Many pentesters and application security professionals talk about what they do but often, unintentionally, fail to provide detailed insight into what they do. For aspiring professionals, this is very frustrating because they don’t care about the 5 five phases of pentesting or OWASP Top 10. They want to see what professionals do in their day-to-day job, they want to know the details because that is the best way to learn and understand what it is all about.
Thus, with 55 application security assessments and pentests in 2022 alone, let me share with you some inside information.
First, how do I get so many assessments? It has been through networking and talking to people in the field. The fact that I post about security on my Youtube channel and I have a presence (I post frequently) on Twitter and Youtube helps a lot because I get an ongoing flux of opportunities via these channels.
Second, how much time do I spend on an assessment? It is usually between 15 to 30 hours. And I get very flexible deadlines.
Third, there are a small number of vulnerabilities that I encounter in at least 90% of the projects. These include:
- issues with the authorization token JWT — leaking too much information
- lack of best practices for cookies and security headers
- information leakage via headers (i.e. Server: IIS 10.0)
- token invalidation upon logout
- lack of rate limiting on login enables bruteforce
- bypassing browser-level input validation
- and more.
As soon as I have many of these low-hanging fruits cleared out, I look for more serious issues. I follow and look for vulnerabilities according to the OWASP Top 10. And once I’ve gone through them, I like to focus on authorization and access control issues.
And in the overwhelming majority of cases, I find at least 2–3 such critical issues. The impact of these issues is very significant because it leads to unauthorized access to sensitive information.
The very basic idea of me testing for authorization and access control issues is to create multiple accounts with different roles and cross-testing in Burp Suite in an IDOR style. I won’t go into details here because if you’re reading this, you should know what I’m talking about.
Most of the time I spend on an assessment is doing manual testing and using Burp Suite extensively. I do JS code review and test for input validation where it is the case. There is very little to no recon or automation unless the target is very big or the client has some special request.
The final thing that I want to mention is about report writing. Given that some of the low-hanging fruits are found in most of the projects, that is a matter of copy-pasting from past reports and adapting to the context. On top of that, I will add the unique vulnerabilities. And at the end of each vulnerability, I will recommend a fix. I fill in the report as I find the vulnerabilities.