XSS in Azure, Choosing Web Research Topics, Security Dev-in-Residence, More Myths – ASW #245

A wonderfully detailed writeup about being diligent in not only finding a flaw, but figuring out how to exploit it. This takes a deep dive into the postMessage() method, for which both that Mozilla documentation and the spec itself give warnings about the potential for XSS from hostile data.

Azure in fact had a lot of security recommendations in place, such as CSP and checking message origins against an allow list. But two endpoints were misconfigured, which the researchers took advantage of.

Another article noted a good practice in Microsoft's response, where they "updated their internal rules to improve scanning for this class of bug across all of Microsoft’s products and services."

Taking over orphaned resources is a security issue for package management systems (including adjacent attacks like typosquatting), sub-domain hijacking, and GitHub repos aka repojacking. (Arguably, the concept is similar to taking over abandoned handles on social media sites or email addresses.)

This research focused more on the consequences and exploit scenarios of repojacking, noting that even large orgs with well-funded security programs had vulnerable repos. Probably the biggest thing to point out here is how difficult asset management is (to no one's surprise) and how complex it is in terms of types of assets (add repos and SaaS assets to the list).

Insights from James Kettle about how to approach security research in terms of challenging yourself, focusing on techniques for a broad audience, and maintaining a sense of curiosity.

The OpenSSF’s Alpha-Omega Project "partners with open source software project maintainers to systematically find new, as-yet-undiscovered vulnerabilities in open source code – and get them fixed."

Through this program the Python Software Foundation (PSF) has hired its first security developer-in-residence. I like how this includes an explicit focus on fixing vulns as opposed to just another effort to scan for more flaws.

Read about how they see their responsibilities and keys to success in their blog. This might also provide some inspiration for orgs looking to start an appsec program, make their first security hire, or integrate security into their DevOps teams.

The four myths noted in this article stood out to me. They're perhaps empty platitudes that you already dismiss or are already suspicious of, but they're a decent way to make sure your risk strategy and approach to appsec has something more concrete to it than just buying more tools, shifting left, or adding more controls.

This article links to a lot of free training and here on ASW we want to highlight free training. But there's a lot of free training out there. And it's important to be able to find training that will introduce you to key topics, help you learn tools, and reinforce techniques for finding or fixing flaws. After all, we need a lot more than just reading about top 10 lists.

The Web Security Academy from Portswigger isn't on the list in that article, but it's definitely one I'd recommend.

We didn't have time to cover this last episode, so we're putting it back on the list for this one -- let's see if we manage to discuss it this time!

While we talk about cloud vulns and security issues, I don't think we've talked through how one tests their cloud environment. What's different than a "normal" pentest? Here's one testers methodology about looking for cloud-specific issues.

CDK - AWS' multi-language IAC framework - is open source, with quite a lot of eyes on it. Nonetheless, a vuln was found in part of the code for creating EKS clusters.

I'm on a hands-on kick this week, it seems. Without offending sponsors, when new applications ask me what they should use for identity and access management, Keycloak is often what I recommend. Still, it's easy for me to say "just use Keycloak." Here's the first part in a series on how to set keycloak up for production use.

This article is crypto-focused, but still interesting to see that the less effective a bug bounty program is, the more the org ends up paying. Perhaps this is part of why bug bounties have a bad reputation in some circles...

This is a neat writeup about looking for and finding a vulnerability in fresh kernel code. I share this under my ongoing trend of thinking about where and how to look for bugs in your code. (h/t hackaday)

That's the viewpoint of the Bytecode Alliance about WASIX, a WASM compiler that compiles to Posix and other bytecodes, not needing a wasm runtime...