Methodology

As a penetration tester, you will inevitably find yourself involved in scoping engagements, navigating the challenges of aligning a client’s needs with their expectations. “Penetration testing” is a term that almost everyone believes they understand, yet it often carries vastly different interpretations. This ambiguity makes it more of an umbrella term, offering little insight into how the test will actually be executed or what it will cover. In this post, I’ll share my perspective on one approach to differentiating how penetration tests can be executed, helping both testers and clients clarify their expectations. ...

In my years of working as an application security (appsec) penetration tester I’ve come to the conclusion that there are so much more value to be added than pure technical vulnerabilities. To deliver the most value you have to be willing and able to walk the extra mile. Before getting into what can be done to increase the value, let’s dig into the two most common types of vulnerabilities. Technical Vulnerabilities The technical vulnerabilities are the most common vulnerabilities we see. This is where the application is abused to do something it shouldn’t, for example by injecting code or abusing weak cryptography. Even though the vulnerability is technical, it is important for the reporter to describe how it will impact the business. Otherwise the receiving organisation might not have enough of an understanding to prioritise the issues, and handle them accordingly. Even though a code injection can be used to pivot to other machines, the main impact for the business can often be linked to the confidentiality, integrity and availability of the application. As a tester it can be hard to accept, but a dom based XSS might be an accepted risk if the only impact is defacing the sight by pasting code into the searchbox. ...