Building a Content Security Policy configuration with CSP Auditor

Content Security Policy - or CSP in short – is the latest milestone in browser XSS attack mitigation. Rather than relying on the browser's anti-XSS filter solely, it is now possible to instruct browsers to apply additional restrictions on external resources like Javascript. This is enforced via the CSP HTTP Headers. The true adoption of this standard will probably not happen before auto-generated and transparent CSP configuration become built-in to web frameworks. At the moment, manual work is still needed in most cases.
In this blog post, we discuss the basic strategy to integrate CSP into an existing website. It covers the theory and the new features of CSP Auditor. If you are not familiar with the tool or CSP, you can read our previous article.

Detecting deserialization bugs with DNS exfiltration

At the moment, Java deserialization vulnerabilities are becoming well known by vendors and attackers. Nevertheless, pentesters will still encounter these types of vulnerabilities. The low-hanging fruits can be identified with the current tools. Most of the available tools rely on the command execution API. However, the command from the payload may fail because of Operating System specific conditions. Additionally, the command used might be missing or the arguments it requires may differ due to the version of the command or the flavor installed (ie: GNU netcat vs OpenBSD netcat for example).

Due to the above-mentioned limitations of executing commands, detecting these bugs requires some trial and error. Having to send multiple payloads per target makes automation harder. Crafting a universal payload would simplify large scale detection of deserialization bugs. Before introducing our scanning approach, let's define a set of objectives for a more reliable payload.