<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">
LAUNCH WEEK 🚀 Enable continuous, contextual + granular authorization. Learn more.

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.

About the Author

, Customer Success Engineer, has helped enterprise organizations navigate through complex technical deployments, helped startups build their security programs, and developed custom-fit implementation solutions for security operations tooling. He thrives on guiding people and businesses toward secure, resilient infrastructure architecture design. To contact John, visit him on LinkedIn.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

AWS Authentication Best Practices (That Go Beyond MFA)
AWS Authentication Best Practices (That Go Beyond MFA)
AWS authentication confirms the identity of users trying to access your resources, safeguarding against potential intrusions and data breaches. But weak authentication practices—like easy-to-guess passwords and single-factor authentication (SFA)—are far too common and they leave the door wide open for threat actors. Weak authentication often leads to data theft, resource misuse, financial and reputational nightmares…the list goes on. On the contrary, strong authentication measures like Multi-Factor Authentication (MFA) significantly reduce the risk of these incidents occurring. StrongDM takes AWS authentication to the next level, going beyond MFA to include granular access controls based on roles (RBAC), attributes (ABAC), and just-in-time approvals.
AWS Management Console resources
Connect to Even More Resources with StrongDM’s AWS Management Console
We’ve just launched our AWS Management Console, adding yet another supported authentication method to improve control and auditability–so you can protect your business and improve employee productivity.
Token-based Authentication: Everything You Need to Know
Token-based Authentication: Everything You Need to Know
Secured authentication to databases and applications is crucial to enterprise cybersecurity management. Unfortunately, 82% of all breaches involve human error, including misused or compromised credentials that give threat actors unauthorized access to network resources. Luckily, there’s a solution that ensures security without the risks that come with traditional, credential-based authentication. This article discusses token-based authentication and explains why it's a reliable and flexible alternative to verifying users, especially for cloud applications.
LDAP vs. Active Directory: Everything You Need to Know
LDAP vs. Active Directory: Everything You Need to Know
Struggling to understand the difference between Active Directory and LDAP? Don't worry, we’ll make it simple. These are just two among many methods that can provide secure user authentication and authorization. The information in this article will help you decide if LDAP or Active Directory is right for your organization. Robust security and a seamless user experience are attainable, and you can have both!
SAML vs. OAuth
SAML vs. OAuth: Everything You Need to Know
In this article, we will provide a high-level overview of the Security Assertion Markup Language (SAML) and Open Authorization (OAuth) information access frameworks. You’ll learn about the key similarities and differences between SAML and OAuth, the unique benefits of each framework, and specific use cases for each. By the end of this article, you’ll have a clear understanding of SAML and OAuth to help you determine which is right for your organization.