OWASP Breach, Types of Prompt Injection, Device-Bound Sessions, ASVS & APIs – ASW #280

Two big lessons stand out to me from this breach.

One, OWASP explains that it "...collected resumes as part of the early membership process, whereby members were required in the 2006 to 2014 era to show a connection to the OWASP community. OWASP no longer collects resumes..." This implies that the data was kept around for the past 10 years despite being of no importance and that they made the active decision to stop gathering resumes. Even better than encrypting data is deleting it in the first place -- deletion removes the liability and burden of having to protect the data. There was a big process failure here.

Two, even security-minded orgs make mistakes. You can have all the awareness you want, but if it's not backed by processes that exercise that awareness in practice, then it's just relying on random people to randomly remember to do something. Even better is having tooling that enforces and controls that process. A retention policy combined with an automatic job to delete data would have helped immensely.

This is a nice summary of classes of attacks against LLMs. Establishing a shared terminology makes discussions about threat models, countermeasures, and risks more efficient since everyone in the conversation can be starting from similar assumptions.

For example, it's more useful to understand specific vectors of prompt injection in order to evaluate whether a defense is effective. A jailbreak and a prompt leak require different defenses.

Yes, authentication solutions like passkeys, WebAuthn, and FIDO2 are phishing-resistant and the modern mechanism that all orgs should adopt.

But there's still a catch. The post-authentication process typically assigns a session token to identify the user for a period of time. If that session token is compromised, such as by stealing cookies, then an attacker may be able to impersonate a user by merely presenting that cookie. The server assumes that the user presenting the cookie is the original user who went through the identity check during authentication. This is the type of attack we saw against Twitter and Uber, where Slack session tokens were compromised, thereby enabling an attacker to impersonate a user and gain more privileges through social engineering.

By binding the cookies to a device, this replay attack becomes more difficult -- the attacker would essentially have to proxy their traffic through the victim's device, which may be more technically difficult and more prone to detection by network or endpoint monitoring.

This discussion thread shows the challenge of translating a single sentence into a design and implementation.

Item 2.10.1 of the ASVS states, "Verify that intra-service secrets do not rely on unchanging credentials such as passwords, API keys"

So, what should intra-service (aka service-to-service or s2s) authentication look like? Is mutual TLS an unchanging credential, but nonetheless secure? Is the spirit of this requirement really about an unchanging password or about the ability to easily rotate passwords? Is the spirit of this more about using authentication mechanisms that don't expose the secret, such as using a signed request instead of a raw API key?

Ivanti is having their Microsoft-in-the-early-2000s moment of repeated security lapses followed by a call to action from their CEO. (Check out some of the Microsoft history in last week's April Fool's news segment.)

Read Ivanti's statement here.

It has some nice sentiments, like "Alleviating the Burden of Security for Customers: We will be enhancing our capabilities to provide solutions that are secure out of the box (Secure by Default)..." We'll see how these manifest in practice.

It seems about 20 years late for a security company to be listing off actions like this, though. It's an unpleasant reminder that security products can weaken your environment by increasing the attack surface you need to defend.

A super-short article that helps clarify some OAuth terminology.

I can never resist a protocol-based attack. The impact here is a DoS, but one that can be very asymmetric -- the attacker needs few resources to exhaust the target.

Check out this post for a table of affected software.

Specification documentation is hard! This is an implementation issue that the HTTP/2 spec sort of cautions against, but not explicitly so. Check out episode 266 for a discussion about RFCs and the importance of documentation with Heather Flanagan.