[WEB SECURITY] RE: XSS-Phishing on Financial Sites (Tip of the iceberg)

Brian Eaton eaton.lists at gmail.com
Sun Jun 25 17:29:41 EDT 2006


On 6/25/06, RSnake <rsnake at shocking.com> wrote:
> A few weeks ago I wrote about this on the blog:
> http://ha.ckers.org/blog/20060601/content-restrictions-and-xss/

This is cool, I guess I was wrong about it not being possible for
browsers to help with the problem of persistent XSS.  Hopefully the
LiveJournals and eBays of the world will contribute to that work.

The content restrictions work they are doing does not appear to be
targeted at CSRF and reflected XSS.  So long as browser plugins are a
fair subject for discussion, I submit for the consideration of the
court a system for browsers and servers to cooperate to mitigate the
risk of CSRF and reflected XSS.

Criticism of this approach, both constructive and otherwise, is
appreciated.  I'm going to list several problems with this mechanism
at the end of this note.  Please add to the list.

Servers will provide browsers with a policy describing what kinds of
cross-site links are normal and should be permitted.  Browsers will
compare the source and destination for cross-site transitions to the
server policy for cross-site links.  If the transition does not match
the server's policy document, then the browser will instead direct the
user to a fallback page specified by the policy.

Here's an example of what I'm thinking of:
- Browser begins following a link from
http://source.start.com/source.html to
http://dest.finish.com/dest.html.
- Browser downloads http://dest/cslpolicy.xml, or uses a cached copy
of the policy.
- Browser evaluates the transition from http://source/source.html to
http://dest/dest.html against the CSL policy.
- If cslpolicy.xml permits the transition, the link is followed as normal.
- If cslpolicy.xml does not permit the transition, then the browser
instead sends the user to http://dest/welcome.html.

A CSL policy document would specify rules like this, probably in an XML format:

If (destination matches http://dest.finish.com/knowledgebase)
    <!-- this is a link to the knowledge base, everybody can link to this -->
    all sources are allowed

if (destination matches http://dest.finish.com/account)
    <!-- this is a link to the account management application, only
our own sites need to link to here -->
     if (source matches http://*.finish.com)
          link allowed
     else
          fall back to http://dest.finish.com/account/start.html

if (destination matches http://dest.finish.com/*)
      could either allow cross-site links by default, or deny
cross-site links by default, depending on whether the business expects
cross-site links to be common.  Denying cross-site links by default is
a more secure policy.

How does this prevent CSRF and reflected XSS?  It prevents a malicious
web site from forcing the browser to send arbitrary requests to the
targeted web site.  There is no good reason for a geocities web page
to link to the "funds transfer" application.  The CSL policy document
lets the server explain that to the browser, so the browser can
recognize the request as unwanted.  A properly written CSL policy
document will reduce the target surface for XSS and CSRF attacks.  An
attacker needs to do more than find a vulnerable page on the targeted
web site: they need to find a way to host their attack on one of the
pages trusted to link to the vulnerable page.

One neat thing about this approach is you can make a good start at a
sensible CSL policy for your site simply by parsing your referer logs.

OK, where does this system fall down?

It may break for some of the same reasons referer header checks break.
 If an attacker can trick the browser into an incorrect determination
of the source of the link, then the attacker can bypass the CSL
policy.

If an attacker can trick the browser into an incorrect determination
of the destination of the link, the attacker can bypass the CSL
policy.

It breaks if one of the trusted source sites in the CSL policy has an
XSS vulnerability.  An attacker can use that vulnerability as a
jumping off point for an attack on the destination site.

Even something as basic as a redirection service on a trusted source
site can allow an attacker to dodge the CSL policy.  If a trusted
source site hosts a page like http://source/redir?targ=<anywhere>, an
attacker can leverage that to attack the destination page.  (On the
other hand, this does limit the attack surface to links generated by
http://source/redir.  POST requests probably won't be possible.)

If the browser doesn't support CSL policy, then the user remains
vulnerable to all of the attacks.

It breaks if business needs require a very loose CSL policy.  For
example, I may want arbitrary sites to be able to link to my knowledge
base.  Wikipedia is never going to be able to specify a useful
cross-site linking policy.

Again, criticism is appreciated.  I'm hoping I haven't wasted a bunch
of time writing up an idea that is fundamentally broken.

Regards,
Brian

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



More information about the websecurity mailing list