Joe Petterson: JavaScript security: myths, fallacies and anti-patterns
Joe Pettersson (@Joe8Bit) was talking about JavaScript security at Scotland.js, these are my notes from his talk.
We don't think about security enough. Maybe some form validation? The more business logic you put in the client the harder it gets. The client environment isn't under your control so is fundamentally untrustworthy. Traditionally you strongly decouple your front end from your server - double validation: both client and server. Also client side code shouldn't trust data coming from the server -> XSS.
We need modular and multi-layered security. For example, a view might not trust data coming from a model. If the model is compromised it can use the view to get access to the DOM which is a huge vulnerability surface.
New generation of APIs are a constantly changing landscape and can have a lot of access.
- Web Messaging and cross domain messaging. Can send messages between tabs. Sending post messages can be completely open to all tabs.
- Storing data in the clients, some of the storage APIs are vulnerable. SQL injection in WebSQL.
- WebWorkers, you can DOS yourself easily.
- iFrames can be sandboxed to block exploit paths.
- Cache poising manifest files via MTM. Can hijack the entire runtime.
- WebGL runs in kernel mode, attacks via insecure GPU drivers. DOS is trivial and can brick the entire environment. (Graphics drivers are typically only 40% on the latest version.)
Testing
Verify how we've done it.
- What are your integration points?
- What you're breadth of attack surface
- Where are the trust boundary
- What are the fundamental implications of the technology (e.g. hardware APIs)
- Understand the risk points
Person merging code has responsibililty with author for security. You're blind to your own blindness.
Penetration testing
- Whitebox -> working from code to vulnerability
- Blackbox -> looking at behaviour and assesing vulnerabilites
Pen testing and vulnerability scanning overlap. Metasploit is a good free tool to start with, there are lots of modules for different attack vectors.
Use CI to test that you aren't vulnerable as part of your process.
Amateurs have automated tools; professionals have people.
Don't do it in production, people will break things if they're doing their job right! Run in a prod replica environment, try and use as much real data as possible.
External tests are always really valuable.
You have to have a stable release you can test against.