Engineering Blog
BackInsights from a Professional Third-Party Penetration Test
At cloudscale, we take security very seriously. Our approach includes rigorous code and architecture reviews, extensive automated testing, and leveraging battle-tested open-source frameworks like Django. For a recent external penetration test in the context of our ISO certification, we engaged a specialized provider to examine our Control Panel and API for potential security vulnerabilities.
We provided the penetration testers with access to the source code and several dedicated test user accounts, giving them as much access as possible to help them identify any weaknesses. We are satisfied with the overall results of the test, reflecting the robustness of our services. As expected, there are always opportunities to learn and improve, and we've identified areas where we can further enhance our systems, which we have promptly addressed.
XSS in the Login Form
Let us start with the most critical finding.
After user authentication, our code executed window.location = variable to redirect users to a predefined page.
What we overlooked was that window.location accepts JavaScript URIs, creating an unexpected cross-site scripting vulnerability.
While we assumed the worst-case scenario would be users landing on unintended pages, attackers could actually exploit this by setting values like this:
window.location = "javascript:alert('xss')"
The penetration testers demonstrated how crafting a malicious URL and sending it to legitimate users, and hope that he logs into our control panel using that link could execute code after authentication. This experience serves as an important reminder that even seemingly innocuous code patterns can harbor significant security risks.
We fixed this vulnerability in less than 24 hours and conducted a review of our logs to ensure no signs of exploitation were present.
Outdated Dependencies
Providing the source code allowed the testers to examine our dependencies in detail, uncovering several vulnerabilities related to known CVEs with recent fixes. Fortunately, we use Renovate to automatically keep our dependencies up to date. Our self-hosted Renovate bot continuously monitors for new CVEs and creates merge requests as soon as patches are available.
As a result, the vulnerabilities identified during the test were already addressed before the report reached our inbox.
Proxy Headers
Another feature that immediately caught the attention of the penetration testers was the Custom Image Import functionality. Instructing our servers to download content from “any” location seemed suspicious to them, we suppose. They discovered that our forward proxy, through which our internal systems perform downloads, included X-Forwarded-For headers that contained internal host names. Additionally, the versions of the requests and similar libraries were revealed.
As a consequence, we have disabled these headers in the meantime.
Staying Vigilant
External penetration tests are invaluable for uncovering blind spots and reinforcing security practices. While we are satisfied with the results of this test, we know that maintaining security is an ongoing effort. That is why we have also added a .well-known/security.txt file to our website, making it easy for security researchers to find contact information for responsible disclosure. A big thank-you goes out to Sebastian Pipping for nudging us to implement this.
If you host a site or service, we highly recommend adding a security.txt file as well. It is a simple but effective way to facilitate vulnerability reporting.
Stay safe!
If you have comments or corrections to share, you can reach our engineers at engineering-blog@cloudscale.ch.