WebApp Sec mailing list archives

Blind cross-domain POST/GET requests


From: Florian Weimer <fw () deneb enyo de>
Date: Tue, 30 Nov 2004 18:27:44 +0100

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.


Current thread: