What’s the Deal with API Security? – Sandy Carielli – ASW #243

Two weeks after we do an episode on top 10 lists there's a new top 10 list.

Unsurprisingly, it has prompt injection. It's nice to see it include alignment in the list (cue the D&D references). It also has some more generic entries like SSRF and error handling.

After glancing at the list of vulns reported, my first thought was how old is this codebase? Looking at the release notes it doesn't seem very old, maybe a few years. But the vulns seem like a few decades out of place.

How much of this is due to an SDLC that has skipped over modern tooling and frameworks?

I mostly avoid Wordpress-related vulns. The core codebase tends to be secure, but the plugins get messy fast.

This one is a plugin, Jetpack. It caught my eye because a vuln was discovered during an internal audit by the team (that's good!), but the vuln has been present since 2012 (that's not as good!).

I'd be far more curious about what the discovery process was for this vuln. Why now after 10+ years? Was it a matter of improved security tooling? A fresh set of eyes? Awareness of a new vuln class? Hearing about how the team found the vuln might have lessons for others looking at long-lived codebases.

Protecting packages starts with stronger authentication for accounts managing packages.

Python had additional news recently:

• Novel PyPI Malware Uses Compiled Python Bytecode to Evade Detection
• PGP signatures on PyPI: worse than useless
• Removing PGP from PyPI - The Python Package Index

This gets a mention because of path traversal. It has a simple POC as well: https://github.com/Occamsec/CVE-2023-2825

I wanted to look at the vuln to see what the fix is like since that's often a chance to talk about secure coding. GitLab won't show the details on their issue tracker until after 30 days, so we'll have to wait a bit longer.

Although there's another path traversal on the issue tracker that's fixed by a call to Gitlab::Utils.check_path_traversal!(file)

So maybe there's something to be said for running a linter or code scanning tool to find similar patterns.

Thinkst posted their latest research report. It's been a light quarter from their view -- only about 1,500 blog posts and 700 presentations to go through.

A few items to check out are

• “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection” -- especially in light of the LLM Top 10 we talk about this episode
• “Server-side prototype pollution: Black-box detection without the DoS” -- which we talked about in episode 230
• “Why I write my own security tooling” -- to emphasize the learning reinforcement of hands-on development and, equally important, documentation
• “Finding 10x+ Performance Improvements in C++ with CodeQL” -- the examples are specific to C++, but the concept could generalize to other languages and is important to highlight as an example of how security tooling provides even more value when it helps other developer problems like performance

This is a fun way to learn some basics of variables represented in memory by C programs. You don't even need to write any C code yourself. Walk though some of the examples for a visualization of values in memory.

And if you enjoy that, check out Implement DNS in a weekend as a way to learn programming and protocols. One of the best ways to reason about a protocol is to try and implement it. You'll discover areas of ambiguity and perhaps even design flaws that can lead to interesting vulns. But in any case this kind of hands-on project is great for learning a language a well. Try it in Python, Rust, or Go!

Informative walkthrough of Burp's new API and using it to make pentesting more effective.

No, don't use these passwords. Yes, do have fun with the site.

Also, why isn't more security awareness fun like this? It's doesn't need a retro style (which is pretty awesome, btw), but it should have something more appealing than bullet points and language from top 10 lists.

Then check out the rest of the "Top Gun" soundtrack.

Counting's hard, mmmkay?

I won't lie - "Firecracker" in the title clickbaited me. But as I read through this, it occurred to me that while I appreciate a good long detailed writeup about a vulnerability, the writeup to do something securely is often just as long.

And basically all of us have to "do something securely."

This story has been making the newsletter rounds over the last week or two. I wouldn't cover it, except as with the Firecracker and Pinterest stories I'm posting...it takes a lot of work.

I guess for this blog I figured since they were using their own software, it wouldn't be that hard?

It's like we've learned nothing from the "Just recompile your kernel. It's so easy." meme.

Bcrypt turns 25 this year. Thanks for all the fish!

It's refreshing to see a package maintainer realize that their software shouldn't last forever, and that once was state-of-the-art might not be the best way to secure things over time.

We don't have to stop using it today, but no time like the present to think about when should we stop.

One of these password safes is safe. Let me know when you figure out which one it is, k?

This one's also making the rounds over the last week or so, for good reason.

Please encourage your vendors to sign on and stop with the silly security awards. We have more serious things to make fun of.

A blog post on pgp signatures for pipi packages - they're not verified, sometimes expired, sometimes badly created. Weakest link, and all that.

But it makes me wonder if something as complex as PGP provides value for open source packages in general in 2023?

As with the Bytewax story - it's interesting, but not something one does easily.

Don't get me wrong - this is a great article that dives into the data science/modeling aspects of trying to do anomaly detection right, at scale. This is a great example of when one hears somebody say "oh just use machine learning" - that stuff ain't easy.

ML/AI is important, where we're going in the future, and really what's probably going to allow us to get our jobs done. But if a vendor (or coworker, or manager) does the "it's so easy!" thing - push back.