Google and Mozilla lay more groundwork to eliminate XSS vulnerabilities

Link: Browser security briefing: Google and Mozilla lay the groundwork for a ‘post-XSS world’ | The Daily Swig (

Major browser vendors have been adding technologies to browsers that, when enabled by default, make certain types of attacks impossible to reasonably achieve. If you’re doing web application testing, you’ve probably come across a site with a robust Content-Security-Policy header full of things that ruin your day, like nonces.

I say ‘reasonably’ above because application developers first have to correctly implement the new policies and features and change programming habits away from sifting StackOverflow for insecure code.

Google, via the v8 engine, have been at the forefront of designing and implementing these changes into their browser, while Mozilla is further back with Gecko. Apple’s Safari is much further behind, the article says. Microsoft’s Edge benefits from Chromium’s bones, getting the benefits for free.

It seems plain that, once reliable code with secure-by-design attributes are integrated into newer applications, attackers will have to shift to other vulnerability classes such as deserialization or business logic errors, which usually take more time to discover. However, obviously this only applies to applications and frameworks which are actively maintained. Your uncle’s custom database manager from 2013 written in a couple of weeks will continue to have problems.

PEzor - A very thorough tool for making sure your payload has the best chance of success

Link: phra’s blog ~ Technical posts about InfoSec (

In a detailed and well-sourced blog, @phraaaaaaa describes a tool for making darned sure that you’ve done everything you can to get your shellcode past defensive technologies on Windows.

Incorporating Donut, randomization, polymorphic code segments, and direct syscalls into the Windows kernel (generated dynamically!), PEzor is designed to make it difficult to let the blue teams normal layers of defense get a solid lock on the shellcode. A clever mechanism helps ensure that executables aren’t calling into userland hooked versions of sensitive syscalls, which are commonly used by EDR products to generate alerts or identify commodity malware. Polymorphic code makes it difficult to to statically signature such binaries as well.

It isn’t perfect, but is a great example of why application whitelisting and a strong defense-in-depth strategy is important.

Repo full of goodies

Link: hackerscrolls/SecurityTips (

The Hackerscrolls repo is full of, as you might expect from the name, large format images with mind maps or other organized data about various offensive topics. They’re probably not fit to literally print, but contain neat stuff. I was especially impressed with this example, which I thought was damned clever. I certainly never thought of it.