It's that time of year again! At Report URI, we've just been through our 5th penetration test, and as usual, we're going to publish the results, take a look at what was found, and what we're going to do about it.

Penetration Tests

We're racking up quite the tally of penetration tests now, with 5 years of testing history on show! You can see our tests from the previous years here:

Report URI Penetration Test 2020

Report URI Penetration Test 2021

Report URI Penetration Test 2022

Report URI Penetration Test 2023

Along with those, you're of course looking at our 2024 test and, if I do say so myself, we've had another good year and the results are awesome. Despite continually building and developing the product, introducing countless new features and new code, our efforts in security are paying off when it comes to being scrutinised.

The Results

Here's the summary of our 2024 findings, with only two low-rated issues showing up!

Neither of these issues of anything for us to worry about, of course reflected in the Low Severity rating, but they are worth talking about.

Vulnerabilities in Outdated Dependencies Detected

This one I knew was coming and is something we were already actively working towards solving. The problem is an XSS vulnerability in the version of Bootstrap we're using, which was assigned CVE-2024-6484 and Medium Severity. Taking a look at the details, and the provided PoC, it seems that the issue is if you let an attacker inject arbitrary content into HTML attributes, including the href, they can execute arbitrary JS. Here's the PoC code...

Now, Bootstrap or not, I'm pretty sure if you let an attacker inject a javascript: URI into the href attribute of an <a> tag, then you're going to have XSS one way or another, no? Maybe I'm missing something in the nuance of this, and if there's somebody out there who can explain this to me, please drop by the comments below, or email me! There were also two other issues found that were very similar in nature, CVE-2024-6485 and CVE-2024-6531, and I'd love some feedback on these similar issues.

Either way, we're not really concerned about these issues because we don't use the impacted components of Bootstrap, we don't take user content and reflect it in to page in this way, and, of course, we have a Strict Content Security Policy in place. These reasons are ultimately why this issue was rated as a Low severity finding in our report, but we're still going to fix it.

By the end of the week, we should have our patched version of Bootstrap deployed, which is the road we've decided to take as a short-term measure due to the work involved in moving to v4 or v5 at this time. It solves the problem, completely removes the risk, and comes at a relatively low cost for us, so it's a nice solution.

No Anti-Automation Protection

This one is a non-issue for me because, as we always do, we disabled all of our Cloudflare protections for the origin IP addresses of the penetration testing company during the test. This allows them unfettered access to our application and means they're actually testing our application, rather than the effectiveness of whatever WAF solution we might be using.

Part of that protection that was disabled was things like our WAF Rules, Bot Management, Rate Limiting and everything else we have configured with Cloudflare, so, there's no action required here from us.

Another Strong Year

As we approach the end of the year, our penetration test is a way to validate all of the hard work we've put in throughout the year, and goes to show that the processes and measure we have in place continue to be effective.