1
Placing ‘exploit kits’ on compromised pages, and hitting their users’ with browser exploits or downloads continues to be popular, as is conducting ad-fraud. Cryptocurrency mining is yet another vector for attackers to monetize their hacks.
The problem is this; how does a browser verify that the code it has received from a website – is the same code the organization released to production?
The use of secure HTTPS communications – over TLS and SSL – prevents some attackers, such as those carrying out man-in-the-middle attacks from malicious wireless access points, or your local network. However, there’s a much larger attack surface upstream of HTTPS protections, Load Balancers, upstream enterprise components (an explosion with microservices trends), and the application servers themselves. Any of these components present a pivot point for attackers looking to exploit customers – because they can all introduce code before those connections are protected over the wire with HTTPS.
What we could use is an addition to web-standards, one that allows organizations to produce verifiable client-code, and browsers to validate that code. Long term, the dynamic aspects of JavaScript and modern development practices – such as manipulation of the Document Object Model at runtime – via WebSockets, Web Messages, contents of state in LocalStorage, and Ajax calls, mean that these efforts need to rely on a subset of JavaScript, safe from unintended injection attacks. Quick and Dirty - think GPG signatures.
Is there any work being done in this domain?
Copy of the contents here, skip the contact form: http://www.slideshare.net/TravisBiehn/cigitalexploitingjava
Grab a copy: https://www.cigital.com/resources/ebooks-and-whitepapers/java-deserialization-vulnerability/