Recently we undertook an engagement for a customer which clearly demonstrates the difference, I believe, between the different types of test. Too often customers pay for a penetration test and receive a vulnerability assessment and this particular test highlighted that difference. It is really hard to differentiate service offerings in this space – you can either join the race to the bottom on pricing or you can differentiate on quality, which is what we try to do.
The test was on an educational platform with three levels of user – pupil, teacher and administrator.
During our testing we discovered a relatively common vulnerability known as Cross Site Scripting or XSS. From the OWASP page on XSS :
“Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.”
We have seen multiple reports given to customers from previous tests with generic XSS findings, nearly always accompanied by the typical XSS evidence showing an alert dialog popping :
More often than not, in the reports we have seen, the finding is verified and evidenced and the tester moves on to the next finding. Quite often we have seen these issues pulled out as not being too severe due to other mitigations that would prevent something like session hijacking where the target victims’ cookies could not be stolen due to correct cookie security configurations.
Having spoken to the client in depth prior to starting the test, it was clear that one of their primary concerns was ensuring the academic integrity of the platform, meaning that pupils should not be able to interfere with the application in any way.
So for this client we have a serious vulnerability – but how do we translate that into client specific findings that will allow them to easily present the issue to other business areas and obtain budget and buy in to be able to remediate the issue?
We deep dived into the issue to demonstrate an attack path that spoke directly to the client’s concerns by chaining multiple issues together to achieve a complete platform takeover from the lowest possible user role. It took a few hours to get it to work having to bypass some input length limitations, bypass the basic XSS defences the client had, create a fully functional payload to re-write the HTML of a page and mimic a POST request to the CreateUser endpoint complete with correctly formatted JSON but that extra effort gave the client exactly what they needed to address the issue.
Alert('XSS') is so much easier
This meant that the client was able to present the findings directly to the stakeholders involved and not have to worry about the issue being lost in technical details or wordy hypotheticals. A solid, reproducible, well evidenced vulnerability was proven to exist.
That’s the difference we are trying to achieve here at Cybaverse, not just sending a report out based on an automated tooling’s findings, but listening to our clients and ensuring that the report is tailored to their requirements. The output we provide should be actively useful to the client rather than a just list of findings from a tool and recommended remedial actions.
And that is what occurred to me during testing. I am sure that the majority of tests performed against this platform would have simply highlighted all of the same vulnerabilities that we discovered (we don’t have any secret sauce for testing, just effort and skill), but would have failed to contextualize them for the client. We are security partners for our clients, not just a one-time deal, thank you for your order, here is your report and invoice. That means we have to take the time to understand not only the technical requirements for testing such as scope but also the business requirements. Without understanding the latter, we cannot produce output that is relevant and targeted for the client.
And that is the Cybaverse difference.
Get in touch to find out how we can make a difference to your business
