I don't *think* this is a big issue. There are two possibilities:
1. Source site is vulnerable to XSS attacks.
In this case, attack could simply send a request to the
attacker's server with the victim's cookie, or with the whole page
contents, or with any information available to JavaScript. If we're
using cookies to handle state, then keeping a cookie in a hidden form
field won't add anything extra-- the XSS attack could grab it just as
easy. If we're stateless, then including a hash of the authentication
information + time information will suffer the same fate as the
cookies-- they're available to the attacker.
2. Source site is not vulnerable to XSS attacks.
Here, you implicitly trust the source site with your
authentication information. If the source site wanted to, it could send
your authentication information to the attacker on its own-- or post it
to a newsgroup-- it's out of your control.
Unless I'm missing something, which is quite possible...
Mike
-----Original Message-----
From: Florian Weimer [mailto:fw@deneb.enyo.de]
Sent: Tuesday, November 30, 2004 12:28 PM
To: webappsec@securityfocus.com
Cc: chops@demiurgestudios.com
Subject: Blind cross-domain POST/GET requests
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.
