Hello Florian,
Yes, This is a known class of vulneraiblities. It is called CSRF (Cross
Site Request Forgeries). There are many sites that have this vulnerability.
GMAIL, slashdot, etc have this.
To protect against these type of attacks use:
1) Post vs Get on all forms, but this can be circumvented using
JavaScripts as you mentioned.
2) Use unique Tokens for each forms (HMAC or randomly generated number
works)
Thanks.
Saqib Ali
http://validate.sf.net
Florian Weimer <fw@deneb.enyo.de> wrote on 11/30/2004 09:27:44 AM:
Hi,
Andrew Moise told me about a class of web application vulnerabilities
I didn't know about: blind POST/GET requests to well-known target URLs
which trigger side effects on the server, reusing authentication
tokens of a victim.
An attack might look like this: The attacker lures a victim to visit a
malicious web page which triggers a request to a web server that is
used by the victim. The browser sends along all the authentication
information it has (cookies, HTTP authentication, SSL client
certificate), and the web server performs the requested operation
(maybe deleting some data, or sending out email).
Thanks to JavaScript, there is little difference between POST requests
and GET requests. Browsers support cross-domain POST requests and
pass along cookies, and there are many applications that depend on
this behavior, so it won't go away. Note that this weakness is not
related to cross-site scripting because no script is executed in the
context of the attacked web application.
Is this class of vulnerabilities already known, and if yes, under
which name? Maybe I'm just using the wrong keywords, I can't find
anything about it.
For applications that don't perform session management and rely on
HTTP authentication, I think this vulnerability can be closed in a
stateless way by passing a time-depended value plus a HMAC of some
page ID, the user name, password, and the same time-depended value
that is sent in the clear as a hidden form parameter. After form
submission, the application can verify that the time-depended value is
relatively recent, and verify the HMAC by recomputing it.
OTOH, if the application uses cookie-based session management, it
should be sufficient to include the session ID in a hidden form
parameter and compare it to the real session ID from the cookie after
form submission. If an application uses URL-based session management,
it's likely not vulnerable in the first place.
Comments?
Florian
PS: Andrew is not subscribed to this list. Please keep him Cc:ed.
