How to Avert Authentication Bypass Vulnerabilities for Self-hosted Web Infrastructure

When it comes to self-hosting critical web infrastructure, modern security requires more than simply siloing an appliance to a local network. In this article, we will discuss new methods for authentication bypass vulnerabilities, simplify end-user experiences, and satisfy compliance requirements—without the need for legacy VPN solutions. Here's how.

Pros and Cons of Self-hosted Web Infrastructure

Two recent CVEs from Atlassian products remind us how important it is to bake security mitigations into our self-hosted tools right from the get-go. These CVEs disclose vulnerabilities that bypass authentication completely, meaning any relevant server on a publicly accessible IP is at risk of compromise until they are patched.

Certain tools will always assume inherent risk simply due to the nature of their hosted data or operational capacity. These may include engineering code repositories, CI/CD appliances, internal admin consoles, infrastructure monitoring tools, or even data science dashboards that query against production data. Such tools have audiences with varying degrees of technical abilities, and they all require a high level of protection.

While these tools are often business-critical, they are also highly sensitive when it comes to the granted privilege or confidential company IP involved. Given these considerations, many organizations make the decision to maintain a certain level of direct control and mandate they be self-hosted in their own data center or cloud account.

Self-hosting does provide more direct control, but it also means more direct responsibility and, in most cases, more maintenance. Even the most mature vendor software can fall subject to serious vulnerabilities and require swift action to avoid compromise. With hosted software, the vendor must take care of it. When self-hosting, that responsibility lies with the user.

Anticipate Worst-Case Scenarios

A full auth bypass exploit, like the ones mentioned above, can be a worst-case scenario for many security teams. For those that are self-hosting the application on a publicly accessible IP, this means likely being compromised prior to any public disclosure. For those that implement a few additional protections, this means simply updating some packages on a server in an off-schedule deployment.

So how do teams anticipate and plan for scenarios when the stakes are so high? After all, the vendor in question may be ubiquitous, may have passed the internal vendor review process with flying colors, and may fit the bill by all other measures.

One answer is to practice defense in depth and bake in mitigations into that tool's deployment architecture. CVEs are an unfortunate fact of life even for the largest software teams, and security is a shared responsibility. Luckily, there are many ways to mitigate potential attacks.

Ensure that self-hosting is necessary

Is self-hosting this tool a true business need? Overzealous teams may introduce new attack vectors simply by assuming too much responsibility too quickly. Before you assume the obligation of self-hosting, ensure that it is necessary for the resources in question.

For example, it may be tough to require the sales team to upload their general reports solely through the AWS CLI directly into S3 without leaking access keys. Google Drive may serve just fine. And Google likely has more engineers dedicated to protecting Google Drive than the startup in question may have on their entire engineering team.

Prevent direct exposure

Ensure that self-hosted tools of this nature are not exposed directly to the public internet. In today's reality of continuous automated scanners looking for easy exploits, simply not having a publicly accessible IP address can do most of the heavy lifting when reducing the attack surface.

Eliminate needless friction

Finally, take a look at your added layers of protection. Do they create challenges for employees who require access? Can less-technical teams and remote workers connect to the systems they need to perform their jobs? Legacy solutions such as clunky VPNs and neglected jump-hosts ignore usability for non-technical users and often end up more of a blocker than a solution.

Enter, the Identity Aware Proxy

An Identity Aware Proxy (IAP) goes beyond simply siloing an appliance to a local network.

An Identity Aware Proxy simultaneously:

• Scans for targets by isolating sensitive resources within company networks
• Eliminates the need for legacy VPN solutions
• Authenticates users prior to providing network access to sensitive resources
• Provides audit logging of all user access activity
• Enables request-based access flows as needed
• Offers ease of use even for non-engineering applications

StrongDM can protect self-hosted web pages and provide ease of access to end users via an IAP. This feature can help you avoid scenarios like the full auth bypass vulnerability described above, allowing organizations to put highly confidential documentation into portals, admin panels, dashboards, and related tooling.

Implementing this feature of StrongDM not only confers all of the benefits of an IAP but also aids in fending off attacks, improves the user experience, and satisfies compliance requirements.

Want to see it in action? Sign up for a demo today.