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.

Today ● JavaScript MVC &
Templating Frameworks ● Why? Because they are becoming popular ● Yes, we have numbers, wait for it... ● And they are special ● Are there security flaws? ● If yes (heh.. if..) what can we learn from them?

What are they ● Written
in JavaScript ● Often huge ● Often very complex ● Often maintained by corporations ● Interfaces to enable different coding styles ● Extending, optimizing, changing ● The way developers work with JavaScript ● The way web applications used to work

How do they do it?
I. Parse the “ng”-attributes II. Slice out the relevant parts III. Create anonymous functions IV. Connect them with events V. Wait for event handler to fire $element.onclick=function($event){ $event['view']['alert']('1') } ● It's technically not in-line ● Neither is any “eval” being used

“Packaged apps have access to
Chrome APIs and services not available to traditional web sites. You can build powerful apps that interact with network and hardware devices, media tools, and much more.” :-O

It's bad “Ever played with
Chrome Packaged Apps?” ● Very powerful tools ● Similar yet not equivalent to extensions ● Melting the barrier between web and desktop ● HTML + JS + many APIs ● CSP enabled by default ● And work great with AngularJS (of course)

More CSP Bypasses ● And
even a much better one ● ● Upload a GIF ● ● Inject a class attribute Get a free AngularJS + HTML5 CSP Bypass Wanna see?

Let's upload a pic! <span
class="ng-include:'test.gif'"> </span> Now we inject a class attribute It's a valid GIF but also contains payload! – including the image as HTML! Now it imports itself <link rel="import" href="test.gif"> Thereby loads itself as JS <script src="test.gif"></script> “And pop goes the weasel”

“It looks like we will
agree to disagree on the importance of the HTML imports issue -- we don't think it's possible for a third party to execute arbitrary Javascript via the process you describe, so the risk of unsanitized HTML would be one that the developer was taking on deliberately.”

Quick Recap ● What have
we seen today ● Rotten Markup-Sugar ● JavaScript exec. from data-attributes ● JavaScript exec. from any element ● JavaScript exec. within encoded mustache ● A full-blown CSP Bypass ● The reasons for all these ● Oh – and an attack against Chrome Packaged Apps ● And it was just the tip of the iceberg ● Lots of “eval” and bad coding practices

Metrics ● While root causes
persist, new challenges arise ● We need to build metrics ● After having analyzed 12 frameworks: Here's a proposal {}SEC-A Are template expressions equivalent to a JavaScript eval? {}SEC-B Is the the execution scope well isolated or sand-boxed? {}SEC-C Can arbitrary HTML elements serve as template containers? {}SEC-D Does the framework allow, encourage or even enforce separation of code and content? {}SEC-E Does the framework maintainer have a security response program? {}SEC-F Does the Framework allow safe CSP rules to be used

Conclusion ● JSMVC requires new
security requirements ● No reflected content from the server within template containers ● Sometimes, everything is a template container ● Strict separation is necessary ● And there is hope! ● Maybe JSMVC eliminates XSS ● Because it changes how we design applications. ● And does by boosting and not hindering productivity ● Interested in collaborating on this? Contact me!