Stopping Business Logic Attacks: Why a WAF is no Longer Enough – Karl Triebes – ASW #255

I always say I find XSS boring and then I end up including the occasional article that references it. In this case, there's a slew of XSS vulns in Azure's collection of open source tools for analytics under its HDInsights feature.

It's a good article, with a clear explanation of the services involved and the vulns discovered. One quibble I have is with the characterization of XSS as an input validation issue. That's a common framing of the problem -- even the OWASP Top 10 list does it. But I always see XSS as an issue with rendering the output safely for its destination context. You can accept whatever input you want, whether its characters used in HTML or not. You just have to escape them properly when they're rendered. Move the security check to where it's most relevant and is best handled.

Bringing the topic back to the article, it's quite surprising and disappointing that XSS would be present in a modern app, especially for as simple a payload as an image error handler.

"Microsoft’s AI research team, while publishing a bucket of open-source training data on GitHub, accidentally exposed 38 terabytes of additional private data — including a disk backup of two employees’ workstations."

In other words, this is exactly the sort of data leakage warned about in AI adoption -- and it's about the most spectacular way to do so in terms of amount of data and sensitivity of data. One of those backups included secrets, private keys, and passwords

Mentioning this because it highlights race conditions, which sounds like that'll be the theme of web app security conferences and vuln disclosures for the next year or two -- and I say that with affection! It's nice to see the generic "business logic" flaw be decomposed into more interesting examples and types.

We've also talked previously about the research from James Kettle on race conditions in web apps.

I enjoy reading security audits for a few reasons. One, it's interesting to see what types of issues are being identified and if any of the techniques seem new. Two, how results are presented in terms of a focus on implementation errors or underlying design flaws. Three, hints of the testing techniques and scenarios used in the test. It's that last item that can add to appsec education, but it's also the item that mostly commonly missing or superficial. This report doesn't go into much detail, but it has a short list of project goals that can serve as seeds for threat modeling and it references fuzzing quite a bit.

On the specific findings, it seems surprising that the file access isn't in a sandbox at all, which was part of the reason the researchers could execute arbitrary file read and write. I also appreciated that, even though they didn't find an explicit flaw, they pointed out the risks of relying on regexes and string methods to parse URLs -- regexes and parsing and fraught with danger.

Another report from the CNCF, this time coming Kyverno. (We also mention CNCF's Dragonfly2 security audit this episode.)

I like that the intent of this work isn't to fuzz and forget, it's to demonstrate integrating fuzzing within the project and putting it on a path to be able to fuzz on a continuous basis with large coverage. It also shows that saying, "Use a fuzzer" comes with a lot of unmentioned development overhead.

CISA lays out the important of open source software (OSS), including the need to better quantify just how important and prevalent it is.

It's a relatively brief doc with two goals that should resonate with a lot of orgs looking to improve security: visibility and hardening.

I'm curious about objective 2.2. -- "Develop a Framework for OSS Risk Prioritization" -- and how CVSS, exploitability, and other approaches to describing impacts and risks will play into it.

I'm very curious about objective 4.2. -- "Foster Security Education for Open Source Developers -- since security education is a topic we revisit often. I really hope it goes far, far beyond reciting entries from a top 10 list.

There's also objective 4.3 about publishing guidance on best practices. That's another one that I hope turns more towards design principles and away from hardening guides.

This is a nice reduction in attack surface, but wow does it take a long time to deprecate major features...

The latest top 10 for APIs is here. We talked about lots of top 10 lists back in episode 242.

Not going to rehash much of that episode here. So, here's the list of API security things. Three of them are broken authorization, another is "unrestricted access" -- which sounds like a way to have a fourth broken authorization entry.

The OWASP Global Board elections are coming up. If you're a member, or wish to be a member and influence the org's direction, check out the timeline and candidates.

For the amount of patching and rebooting over the last week, there's not a lot of (public) info out there on this issue: The libwebp project had a heap overflow vulnerabiilty which reportedly was being exploited in the wild. A look at the fix (below) is a good example of sometimes it's not quite as simple as checking bounds...

https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a

This is a cute information disclosure vulnerability: In short, due to how antennas are positioned in many mobile devices, the signal seems to be attenuated as a user types on the device's screen. The information about the quality of this signal is used by WiFi beam forming to determine the best way to communicate between the mobile device and access point - and is transmitted to the WiFi access point in plaintext.

Researchers have figured out how to use the variations in that signal quality to recognize numerical passwords with up to 90% accuracy.

For a "named attack," These guys did a horrible job on the SEO. I keep getting search results for rappers and video games.