Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Client side code is a growing part of the modern web and those common patterns or libraries, that are supposed to help developer's life, have the drawbacks to add complexity to the code exposing unexpected features with no or little warning.
We will focus on the most popular JavaScript libraries such as jQuery, YUI etc and common design pattern, describing how happens that wrong assumptions can lead to unexpected, unsafe behavior.
Several code example and live demos during the talk will try to clear both exploitation techniques and positive coding strategies.

The presentation will also show some interesting case study, collected and identified during two years of real world applications analysis.
Slides of the talk I did at Appsec EU 2013 in Hamburg.
Video will be linked asap.

4.
About this talk
• A wrap up of some interesting JS snippets
• Reckless use of common libraries and third
party scripts
• Some unwitting one as well
• Comes after 2.5 years developing/using
DOMinator and DOMinatorPro

5.
• What's a Sink in Application Security?
“..a function or method that can be considered unsecure when one of its
arguments come from an untrusted input and is not correctly validated
according to the layer the function is going to communicate to.“
• C's strcpy is a sink. strcpy(dst,src)
• Java's jdbc.executeQuery is a sink executeQuery('select * from t
where id='+str)
• JQuery.html is a sink
(and no one complains)
JQuery() is a Sink(?)

6.
• JQuery is More than a Sink!
• Other sinks do only one thing. JQuery was designed to perform
different operations based on the argument type and content.
JQuery() more than a Sink
http://api.jquery.com/jQuery/

7.
• JQuery was written with flexibility in mind
• But introduced a design issue that could be called a 'developer trust
boundary violation'.
– The principal use is for selecting elements (trusted)
– ...and 'onload' callback execution(trusted)
– The least one used is the actual sink method:
JQuery() more than a Sink
jQuery( html [, ownerDocument ] )
Enough Words!
Show Me The Code

9.
• Might be considered as a potentially dangerous method ?
– depends on how its results are further used.
• It's more than querySelectorAll because there are features like:
$("div:contains(" + word + ")")
What if:
word=),div[id=secret]:contains(cycleForDataExtr)..
• If the results will affect something that is observable by an attacker, then
we got a problem!
JQuery() as a Selector?

10.
• JQuery Users:
– Never Use jQuery() or $() with an unvalidated argument
– No matter which version you are using!
– Read the whole documentation, please!
– And since the doc is never really complete, take some time to read the
code!
• JQuery Developers, please:
– remove old versions (zip them all for reference)
– Plan to change the jQuery do-everything behaviour to a do-simply-
one-thing behavior.
JQuery() Solution

25.
• http://www.ietf.org/rfc/rfc4627.txt
Security considerations:
JSON.js (OBG)
«Generally there are security issues with scripting languages. JSON is a subset of
JavaScript, but it is a safe subset that excludes
assignment and invocation.
A JSON text can be safely passed into JavaScript's eval() function
(which compiles and executes a string) if all the characters not
enclosed in strings are in the set of characters that form JSON
tokens. This can be quickly determined in JavaScript with two
regular expressions and calls to the test and replace methods.
var my_JSON_object = !(/[^,:{}[]0-9.-+Eaeflnr-u nrt]/.test(
text.replace(/"(.|[^"])*"/g, ''))) &&
eval('(' + text + ')');
Interoperability considerations: n/a
Published specification: RFC 4627»

27.
• parseJSON('a') is considered valid even if
it's not JSON → a is actually eval'ed!
• Eaeflnr-u part with no quotes let's you do this.
• Next step is to see if there some standard object in window that matches
the JSON regexp.
Results in:
self
status
JSON.js (OBG)
http://blog.mindedsecurity.com/2011/08/ye-olde-crockford-json-regexp-is.html
for(var aa in window)
if( aa.match(/^[,:{}[]0-9.-+Eaeflnr-u nrt]*$/))
console.log(""+aa)

33.
JSON.js Solution
• The new json.js uses a brand new regexp which "should" be
safe
• Or use json_parse.js which doesn't use eval.
• ..or better use native methods JSON.parse / JSON.stringify if
you can!
• Finally, remember that after parsing you still have an
unvalidated object!
{"html":"<img src='s'onerror='XSSHere'>"}

36.
Cookie Parsers
set an attacker site:
http://www.attacker.com/userHist=alert(1)
Iframing victim site which will sets cookie:
ref=http://www.attacker.com/userHist=alert(1)
Then looks for userHist and Boom!

37.
• YUI().use('jsonp', 'jsonp-url')
http://yuilibrary.com/yui/docs/jsonp/
HPP anyone?
YUI.js JSONP
Customizing the JSONP URL
The default URL formatter simply replaces the "{callback}" placehold with the name of the
generated proxy function. If you want to customize the URL generation process, you can
provide a format function in the configuration. The function will receive the configured URL
(with "{callback}" placeholder), the string name of the proxy function, and any additional
arguments that were passed to send().
Enough Words!
Show Me The Code

39.
• Test and audit all the 3rd party libraries / js!
• Do it periodically if they are external resources
3rd party services solution

40.
• Mustache + Expression Language → Interesting Injections
• AngularJS uses stuff like:
<div ng-init="some.js.code.here"> or
{{constructor.constructor('alert(1)')()}}
• AngularJS uses it's own parser (similar to Expression Language).
• If there's an inection point, no actual antiXSS filter will be able to stop
these attacks.
• Credits to .Mario (MVCOMFG) and Kuza55
(https://communities.coverity.com/blogs/security/2013/04/23/angular-
template-injection) as well for their awesome research on this topic!
AngularJS

41.
• JavaScript code can always be read so black box turns into
white box analysis
• JavaScript secure development is still not fully implemented
even on companies that know about security.
• JavaScript Developers can be super badass coders but also
naives as well on some circumstances and their code is
available for everyone.
• Just scratched the surface of JavaScript security!
• Let's give jSanity a try! :)
Conclusions