WebSocket Hijack, Post-Quantum Side-Channel, OWASP’s Future, OAuth Misconfigs, ZAP – ASW #231

Snyk shares some clever WebSocket hijacking in a CDE -- a cloud-based IDE. It might be the first WebSocket vuln we've covered, too.

The appsec angle in this that appeals to me is what controls a public package repo can create to minimize the impact of attack classes like typosquatting or even just mass creation of packages. Typosquatting isn't specific to PyPI. The article talks about the verified namespaces used in the Java world as one countermeasure.

Side channel attacks are cool ways to leak information from a cryptographic system. They're often more about targeting the engineering and implementation of an algorithm as opposed to its design.

It's an area with subtleties where toolchains can introduce flaws in otherwise secure code. For example, constant-time string comparison is a common cryptographic need. And it's something that developers have to implement and review carefully because compilers love to optimize code -- and optimized code might introduce time-based side channels.

Also check out this article, which includes comments from NIST that indicate the attack doesn't appear to be a fatal flaw in the algorithm's design.

In the meantime, see how long it takes to upgrade your org's web footprint to TLS 1.3 and HTTP/2 (or, even better, HTTP/3). It's important to be prepared for new attacks, but there's a far more pressing reality of adopting new protocols in the first place.

More discussions about OWASP, with a desire for where it should head and a highlight on what it does well. It also points to the success of other projects like OpenSSF in order to figure out OWASP's future.

I like how it points to the cheatsheet series. Those have always been more interesting to me than the Top 10 lists. They're more actionable and more consumable for devs and appsec teams. One of the key decision points for OWASP may be to figure out who they should be serving and how best to do so.

This article gives a nice, non-technical overview of OAuth authentication flows. Read it for that info alone. It also goes into flaws the researchers discovered in apps that mishandled redirect_uri parameters, enabling attackers to get servers to leak OAuth codes (the Authorization Code grant, a one-time value that the user exchanges for an access token).

Regardless of whatever intelligence it has, ChatGPT has surely won the marketing campaign for AI over the last few months. Everyone likes talking about examples of ChatGPT giving humorous responses, naive responses, and even appsec-oriented responses. And there's a fun game of prompt injection to probe its boundaries. But all those conversations are quite varied and don't share much consistent terminology when talking about security and privacy issues.

This work from NIST helps guide those conversions. It starts with a framing of AI risks that covers far more than appsec concerns, while still giving a way to talk about appsec concerns like impacts on phishing, malware, impersonation, and creative uses I'm sure we'll start seeing a security conferences soon.

Check out the PDF.

ZAP is the other web proxy that's a go-to tool for bug bounty researchers, pentesters, and other appsec folks. It's open source, supports extensions, and has active development.

This is almost a BSW/ESW article, but I felt there's value in us - as appsec or software engineers - to think about the parallels to the automotive industry, and how our orgs will handle creating a "standard of care"

Good timing on this one - Last week we talked about the SSO tax and I asked if it was acceptable to charge for audit/security logging. audit-logs.tax says, yes, but more interestingly to me it discusses what should be in good audit logs, and how they're different than system logs.

There's nothing super exciting in the article itself - a few more lame basic vulnerabilities.

But...it does make me wonder if known vulnerabilities affect the price of devices like these on ebay and similar?