Read on Twitter
Based on a question from @hakluke on how the @OWASP_ASVS might be used with bug bounties, here's my approach
First up what is the ASVS?
It's a list of application security requirements or tests that can be used to test and verify secure applications.
First up what is the ASVS?
It's a list of application security requirements or tests that can be used to test and verify secure applications.
There are 14 different categories of which one could use to test and indeed build secure applications, ranging from architecture through to configuration management https://github.com/OWASP/ASVS/tree/master/4.0/en
At the start of each section is the control objective (what is it you are looking at, what is the aim)
Then we have the checks. For example, session management
It ranges from basic to advanced, in this case here are some basic cookie checks that all sites should have
Now @hakluke did say he felt that the bulk of checks in ASVS wouldn't be accepted on a bounty program and I disagree
Let's take this post https://www.bugcrowd.com/blog/these-are-the-bugs-you-should-look-for-in-late-2020/
Listed are:
Cross-Site Scripting
SQL injection
Sensitive Data Exposures
Access Control
Listed are:
Cross-Site Scripting
SQL injection
Sensitive Data Exposures
Access Control
They are all in the ASVS and have been for a long time
XSS - https://github.com/OWASP/ASVS/blob/master/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md
XSS - https://github.com/OWASP/ASVS/blob/master/4.0/en/0x13-V5-Validation-Sanitization-Encoding.md
SQLi/XPATH/XML hell any damn input and output validation flaws are all listed in V5, along with references we felt were useful in testing and fixing.
if you need to run a tool, don't just blindly run sqlmap, understand *what* it is you are looking for first.
if you need to run a tool, don't just blindly run sqlmap, understand *what* it is you are looking for first.
So let's say you are testing for authorisation flaws in a new app and want to look for possible Out of Band (OOB) flaws.
We got ya covered and yes, most apps are vulnerable to these in some form or manner.
We got ya covered and yes, most apps are vulnerable to these in some form or manner.
So what I'd do, and indeed still do as I find a lot of bugs and have been doing for decades now, is understand what constitutes a secure web application in 2020.
I'd then use the list, we've made you a CSV format so it's easily parsable using automation
I'd then use the list, we've made you a CSV format so it's easily parsable using automation
Now Level 1 (which we feel is the bare minimum for any app today) is mostly all scriptable. So you could create a tool that rips through the checks in https://github.com/OWASP/ASVS/blob/master/4.0/docs_en/OWASP%20Application%20Security%20Verification%20Standard%204.0.2-en.csv and finds low-hanging fruit
I think the key thing here is that bug bounty hunters aren't finding new unheard of bugs in web apps often. These are pretty old bugs that we found at the turn of the century, and even though some names might have changed like IDOR https://hackerone.com/reports/227522
That was access control bypass years ago, but the idea is still the same
So hopefully this shows how you can use the ASVS to find bugs, along with other reference material in how to test for them manually (OWASP Testing Guide, cheat sheets etc)
Happy to explain more if needed.
Happy to explain more if needed.
One thing I find incredibly helpful when hunting for bugs, which I do often, is for me to perform a threat model against the target. Sure, it is slower than just hammering it with a tool(s) but I get to work out where the potential flaws are whilst my foot printing phase runs
