Re: Blind cross-domain POST/GET requests

[Saqib.N.Ali () seagate com]

Oh and BTW, application that use CDSSO (Cross Domain Single SignOn) and
ESSO (Enterprise Single SignOn) are at more risk of CSRF attacks, and
developers of these application should be extra careful.

Thanks.
Saqib Ali
http://validate.sf.net

Saqib.N.Ali () seagate com wrote on 12/01/2004 11:44:50 AM:

> 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.