| 2008-11-20 05:00:06 |
Aaron Swartz |
description |
The typical way to build a web.py application that lets users do things is to:
a) give the user a cookie to log into the site
b) present them with an HTML page with some prepared request (i.e. form or link)
c) do the action when they submit the request
The problem is that, with cross-site scripting attacks, scripts on other pages can cause the user's browser to submit the same request and, since the user already has the cookie, the request will go thru.
To prevent this, request tokens should be sent along with the request. This makes this attack more difficult, since the scripter has to grab the token and then use it to resubmit the request. (Admittedly, this doesn't seem like much of an improvement, but I might be missing something.) |
The typical way to build a web.py application that lets users do things is to:
a) give the user a cookie to log into the site
b) present them with an HTML page with some prepared request (i.e. form or link)
c) do the action when they submit the request
The problem is that, with cross-site scripting attacks, scripts on other pages can cause the user's browser to submit the same request and, since the user already has the cookie, the request will go thru.
To prevent this, request tokens should be sent along with the request. This makes this attack more difficult, since the scripter has to grab the token and then use it to resubmit the request. (Admittedly, this doesn't seem like much of an improvement, but I might be missing something. I guess JavaScript makes it easier to send cross-server POSTs than it does to get the responses of GETs: http://www.webappsec.org/lists/websecurity/archive/2007-01/msg00157.html) |
|
