[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [WEB SECURITY] Announcement: The Cross-site Request Forgery FAQ
- From: "John Terrill" <jterrill@xxxxxxxxxxxxxxxxx>
- Subject: RE: [WEB SECURITY] Announcement: The Cross-site Request Forgery FAQ
- Date: Tue, 16 Jan 2007 22:01:15 -0500 (EST)
Robert, you and Billy have done an excellent job illustrating XSRF. Its
unfortunate that most of the common suggestions for solving XSS and XSRF
vulnerabilities are flawed.
Rotating session tokens, two factor authentication mechanisms, or
disabling functionality in browsers is rarely an adequate patch and never
the correct solution.
In the case of rotating session tokens, XSRF and XSS vulnerabilities can
still exploit a site. An XSRF attack could direct a user to a spoofed page
where an attacker could instigate a Man-in-the-Middle attack. For
instance, if an attacker exploited an XSRF vulnerability, they could trick
a user in to traveling to a page that says they have been logged out but
is controlled by the attacker. Now the attacker can have the user log back
in but sit in the middle of the conversation seeing all rotating tokens
and altering the information sent to and from the server to the client.
An XSS vulnerability could allow for live Man-in-the-Middle attacks
without having to change domains or spoof extra content or address bars.
In both cases, the ability to intercept a user's traffic is still a viable
option for attackers.
Using a two factor solution like a one-time-pad with a rotating number
like SecureID or PassMark's "Two Way Authentication" utilizing images in
conjunction with additional verification info are still vulnerable to
these kinds of attacks in a similar method. If an attacker could instigate
an XSS or XSRF vulnerability, it would be possible to steal session data
for session hijacking or commit a Man-in-the-Middle attack.
In terms of disabling functionality, its not practical as the usefulness
of most web applications comes with the added features of javascript,
linking to other domains, and rich content (i.e. Quicktime, Flash, Adobe).
At the end of the day, the browser will always be an insecure client. With
that in mind, it will always be difficult to protect users without having
secure clients for access to trusted sites.
------------
John Terrill
CTO - EMT LLC
1 Penn Plaza, Suite 3600
New York, NY 10119
T) 1-212-835-1557
C) 1-404-797-3865
http://www.em-technology.net
?Secure Solutions for an Insecure World?
----------------------------------------------------------------------------
The Web Security Mailing List:
http://www.webappsec.org/lists/websecurity/
The Web Security Mailing List Archives:
http://www.webappsec.org/lists/websecurity/archive/
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Brought to you by http://www.webappsec.org
Search this site
|