Skip to main content

2024-11 Cobalt pentest

We are committed to engaging in regular pentesting and security audits of authentik. Defining and adhering to a cadence of external testing ensures a stronger probability that our code base, our features, and our architecture is as secure and non-exploitable as possible.

In August-September of 2024, we had a pentest conducted by Cobalt. This document covers the findings of the audit, how we addressed the noted issues, and the subsequent re-testing by Cobalt to confirm that all issues were resolved.

Cobalt described their process for testing:

This pentest was a manual assessment of the security of the application’s functionality, business logic, and vulnerabilities, such as those cataloged in the Open Web Application Security Project OWASP) Top 10. The assessment also included a review of security controls and requirements listed in the OWASP Application Security Verification Standard (ASVS).

Summary of findings​

Overall, we are pleased with the report's findings and grateful for the opportunity to improve in every area we can.

Cobalt reported "The pentesters found that the Authentik Security team implemented robust and up-to-date security practices throughout the application."

In total, there were 5 low-level and one info-level vulnerabilities reported. By early November 2024, all 6 vulnerabilities were addressed and released in the 2024.10.4 patch release.

Responses to specific findings​

From the audit, this is the complete list of findings, with information about how we addressed each.

HTML Injection​

Issue: A vulnerability existed through user-supplied names in our Flow diagrams, where the application did not properly sanitize or escape HTML input when parsing user-entered names. As a result, an attacker could inject arbitrary HTML or JavaScript code into the application, potentially leading to manipulation of the web page or execution of malicious scripts in the context of the user's session. (This action could only be performed by an authenticated admin user, and thus had little practical value as an attack vector.)

Fix: We added strict DOMpurify configurations for any user-defined names in our diagrams. For details, refer to Pull Request #11783.

SVG images for icons possible XSS vulnerability​

Issue: The pentesters discovered that the application was susceptible to insecure file upload and stored Cross-Site Scripting (XSS) vulnerabilities by uploading crafted SVG files that were used as application icons. (This action could only be performed by an authenticated admin user, and thus had little practical value as an attack vector.)

Fix: The fix was to add a CSP header to files that are stored in the /media directory of the installation. For details, refer to Pull Request #12092.

Issue: It was found that the application was vulnerable to stored XSS through footer links. The footer section of the application accepted and displayed user-provided links without proper sanitization. This could allow an attacker to inject malicious scripts into these links, which would then stored and executed when other users access the footer links, leading to potential script execution in the context of the victim's session. (This action could only be performed by an authenticated admin user, and thus had little practical value as an attack vector.)

Fix: Again, as with the diagram issue above, we added strict DOMpurify configurations. For more details, refer to Pull Request #11773.

Password policy weakness​

Issue: It was determined that the password policy in place on the testing environment was weak, allowing users to create passwords that lacked complexity and were easily guessable. This made the application more susceptible to brute-force and dictionary attacks.

Fix: This was not a vulnerability in authentik, but rather a poor configuration of our provided test environment. Rather than simply improve our test instance’s configuration once, to make this issue easier to avoid for all our users and customers, we added a strong default password policy that applies to all new instances. (As always, admins can still configure their own custom policies.) For more details, refer to Pull Request #11793.

Lack of a CSP header​

The absence of Content Security Policy (CSP) headers means that the application may lack a mechanism to restrict sources of content and scripts, which can potentially expose it to XSS attacks and other forms of content injection.

Fix: We added CSP headers to control the sources of content and scripts that the application can load for our provided test instance. Again, this is not a direct vulnerability in authentik itself. Given the variety of architectures in which authentik is deployed, adding our own CSP headers would be more likely to break functionality than to provide improved security.

API endpoints strengthened​

Issue: Finally, the only informational level finding was the potential for the unauthenticated download of private key and certificate values via a direct URL. (Guessing the URL required the knowledge of the UUID of an object.) We had already fixed this issue in 2024.8.0, but the instance tested against was the immediately preceding version.

Fix: For more details, refer to CVE-2024-42490.

Retest results​

The subsequent retest conducted by Cobalt deemed all issues resolved. See page 17 of the report for the mitigation status ("fixed") for each of the issues discovered in September.

We are pleased to share this pentest and the final results of the retest. We encourage an open and ongoing communication with our users and community. For more information abut our security stance, read our Security Policy, Hardening authentik, and our other security-related documentation. If you have any questions or feedback you can reach us on GitHub, Discord, or via email to hello@goauthentik.io.