[WEB SECURITY] RE: XSS-Phishing on Financial Sites (Tip of the iceberg)
eaton.lists at gmail.com
Mon Jun 26 13:14:10 EDT 2006
On 6/26/06, RSnake <rsnake at shocking.com> wrote:
Hey RSnake - thanks for the feedback.
I think there are two slightly different problems we are thinking
about, which is why the proposal I made looks fairly different from
the content-restrictions and site keys proposal.
Site keys and the firefox content restriction proposal seem to be
targeted for sites that are knowingly allowing end users to publish
limited HTML content. They have an HTML cleaner in place, but they
need some method of handling cases where the HTML cleaner fails.
That's one use case for an XSS-killer proposal.
The other use case is for sites that are just plain broken, where end
users are not supposed to be able to publish any HTML tags. Site keys
and content restrictions are massive overkill for a site like hat. A
web developer with an ounce of clue can fix the problem without
relying on any special browser extensions. But many sites are coded
up by developers without that ounce of security clue, and so reflected
XSS is very common. The situation for CSRF is similar; it's not that
hard to prevent it once you know the problem exists. The problem is
that most developers don't think about it. (This is why I don't think
content restrictions will help much with reflected XSS: if you know
enough to use content restrictions on a page, you've probably already
dealt with most of the reflected XSS issues.)
So the proposal I wrote up was trying to be a solution for
administrators of sites, who think there might be XSS or CSRF
somewhere, but don't have the time/money/skills/access to find and fix
all of the places where XSS and CSRF exist on their site. They could
design a CSL policy to limit their exposure.
Replying to some of the other comments on your blog...
> Firstly, the policies will vary from page to page and on some sites that
> could mean millions of pages.
Yeah, scalability could be an issue. Wildcards are definitely an
option for some site designs, but not for others. Maybe as a test of
the approach I'll pick a few sites and see how hard it is to design a
CSL policy for them.
> Also, avoiding CSRF is very difficult… because many websites want to allow linking to
> remote images. If you link to a remote image, that can actually be a HTTP 301 redirect
> back to your site function.
No problem, unless I'm misunderstanding the attack. The CSL policy
would let you prohibit links from the remote image back to your site.
1) attacker uploads link to http://malicious/evil.jpg
2) victim's browser follows link to http://malicious/evil.jpg
3) evil.jpg redirects back to http://mysite/csrf.php?dosomethingbad
4) victim's browser checks the CSL policy for http://mysite, and
discovers that http://malicious is not supposed to link to
5) victim's browser avoids sending the request to csrf.php, sends user
to the front page of the web site instead.
> Another major problem for this security model is things like Akamai. When you are
> running a very large website and you want to use a content caching service to
I'm not seeing why this would be an issue. Couldn't the CSL policy
just allow links from the Akami domain back to your domain? Or does
that make the CSL policy too permissive to be effective?
> Brian didn't mention are DOM based injection explicitly (he did mention
> XSS, but this is a particular example), which should be allowed given the
> script in question should have the authority to do whatever it needs to.
Again, I'm not really seeing the problem. CSL policy affects what
sites are allowed to link TO your site, not vice versa. Your scripts
will be able to link to anywhere... provided the targeted site's CSL
policy lets that happen. For this case, I don't think DOM based XSS
is all that different from your garden variety XSS.
> Ultimately my major problem with this technology is the same problem that
> Microsoft's HTTPOnly faced. It was a pretty good precaution, that had a few
> small holes and was never properly picked up by the rest of the browser community,
The Web Security Mailing List:
The Web Security Mailing List Archives:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
More information about the websecurity