HTTP RFCs Have Evolved, Breaking Into Cloud, Scaling AppSec at Netflix, & Confluence – ASW #200

A few things to think about when reading about bug bounties is understanding the mindset of researchers as they reason through possible threats for a specific technology and how those discovered flaws might manifest in other implementations. Generalizing this article a bit, we see flaws in OAuth, protocol analysis (DHCP), and SQL -- technologies both well-established and common among applications. At the very least, reading about these kinds of vulns helps us broaden our threat models. At best, we'll identity flaws or adapt hardening techniques that make these flaws less likely to happen. OAuth is very common in modern web apps and a good topic to become an expert on. Check out the write-up on "Bypassing Identity-Aware Proxy" at https://www.seblu.de/2021/12/iap-bypass.html

HTTP/3 has officially reached standardization. For the most part, this is likely to have little security consequence for the app layer and the common flaws we see in top 10 lists. Plus, it's the migrations to new protocols where subtle implementation differences often become security issues. We've already seen how HTTP Request Smuggling has manifested in HTTP/2 to HTTP/1 interfaces. And there's sure to be some surprises in the state management associated with the HTTP framing layer. But there are also positive improvements like the underlying reliance on TLS 1.3. If anything, moving to HTTP/3 may be the chance to improvement certificate management throughout your org. Check out RFC 94114 at https://www.rfc-editor.org/rfc/rfc9114.html

This article isn't specific to appsec and, even though Phil Venables is best known for his work in building large, effective security teams, the concepts easily apply outside of infosec. It can still be informative to read through the lens of appsec. One point, "You always underestimate your impact (positive and negative) on others," speaks directly to the importance of collaboration between appsec and DevOps teams. Another is "big moves" -- ideas that require many years to execute, but that can have significant impact. This latter point is a great way to evaluate the difference between educating developers on XSS vs. adopting a framework where XSS is difficult to introduce, or the benefits of investing in Infrastructure as Code (or perhaps anything as code) where secure defaults become the norm as simple linters can identify critical misconfigurations.

This article has an importance premise for cloud security -- start with an understanding of the engineering concepts within cloud environments. It has some useful links to further resources as it highlights a progression from cloud concepts to cloud security concepts to finding a specialization. And as the appsec industry continues to talk about concepts like "shift left", this is a good reminder that cloud security can be a specialization itself on top of the IAM, compute, storage, and network concepts that are foundational to cloud environments. In other words, there are several dimensions to security and developers need tools, secure defaults, and opinionated guidance (aka paved roads) in order to be successful.

Yes, I'm still trying to make fuzz happen. This project is part of the larger investment to secure the open source ecosystem by using automation to identify flaws. From a more general engineering perspective, it's a good example of evaluating the effectiveness of tooling and identifying ways to improve it. In this case, the team is taking examples of critical vulns that fuzzing missed and, rather than just fix the specific areas of missed coverage, attempt to build a mechanism that can show how to improve coverage and fuzzing harnesses for any target. This is a similar strategy to dealing with bug bounty reports. You can address the individual reports, which would immediately address some known risk. Or you can put in the effort to find similar instances of the reported bugs throughout your code base, fix those, and then consider how to address the underlying problem itself. This speaks to the sort of "big move" idea that ties into the career advice article this week from Phil Venables. The two brief case studies are at https://github.com/ossf/fuzz-introspector/blob/main/doc/CaseStudies.md

This article ties together the other engineering and career advice topics we highlighted this week. It's interesting to see how the team has shifted away from general self-serve guidance into more opinionated defaults and automation. It doesn't sounds like the implication is "do what security says", but something more like "here's a secure way to accomplish this task" that's followed by engineering work from the appsec team to make that task more developer-friendly. The evolution hasn't thrown away practices like security reviews and providing guidance, but it certainly seems to be investing more into the shared responsibility of engineering solutions. In other words, security has a shared responsibility to build software.

If you heard "upcoming RCE in Java" and guessed OGNL, then you've probably been paying attention to Java vulns for the last few years. Atlassian's Confluence had a pre-authentication RCE vuln, which is basically a worst case combination of words in appsec. This write-up walks through how relatively simple the exploit is in terms of payload and being able to observe when it succeeds against a host.