More API Calls, More Problems: The State of API Security in 2024 – Lebin Cheng – ASW #276

A small part of the story is the back and forth about coordinated disclosure and a vendor's responsiveness. For me, the bigger part of the story is how Rapid7 crafted an exploit -- satisfying three seemingly random requirements of an unauthenticated request in order to reach an authenticated endpoint.

Check out the advisory from Rapid7.

Prompt attacks still feel like the new XSS -- a class of vulns where there's lots of discussion in the cleverness of exploit payloads and an unfortunate lack of focus on frameworks to eradicate the problem.

This article takes a fun twist, where the attack is based on using the ASCII art representation of a word that would otherwise be rejected or trigger a safeguard. The idea is that LLMs may spend more effort on recognizing the word in the ASCII art at the expense of safety checks.

Josh has been a guest on ASW a few times to talk about TypeScript and a developer's view of appsec. So it's not surprising that this blog post echoes a complaint that a lot of open source developers and developers dealing with bug bounty issues have with low quality reports.

Here's a nice example of secure by design that any project can benefit from because it has nothing to do with memory safety.

In the process of recreating sudo in Rust (yes, for the memory safety benefits), the Prossimo team got to the point where the codebase was relying on 135 direct and indirect dependencies. (Sure, those sound like amateur numbers to the Node.js world, but bear with me.) An initial 10 direct dependencies pulled in an additional 125 -- not the best situation when "supply chain" is the buzzword of the moment and everyone is talking about keeping dependencies up to date.

They succeeded in reducing the list to three crates. That makes the code far more maintainable, which is favorable for critical software that handles high-risk operations. It would be great to see more projects reduce their dependency count. Maybe this is even the kind of drudge work that an LLM can help with.

This article is really just about what to do with hundreds of millions of lines of C++ code. (I wish we had more secure by design articles that were about something other than memory safety -- there's a lot of secure design needed for apps written in memory safe languages!)

Rewriting sensitive areas of code into Rust can have ancillary benefits. As the blog points out for, "Chrome was able to move its QR code generator out of a sandbox by adopting a new memory-safe library written in Rust, leading to both better security and better performance."

In other words, a lot of the security patterns that evolved to deal with memory unsafe languages can be removed or adjusted. If you can achieve in-process security properties for handling untrusted data, then you can remove some security overhead like process separation and IPC calls.

We can scan for secrets after they've been pushed into a repo or scan the push before it's committed. Either way, a secret shouldn't be in code, but scanning the push itself is the smarter choice that focuses closer to where the mistake happens and reduces the secret's window of exposure.

A new memory safe language has entered the chat.

If you like the parentheses and arrows of OCaml, you might like Gleam. There's not much else to say about it at this point, but I wanted to mark its version 1.0 release in order to revisit it as part of our occasional "six months later" review.

In this fabulous thread between Chris Partridge, a moderator for r/cybersecurity and an anonymous contributor, the way of breaking into AppSec from scratch is discussed in detail, including ideas for projects, career path, and how to learn the basics of cyber. A great resource for those considering getting into Application Security!

"Hypervisor escape" are two very bad words to see together, in any hypervisor of significant use. In this case, VMWare seems to be providing clear, loud guidance in not just an advisory, but a fAQ for the vuln: "PATCH NOW." One of the interesting things in this FAQ is referring to ITIL I guess that's still a thing?

I found this when I was going down the YouTube foxhole of synthesizer videos recently, but besides being just a neat piece of kit, it got me thinking about something that I do occasionally - comparing something in software development (in this case, appsec) with something from a decidedly different world...

I may be reaching here, but on an instrument like this, the process of finding "The Sound" an artist is looking for is frequently...just trying things. That's a little like fuzzing, or an unfocused pentest. Or maybe a junior (ok maybe not junior) developer looking for ways to accomplish a business goal in their software. Looking at something with this "appsec lens" - what can we learn? Did they think about security when they built their product?

...resulting in 11k LOC removed from the kernel. But still it's not removing all sparc code, as some legacy CPUs are still using some of it. Pour some out for your old sun4m and sun4d systems.