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

Brian Eaton eaton.lists at gmail.com
Sat Jun 24 22:08:22 EDT 2006

On 6/24/06, arian.evans <arian.evans at anachronic.com> wrote:
> Most home DSL/cable/Router-thingies have changed from GETs to POSTs,
> that I've looked at, but some POSTable forms still parse GET anyway
> (maintaining trivially high attack surface).

Switching to POST doesn't do anything to prevent CSRF, at least not
while nearly everybody uses browsers with javascript enabled.

<body onload="javascript:document.myform.submit()">

> This year we released a homegrown WAF at BH Amsterdam to transparently
> block these types of attacks, and were *really* excited about it.
> It was poorly received and I think poorly understood, as I mentioned
> before, due to presentation deficiencies.

Even if you don't work on this WAF any further, I think you should
keep pitching the technique you were using to block XSS and CSRF.  XSS
and CSRF are epidemic, and most of the suggestions for resolving them
are just picking around the edges of the problem.  More comprehensive
solutions are needed.

I've been wondering whether web application developers could cooperate
with browser vendors to find a way to make XSS and CSRF harder to
exploit.  I'm pretty sure that there is nothing a browser can do to
prevent exploitation of persistent XSS/CSRF vulnerabilities, but for
the more common "legitimate user visits malicious web site" scenarios
I suspect browsers could help.


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