<?xml version="1.0" encoding="utf-8"?>
<feed xml:lang="en-us" xmlns="http://www.w3.org/2005/Atom"><title>Simon Willison's Weblog: ouath</title><link href="http://simonwillison.net/" rel="alternate"/><link href="http://simonwillison.net/tags/ouath.atom" rel="self"/><id>http://simonwillison.net/</id><updated>2009-04-23T15:06:13+00:00</updated><author><name>Simon Willison</name></author><entry><title>OAuth Security Advisory 2009.1</title><link href="https://simonwillison.net/2009/Apr/23/oauth/#atom-tag" rel="alternate"/><published>2009-04-23T15:06:13+00:00</published><updated>2009-04-23T15:06:13+00:00</updated><id>https://simonwillison.net/2009/Apr/23/oauth/#atom-tag</id><summary type="html">
    
&lt;p&gt;&lt;strong&gt;&lt;a href="http://oauth.net/advisories/2009-1"&gt;OAuth Security Advisory 2009.1&lt;/a&gt;&lt;/strong&gt;&lt;/p&gt;
It’s a show-stopper: an attacker can start an OAuth permission request flow from a consumer site, then trick another user from the same site in to completing that flow and hence authorising the attacker to act on their behalf. A fix to the spec is forthcoming; in the meantime, don’t start an OAuth flow from an untrusted location.


    &lt;p&gt;Tags: &lt;a href="https://simonwillison.net/tags/ouath"&gt;ouath&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/security"&gt;security&lt;/a&gt;, &lt;a href="https://simonwillison.net/tags/sessionfixation"&gt;sessionfixation&lt;/a&gt;&lt;/p&gt;



</summary><category term="ouath"/><category term="security"/><category term="sessionfixation"/></entry></feed>