Another year of development, new features, bug fixes and progress has been made so that means it's time for our annual penetration test over at Report URI!
Penetration Tests
As is tradition, Report URI has just undergone another penetration test and we will be publishing the report, in full, for all to see. I started this tradition back in 2020 and our 2021 report is also available. You can read the 2020 post for details on why I publish these reports, and how we approach a penetration test, but transparency is a key component.
As with previous tests, there were no artificial restrictions placed on the scope of the test and the test lasted for 5 days. We also provided our source code to the tester not for a full source review, but so they could move more quickly during the test and potentially identify more issues.
The Results
Having made an improvement on our results from last year, there were only a total of 3 issues reported on this test!
I'm really pleased with the outcome here, and I will go into the other measures we took to help the tester find as many as possible, but for now, let's review what was found.
5.1 Vulnerabilities in Outdated Software Detected
I have to hold my hand up on this one, it was a genuine find. We were using jQuery-ui v1.13.0 in the account section of our site and that version does have a known vulnerability (CVE-2022-31160). The good news is that the tester confirmed we did not use the vulnerable function, and I confirmed the same, so there was no risk present. Of course, the library still needed to be updated, and it was updated immediately during the test, but I had a bigger question. As the tester pointed out:
A GitHub workflow already existed to detect outdated JavaScript libraries. This is the recommended approach to prevent outdated JavaScript libraries long term.
Turns out we had a small oversight in our JS dependency scanning and some of our account section scripts were not being analysed. This goes to show the value of having an external penetration test as we'd likely not have found this otherwise. The issue with our dependency scanning is now resolved and all of our JS libs are being checked.
5.2 Account Enumeration
Both of these enumeration vectors have been raised before and it's a tough call to fix one of them, while the other is purely a convenience feature.
You can read our 2021 report (deep link to the right section) for details on these two vectors and my response to them. It's a lengthy paragraph so I won't duplicate that here!
5.3 Server Side Request Forgery (SSRF)
We did have SSRF raised in our 2021 report (deep link), but this time around it's slightly different. The issue raised in 2021 was fixed and this one is simply an 'Informational' finding.
Our Tools generate HTTP requests from the server by design in order to scan external websites and the tester had the following to say:
Report URI offers several free tools which allow an attacker to control a URL that is requested by the backend server. These are available without registration, some do not have CSRF tokens, and none implement CAPTCHA technology. All of these are protected by rate-limiting technologies which would discourage heavily automated use.
No access to internal resources was found on this occasion. There remains a potential that Report URI’s service could be abused to send DoS traffic to third party hosts. This may impact Report URI’s reputation if done.
The point in the first paragraph there was correct in that CSRF tokens weren't implemented on all of our tools pages. Even though the tools are publicly available and authentication isn't required and doesn't provide any benefit, we've still added CSRF tokens to all Tools pages. It's also correct that we don't use reCAPTCHA on the Tools pages, opting to only use that on our registration page. Instead, we depend on our rate-limiting and bot protection provided by Cloudflare to ensure that these pages are not abused and as the tester stated, the issue from our 2021 report did not re-occur. I'm happy that this doesn't need further attention from our side.
Help the tester!
I said this back in my 2020 blog when I published our first penetration test report, but you want to do all you can to help the tester find as much as they can in the time allotted. Slowing a tester down simply means they won't find issues, not that you don't have issues! There's a big difference. Here are some of things we do to maximise the value of our penetration tests.
- Allow the specified IP addresses of the testing company through our WAF. This allows them to directly test the application without rate-limits slowing them, without WAF rules hiding issues in the application and without any other interruption.
- Provide our source code so the tester can investigate, test and explore issues quickly and thoroughly.
- Made an 'information pack' for testers that contains example payloads for all of the report types we ingest so that they don't have to spend any time figuring that out.
- Create a coupon code to get 100% discount at checkout so they can fully exercise our payment flows and all associated logic in the application.
- Have a staff member available throughout the test for any questions that may arise so the tester isn't waiting around for answers.
Even with our efforts to maximise the value of this test, I'm pleased that we still had so few issues turn up in the report and here's to another good result! As always, the link to the PDF report is below and the link in the footer of the Report URI site has also been updated to provide this latest version.