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

RSnake rsnake at shocking.com
Mon Jun 26 11:55:01 EDT 2006



 	Hi, Brian, I posted more about this thread here:

http://ha.ckers.org/blog/20060626/content-restrictions-and-script-keys/

 	Additionally I had some comments on script-keys, Gerv.  I think
script keys do hold a lot of promise, but it's unclear if it's a
one-time use token or used more than once.  That particular issue seems
a little scary.  I can see a webdeveloper hard coding that information
making it vulnerable to Ajax requests.  Or developers may base it off of
something easily guessable, like time (god knows we've all seen that one
enough times).  My other problem with it is that it uses a HTTP header
only in it's current incarnation.  There aren't many people who have
access (or know how to access) the HTTP Header (or it's re-written by
proxies or whatever).  Meta tags are far more useful for most people and
tend to stay intact.

-RSnake
http://ha.ckers.org/
http://ha.ckers.org/xss.html
http://ha.ckers.org/blog/feed/

On Sun, 25 Jun 2006, Brian Eaton wrote:

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

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