Cross Site Request Forgery and GET (ACTION-274)

[Thomas Roessler]

Hello,

Dan Connolly asked me to give a quick summary about CSRF.  From the record of the 28 May meeting:

  http://lists.w3.org/Archives/Public/www-tag/2009May/0123.html

... I gather that the main question was specifically about the interaction between safe and unsafe methods here.

There are really two angles to this point:

1. It is really easy to write applications that simply do not distinguish between GET and POST.  See this FAQ for some examples:

  http://www.cgisecurity.com/csrf-faq.html

The result are Web applications that use POST for their own purposes, but actually perform the same operation when they encounter a GET request.  These kinds of application errors can be exploited through relatively easy means, e.g., causing a GET request from some inline content (img tags are popular).

2. HTML forms expose a submit method in JavaScript.  Since forms can be submitted cross-origin, an attacker can cause a browser to send any form-generated POST request to any origin, without the user noticing.  Note, however, that such requests are sent blindly:  The attacker will, for example, not know any personalized information that the web application in question might have sent to the user; the attacker also won't see the site's response to the request.  That's at the basis of using a nonce as a defense technique; in this case, any application that can cause form actions through POST has to prove that it can read information form the site.

Happy to discuss more,

--

Thomas Roessler, W3C  <tlr@...>

[noah_mendelsohn]

Granting that naive users won't know to do this, and even sophisticated
users can easily forget: to what extent can individuals protect themselves
by logging off from one site before visiting another.  In the Netflix
case, am I right that the vulnerability came because a user visited
Netflix, resulting in a cookie for that access, then without logging off
visited a malicious site that used (for example) a script to post an
address change or queue update to Netflix?  Would this have worked if the
user carefully logged off from Netflix before moving on to the next site?

Thank you.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Thomas Roessler <tlr@...>
Sent by: www-tag-request@...
06/03/2009 01:28 PM
 
        To:     www-tag@...
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Cross Site Request Forgery and GET (ACTION-274)


Hello,

Dan Connolly asked me to give a quick summary about CSRF.  From the record
of the 28 May meeting:

  http://lists.w3.org/Archives/Public/www-tag/2009May/0123.html

... I gather that the main question was specifically about the interaction
between safe and unsafe methods here.

There are really two angles to this point:

1. It is really easy to write applications that simply do not distinguish
between GET and POST.  See this FAQ for some examples:

  http://www.cgisecurity.com/csrf-faq.html

The result are Web applications that use POST for their own purposes, but
actually perform the same operation when they encounter a GET request.
These kinds of application errors can be exploited through relatively easy
means, e.g., causing a GET request from some inline content (img tags are
popular).

2. HTML forms expose a submit method in JavaScript.  Since forms can be
submitted cross-origin, an attacker can cause a browser to send any
form-generated POST request to any origin, without the user noticing.
Note, however, that such requests are sent blindly:  The attacker will,
for example, not know any personalized information that the web
application in question might have sent to the user; the attacker also
won't see the site's response to the request.  That's at the basis of
using a nonce as a defense technique; in this case, any application that
can cause form actions through POST has to prove that it can read
information form the site.

Happy to discuss more,
--
Thomas Roessler, W3C  <tlr@...>

[Thomas Roessler]

On 5 Jun 2009, at 00:36, noah_mendelsohn@... wrote:

> Granting that naive users won't know to do this, and even  
> sophisticated
> users can easily forget: to what extent can individuals protect  
> themselves
> by logging off from one site before visiting another.

In theory, that would help (though there are some tricks to cause  
logins when form fillers are active).

The real point here is, though, that today's web browsers will run  
several web applications at the same time; these applications might  
come from different origins, depend on each other, and talk to each  
other.

In that circumstance, a "log out to prevent XSRF" practice just  
doesn't make sense.

[Anne van Kesteren-2]

On Fri, 05 Jun 2009 15:56:52 +0200, Thomas Roessler <tlr@...> wrote:

> On 5 Jun 2009, at 00:36, noah_mendelsohn@... wrote:
>> Granting that naive users won't know to do this, and even sophisticated
>> users can easily forget: to what extent can individuals protect  
>> themselves
>> by logging off from one site before visiting another.
>
> In theory, that would help (though there are some tricks to cause logins  
> when form fillers are active).
>
> The real point here is, though, that today's web browsers will run  
> several web applications at the same time; these applications might come  
> from different origins, depend on each other, and talk to each other.
>
> In that circumstance, a "log out to prevent XSRF" practice just doesn't  
> make sense.

Might actually be harmful to user security as it would encourage sites to ask for the user's authentication data rather than using e.g. OAuth to obtain the relevant data.


--
Anne van Kesteren
http://annevankesteren.nl/

[noah_mendelsohn]

> In that circumstance, a "log out to prevent XSRF" practice just
> doesn't make sense.

Well, it does if the collection of applications/sites you have active
includes at most one in which you have login credentials giving permission
to access or change sensitive information.  For myself, I try to maintain
that self-imposed restriction, and it would be easier and safer if my user
agent helped me to do that.  I'm not saying that this is a complete
solution, but maybe a piece of the puzzle.  For example, if the user agent
were aware of such logins being active, it could warn when a script from
another site was taking advantage of them.

Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Thomas Roessler <tlr@...>
06/05/2009 09:56 AM
 
        To:     noah_mendelsohn@...
        cc:     www-tag@...
        Subject:        Re: Cross Site Request Forgery and GET
(ACTION-274)


On 5 Jun 2009, at 00:36, noah_mendelsohn@... wrote:

> Granting that naive users won't know to do this, and even
> sophisticated
> users can easily forget: to what extent can individuals protect
> themselves
> by logging off from one site before visiting another.

In theory, that would help (though there are some tricks to cause
logins when form fillers are active).

The real point here is, though, that today's web browsers will run
several web applications at the same time; these applications might
come from different origins, depend on each other, and talk to each
other.

In that circumstance, a "log out to prevent XSRF" practice just
doesn't make sense.

[Thomas Roessler]

On 5 Jun 2009, at 16:06, noah_mendelsohn@... wrote:

>> In that circumstance, a "log out to prevent XSRF" practice just
>> doesn't make sense.
>
> Well, it does if the collection of applications/sites you have active
> includes at most one in which you have login credentials giving  
> permission
> to access or change sensitive information.  For myself, I try to  
> maintain
> that self-imposed restriction, and it would be easier and safer if  
> my user
> agent helped me to do that.  I'm not saying that this is a complete
> solution, but maybe a piece of the puzzle.  For example, if the user  
> agent
> were aware of such logins being active, it could warn when a script  
> from
> another site was taking advantage of them.

I suspect that we're operating from divergent assumptions how Web  
applications will develop and be used:  I fully expect that we'll see  
more and more mash-ups where the browser will need access to private  
data hosted on different origins at the same time for the applications  
to function.  I also expect that we'll see more, not less, different  
Web applications being used in parallel by the user.

If we think of the Web as an application platform, then the behavior  
that you suggest seems to get fairly close to only ever running a  
single application on a PC.

[noah_mendelsohn]

Thomas Roessler wrote:

> I suspect that we're operating from divergent assumptions how Web
> applications will develop and be used:  I fully expect that we'll see
> more and more mash-ups where the browser will need access to private
> data hosted on different origins at the same time for the applications
> to function.  I also expect that we'll see more, not less, different
> Web applications being used in parallel by the user.

Fair enough, thank you.
 
Noah

--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Thomas Roessler <tlr@...>
06/05/2009 01:12 PM
 
        To:     noah_mendelsohn@...
        cc:     www-tag@...
        Subject:        Re: Cross Site Request Forgery and GET
(ACTION-274)


On 5 Jun 2009, at 16:06, noah_mendelsohn@... wrote:

>> In that circumstance, a "log out to prevent XSRF" practice just
>> doesn't make sense.
>
> Well, it does if the collection of applications/sites you have active
> includes at most one in which you have login credentials giving
> permission
> to access or change sensitive information.  For myself, I try to
> maintain
> that self-imposed restriction, and it would be easier and safer if
> my user
> agent helped me to do that.  I'm not saying that this is a complete
> solution, but maybe a piece of the puzzle.  For example, if the user
> agent
> were aware of such logins being active, it could warn when a script
> from
> another site was taking advantage of them.

I suspect that we're operating from divergent assumptions how Web
applications will develop and be used:  I fully expect that we'll see
more and more mash-ups where the browser will need access to private
data hosted on different origins at the same time for the applications
to function.  I also expect that we'll see more, not less, different
Web applications being used in parallel by the user.

If we think of the Web as an application platform, then the behavior
that you suggest seems to get fairly close to only ever running a
single application on a PC.