The vulnerabilities we’ll be looking at in this chapter don’t require any technical expertise. Instead, they just require us to have the right mindset. (Or actually the wrong mindset, the one we mentioned in earlier chapters: thinking like an attacker!)
Report Dangerous Features
During a penetration test, you may come across features that you feel are dangerous.
This is the famous:
“It’s not a bug; it’s a feature.”
This was a joke originally used to mock software companies who failed to recognize bugs in their products.
Here’s Remi Gascou, our guest pentester on this course, sharing an anecdote about what he did when he came across a dangerous feature one day while auditing a client’s system.
Like Remi, it’s your responsibility in these situations to report to the client what falls under:
the business side (for whom it’s more likely to be a feature).
the security side (for whom, like for you, it may be a vulnerability that needs to be corrected).
Let’s return to our example.com application.
When we checked access control reliability (particularly horizontal access control), we realized that doctors from any specialty could access any patient’s medical records, even if the patient wasn’t theirs. However, when we first met with Mike King, the CTO of example.com, he made it clear that protecting patient data was paramount. This means that we absolutely have to report this issue. And we’ll have to discuss it at the closing meeting.
Identify Flawed Features
Here’s another example, from personal experience, which falls under the heading of “uncategorizable” vulnerabilities. I was testing a bank’s in-house web application whose sole purpose was to securely display confidential PDF files to prevent or limit the theft of these documents as much as possible.
I began my test, opened the first document, and found that the interface looked very familiar. It was essentially the same interface you see when you open a PDF file in your browser, as shown below, but without the Download and Print buttons.
I said to myself: “That’s odd, this feature normally uses JavaScript. How do they keep the files confidential?” I checked my proxy, and it confirmed my fears. That is, the file was sent directly to the client in binary format and then displayed using JavaScript.
So, the application just sent the file in its entirety to the browser, in PDF format, making it fairly easy to retrieve by intercepting the request. Attackers were able to retrieve the files—precisely what the application was supposed to prevent! All that remained for me to do was to call the client and report that the pentest was pointless, since the application, by design, could not meet the requirements. Talking to the developers, their response was, “You can’t download or print the file since we’ve removed the buttons. We’ve therefore met the requirement”. I’m simplifying here, but that was the developers’ line of defense. As far as they were concerned, they had met the specification.
Adel and Remi have also come across some rather flawed features while auditing applications.
Let’s finish by checking regulatory compliance, particularly as it relates to obtaining user consent.
Check the Web Application’s Regulatory Compliance
We’re not going to come across any technical vulnerabilities here that might compromise the application, but this is something I’ve made a habit of checking as it can put the application at risk.
We are not lawyers, and this is not a digital law course. I will therefore base what I say on regulatory texts to:
avoid any misinterpretation.
be as evidence-based as possible.
highlight what is important to look at and note as a pentester.
So, let’s focus on what technical contribution a pentester can make to checking compliance with the main legal requirements (rather than on what this or that type of application must contain).
To carry out these cookie-related checks, you can use one of the following options:
Look at when and how cookies are set through Burp’s history feature.
Use a tool, such as a browser add-on, like Cookie Quick Manager in Firefox.
Use your browser’s development tools, as in this screenshot:
Directory listing vulnerabilities are not inherently dangerous, and I won’t be covering this weakness here in this course since it’s more of a configuration error than a technical vulnerability. But if they allow access to sensitive data, your client will want to know that their data is in the public domain!
Before wrapping up, I thought it would be a good idea to share some stories of penetration testing failures—because they do happen, even to the best of us.
Let’s Recap!
Not all vulnerabilities require imaginative solutions or need you to link three new techniques to bypass two security countermeasures. The reality is often much simpler, and sometimes legitimate business features are actually vulnerabilities, at least from a cybersecurity perspective.
You need to understand the business using the applications you’re testing so that you can figure out what’s important for the application. You also need to step back from your findings or tests to pinpoint the risk scenarios that have the greatest impact.
It’s good practice to take a few minutes to check that your client is complying with standard regulatory requirements, especially when it comes to cookies and obtaining consent. Your client will thank you for helping them avoid a fine from their local data protection authority!
We’ve finished our testing and have our findings. It’s time to move on to the stage that auditors usually like least, but which is just as necessary as the testing: formalizing everything and reporting the results to our client. Let’s get started!
