Rigorous AppSec - March 15, 2025

There was a blockage in the machine that turns my TODO list into newsletter content. It’s fixed now.

General Application Security

Google is Out-of-Date on Logout CSRF
Google’s Vulnerability Reward Program still lists logout cross-site request forgery as out-of-scope. I think this is a reasonable exclusion from a VRP, but their reasoning is not correct. They claim:

This is not the case. In fact, there are many conceivable mechanisms that could be used to prevent a distinct site from being capable of initiating a cross-site logout.

On their dedicated page for the issue, they go on:

OK, but this is also wrong? In the absence of other issues/vulnerabilities, a malicious website cannot arbitrarily drop cookies set from a distinct domain. Cookie limits are set per domain. Could you image how annoying this could be if any site could drop all cookies in your browser? To conduct such an attack across domains, you would typically need XSS as described here. If you have XSS, CSRF protections are defeated anyways.

Google also provides two additional sources. The first is this post from 2010. The post claims that logout CSRF is only ever an annoyance (I will address this shortly) and that it cannot be prevented anyways due to “Cookie Forcing” (this can and should now be mitigated, but was a fair concern when discussed in 2008) and “Cookie Bombardment”. Besides the obvious point that application do not have to actually use cookies to bind sessions, Cookie Bombardment depends on a trusted and malicious application sharing a domain. If this can occurs, it is a design risk that brings greater concerns than logout CSRF.

For the second post cited (also from 2010), logout CSRF is not addressed. Instead, the article details various cookie issues and limitations. I would guess that this was cited for the discussion on cookie jar sizes already addressed above.

So is logout CSRF only ever a nuisance? Well there exist now sufficient cases where this capability provides immediate utility to conduct attacks, so there is real risk. Should it be excluded from VRP and bug bounty programs? That is for the programs to decide, but they should at least be clear that it can be an issue worth considering.

I Wish I Could Say “No Thank You, SANS”
My GWAPT certification is coming up for renew in a couple of years. I already renewed it once and recently took the opportunity to review the course material, which takes the form of a few books/chapters containing printed slides and corresponding notes. For anyone considering this certification for themselves or as part of a training program, I can claim the following confidently:

1. The material is out-of-date, poorly structured, and generally of low quality. There are many essential topics that are completely absent.

2. I would NOT trust a GWAPT certified practitioner to effectively test even the most simple of web applications (assuming that is the extent of their expertise).

3. The certification is substantially overpriced compared to other opportunities to learn the craft.

Unfortunately, the following is also true:

1. The GWAPT (and SANS GIAC certs broadly) remains a staple across HR departments and organizations that don’t have the knowledge/capability to actually identify technical knowledge and skills.

As a result, I will unfortunately be renewing when the time comes. Congratulations to SANS in becoming a tax on the infosec industry.

CREST is Failing Application Security
SANS isn’t the only professional certifying organization that is behind on application security testing. Despite its effort to position itself as the global provider for standardized security testing certification, CREST’s application security certification is one of the worst I have ever seen. If you look at the current syllabus for the CCT APP certification, I am sure you will immediately agree.

The majority of the topics included are not particularly relevant or important for application security testing. Why would I want my app testing team to be learning about random network services or tamper seals when they could be learning something that would actually make them more effective application testers? Like many college courses I have seen erroneously labeled as “Web Security”, the syllabus appears to have been developed by a former networking specialist who has a passing knowledge of web security from 10 years prior.

Even the sample questions provided are… perplexing in their content and construction (though, to their credit, they are relevant to AppSec).

Oddly, the course actually appeared more application-specific just a couple of years ago. Of course, it was still a laughable program at this time, teaching Flash apps and Java Applets in the year 2023 (and presumably also omitting numerous essential topics).

I will give the CCT APP one compliment: I think the scenario component is a worthwhile inclusion absent from related certifications. Due to the other content covered, however, I am somewhat skeptical that this exercise is employed effectively and inline with industry standards and trends specific to application security.

If you’re looking for an application security testing certification for yourself or your team, the only one I can mildly recommend is PortSwigger’s BSCP. The certification is nowhere near what I would consider as comprehensive for application security testing, but it covers contemporary topics in practical environments and all training content is freely available for both self-study and for vetting.

Standards

OWASP ASVS 5 Is Coming
The 5th version of the Application Security Verification Standard is hopefully coming soon, but it’s never too late to dive into the issues to contribute. I have been fortunate to have been quite involved this iteration and I cannot recommend the experience of contributing enough as a means to advance your knowledge of application security and the construction of standards around it. Even if you’re just looking to brush up on a specific topic, searching the issues (including closed issues), is a great way to see discussion and debate across a wide range of contemporary AppSec concerns.

PCI DSS May Eventually Recreate the ASVS but Worse
With their DSS, and the effective evolution of the PA-DSS into the SSF, PCI is increasingly deploying web application security requirements and standards. Unfortunately, they are apparently doing this independently (and perhaps even in isolation) from existing application security standards. At the last OWASP conference I attended, I met a consultant who specialized in assisting organizations deploy controls to satisfy PCI DSS v4.0 requirements around payment script protection (6.4.3). He had never heard of the OWASP ASVS.

My prediction is simple: PCI will slowly converge on ASVS requirements but will never meet the same rigor. Why must PCI develop their own requirements? Why can we not just have one standard? Just use the ASVS! It’s right there! You can even pick which requirements you specifically want!

Sadly, the only reference to OWASP within the DSS is to “Open Web Application Security Project (OWASP) penetration testing programs.” It’s not clear what this even means, because there is no specific “penetration testing programs.” This is how I know they don’t enlist sufficient AppSec expertise and it’s why I am sure they will not create a better set of security standards than the ASVS.

AppSec Teams

Busy Season
We are right in the middle of our busy season at DBG. I find it challenging to deliver management insights when I am spending most of my time testing and having to delay other projects. I guess that’s the insight here.

Book Review: Leading Effective Engineering Teams
I had high hopes for this book. The book was written by a former engineering manager at Google, which has consistently marketed itself as taking an evidence-based approach to developing management best practices.

Here’s my review: it sucked, don’t bother. This book could just as easily have been a series of LinkedIn posts that I could scroll past instead of dedicating my limited reading time to (don’t worry; I didn’t finish it). There are very limited (if any) unique or novel insights that I took away and it is written in a way that felt like a series of truisms and tautologies. I brought receipts, of course.

I don’t have strong evidence that the writing of this book was assisted by an LLM, but it sure felt like. Either way, this feels very much like a book written to pad an influencer resume and not one that was meant to actually be read. And yes, this type of practice does occur.

Science and Security

Studying Leaked Secrets
I am always excited when empirical methodologies are applied to answer questions in application security (this is rare). If you have not read it, I would highly recommend this examination into the worst place to leave secrets. As with any research, you will gain the most from it if you approach it skeptically, considering possible limitations in the methodology and ways that it could be improved.

Connect

Respond to this email to reach me directly.

Connect with me on LinkedIn.

Follow my YouTube.