[WEB SECURITY] Close Encounters of the Third Kind - A look at the prevalence of client-side JavaScript vulnerabilities (new whitepaper)
Ory Segal
SEGALORY at il.ibm.com
Thu Jan 6 17:06:28 EST 2011
Hi Arian,
I don't kiss & tell without an NDA.
-Ory
-------------------------------------------------------------
Ory Segal
Security Products Architect
AppScan Product Manager
Rational, Application Security
IBM Corporation
Tel: +972-9-962-9836
Mobile: +972-54-773-9359
e-mail: segalory at il.ibm.com
From: "Arian J. Evans" <arian.evans at anachronic.com>
To: Ory Segal/Haifa/IBM at IBMIL
Cc: tasos.laskos at gmail.com, James Manico <jim at manico.net>,
"websecurity at webappsec.org" <websecurity at webappsec.org>
Date: 06/01/2011 11:57 PM
Subject: Re: [WEB SECURITY] Close Encounters of the Third Kind - A
look at the prevalence of client-side JavaScript vulnerabilities (new
whitepaper)
Sent by: arian.evans at gmail.com
Well, I can only speak for myself, but this discussion is not becoming too
technical. And I'm even mindless middle-management!
Please do share more details about how exactly you taint, trace taints to
sinks, and map those to the correct malicious payload. Very exciting
material!
I am also curious your thoughts on another problem I see here -- perhaps
you covered this in your paper and I missed it - but a lot of this
client-side/DOM code comes from Domains that security stakeholders are:
(a) not authorized to test (by SRC or DST domain)
(b) are not aware exist
So even the best technology fails to properly envelope & include the
necessary pieces of code from off-domain, or see the dynamically built
parameters that go to off-domain locations.
I am speaking of the use-case where you explicitly-allow and authorize
testing content by domain and child node. Authorizing each node and child
explicitly (store.ibm.com, www.ibm, etc.) Obviously if you run your tools
wide-open (*.*.*) this will not be an issue. But, in the latter use-case,
becoming blacklisted by ISPs will soon become your issue.
--
Again - great work though moving the bar forward, and great paper!
Slightly different approach than I would take....but if restricted to pure
automation to attempt to address this problem, building a DOM, and then
statically analyzing it by taint and trace makes the most sense for your
technology use-case. Dynamically tainting and trace the DOM is a real
bear, unless you either have human expertise in selecting the taints or
run through a bazillion automated permutations of taints. If you try to
taint dynamically, without context, you will land squarely in False
Negative Country most of the time.
So again, great work.This is actually do similar to the analysis we do on
Flash and Silverlight. But today we prefer to execute Javascript space
dynamically.
Apologies to all if I got too technical,
---
Arian Evans
Static Scriptspace Scanning Savant
On Thu, Jan 6, 2011 at 1:04 PM, Ory Segal <SEGALORY at il.ibm.com> wrote:
Hi,
This discussion is becoming too technical. We have quite an interesting
list of client-side issues that JSA can find such as: DOM-based XSS, Open
Redirects, Code Execution and even some HTML5 related issues like
Client-side SQL Injection and Client-side Stored XSS. Since each issue is
being detected using taint analysis, you probably know that it requires a
definition of JavaScript sources, sinks and sanitizers. In addition, we
have built a unique String analysis algorithm, which verifies that each
taint flow that is detected from source to sink, actually permits the
correct malicious payload to reach the sink.
-Ory
-------------------------------------------------------------
Ory Segal
Security Products Architect
AppScan Product Manager
Rational, Application Security
IBM Corporation
Tel: +972-9-962-9836
Mobile: +972-54-773-9359
e-mail: segalory at il.ibm.com
From: Tasos Laskos <tasos.laskos at gmail.com>
To: Ory Segal/Haifa/IBM at IBMIL
Cc: James Manico <jim at manico.net>, "websecurity at webappsec.org" <
websecurity at webappsec.org>
Date: 06/01/2011 10:51 PM
Subject: Re: [WEB SECURITY] Close Encounters of the Third Kind - A
look at the prevalence of client-side JavaScript vulnerabilities (new
whitepaper)
Hi,
Yeah that makes sense.
Just out of curiosity...what was the taint?
Was it a benign string and you just checked if during the execution flow
it was passed through escape methods etc. or was it actual code that
triggered a previously defined callback that logged successful
executions/injections?
Or was it code and you just monitored sensitive DOM changes and went
from there?
In that case successful manipulation of a DOM property would mean
successful exploitation.
I'd personally go with the last one...
Obviously I haven't given it much thought but I was curious.
If you can't discuss the matter in public we'll all understand. :)
Cheers,
Tasos.
On Thu, 2011-01-06 at 22:27 +0200, Ory Segal wrote:
> Hi,
>
> While usually I would agree that a thorough human pentester would find
> more issues by manually auditing an application, I must disagree with
> you in this scenario. Locating client-side JavaScript issues requires
> long hours of code reviewing fragmented JavaScript and HTML code.
> There is a good reason (which I mention in the beginning of my paper)
> why people never tried to estimate the prevalence of such issues....
> it's just too time consuming.
>
> Here's a quote from Jeremiah's blog (2006), which I really like: ?The
> [DOM-Based XSS] vulnerability is actually buried inside the JavaScript
> code. We'll soon have to deeply educate ourselves on how best to spot
> these issues both by hand and through automated means. At the moment
> we have to sift through seas of JavaScript code, ugh"
>
> IMHO Using static taint analysis of JavaScript code (during dynamic
> analysis) is currently the most accurate way to locate such
> client-side issues, as we presented in our paper.
>
> Naturally, like any automated analysis it has drawbacks, but I prefer
> having the ability to find the issues, than to be oblivious.
>
> @Tasos - this is a "hybrid" approach. It uses static taint analysis
> techniques to inspect data flow, but the source code was built after
> dynamically executing it, in order to gather as much source code as
> possible.
>
> -Ory
>
>
>
>
> -------------------------------------------------------------
> Ory Segal
> Security Products Architect
> AppScan Product Manager
> Rational, Application Security
> IBM Corporation
> Tel: +972-9-962-9836
> Mobile: +972-54-773-9359
> e-mail: segalory at il.ibm.com
>
>
>
>
> From: James Manico <jim at manico.net>
> To: Ory Segal/Haifa/IBM at IBMIL
> Cc: "websecurity at webappsec.org" <websecurity at webappsec.org>
> Date: 06/01/2011 07:48 PM
> Subject: Re: [WEB SECURITY] Close Encounters of the Third Kind
> - A look at the prevalence of client-side JavaScript vulnerabilities
> (new whitepaper)
>
>
>
> ______________________________________________________________________
>
>
>
> Ory,
>
> While this is interesting research, I'm surprised you did not address
> how "sound" your new JSS analysis tool is. Static analysis tools are
> are great at breadth, but what about depth? In particular, I'm taking
> about false negatives. How many bugs did a dedicated pentester find
> that your tool missed, or vice versa?
>
> I see that this study used smart humans to verify that findings were
> not false positives, but I don't think that is deep enough to really
> understand how good this new feature is.
>
> Fair?
>
> -Jim Manico
> http://manico.net
>
> On Jan 6, 2011, at 9:20 AM, Ory Segal <SEGALORY at il.ibm.com> wrote:
>
> Hello,
>
> IBM has recently published a new whitepaper on the subject of
> client-side JavaScript vulnerabilities.
>
> Below you can find a short excerpt from the whitepaper:
>
> "In the past 10 years, many whitepapers, research articles, and blogs
> have been published on the subject of server-side web application
> vulnerabilities such as SQL Injection, Cross-Site Scripting, and HTTP
> response splitting. In addition, several projects such as the WASC Web
> Hacking Incident Database or the WASC Statistics project have tried to
> estimate the incidence of such issues in the real world. On the other
> hand, there is a dearth of information and statistics on the incidence
> of client-side JavaScript vulnerabilities in web applications, even
> though these vulnerabilities are just as severe as their server-side
> counterparts. We suspect that the main reason for this lack of
> information is simply because client-side vulnerabilities are harder
> to locate, and require deep knowledge of JavaScript and the ability to
> perform code review for HTML pages and JavaScript files. As Web 2.0,
> AJAX applications and rich internet applications (RIAs) become more
> common, client-side JavaScript vulnerabilities will probably become
> more relevant, and we foresee a rise in the amount of such issues
> being exploited by malicious hackers. This whitepaper presents the
> results of a research recently performed by the IBM Rational
> Application Security group into the prevalence of client-side
> JavaScript vulnerabilities. For this research, we used a new IBM
> technology called JavaScript Security Analyzer (JSA), which performs
> static taint analysis on JavaScript code that was collected from web
> pages extracted by an automated deep web crawl process. This kind of
> analysis is superior to and more accurate than regular static taint
> analysis of JavaScript code, as it includes the entire JavaScript
> codebase in its natural environment: fully rendered HTML pages and the
> browser?s Document Object Model (DOM).The research used a sample group
> of approximately 675 websites, consisting of all the Fortune 500
> companies and another 175 handpicked web sites, including IT, Web
> application security vendors, and social networking sites."
>
> The whitepaper can be downloaded at the following address:
>
>
http://www.ibm.com/common/ssi/cgi-bin/ssialias?infotype=SA&subtype=WH&appname=SWGE_RA_RA_USEN&htmlfid=RAW14252USEN&attachment=RAW14252USEN.PDF
>
>
> * I would like to thank Amit Klein & Jeremiah Grossman for reviewing
> the whitepaper and sending me their feedback
>
>
>
> -------------------------------------------------------------
> Ory Segal
> Security Products Architect
> AppScan Product Manager
> Rational, Application Security
> IBM Corporation
> Tel: +972-9-962-9836
> Mobile: +972-54-773-9359
> e-mail: segalory[at]il.ibm.com
> <mime-attachment.gif>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110107/ffac0ed5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2359 bytes
Desc: not available
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20110107/ffac0ed5/attachment.gif>
More information about the websecurity
mailing list