<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

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

, Technical Account Manager, 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.

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

You May Also Like

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.
What Is Credential Stuffing? Definition, Prevention & More
What Is Credential Stuffing? Definition, Prevention & More
In this article, we’ll define credential stuffing and explain the risks that credential stuffing attacks pose to organizations and customers. We’ll cover recent examples of credential stuffing attacks and discuss how to detect and prevent them. By the end of the article, you should understand the full scope of credential stuffing, including how to protect your customers’ and employees’ account credentials with the right tools. 
Brute Force Attack: Types, Examples & Prevention
What is a Brute Force Attack? Types, Examples & Prevention
In this article, we’ll take a comprehensive look at brute force attacks: what they are, how they work, and the different shapes they can take. You'll learn about popular tools utilized by hackers and examples of brute force attacks in action. By the end of this article, you'll be able to understand critical prevention measures for brute force attacks.
The difference between SAML vs OIDC
The Difference Between SAML vs. OIDC
The main difference between SAML and OIDC is that SAML builds the trust relationship between the service provider (SP) and the IdP, whereas OIDC trusts the channel (HTTPS) that is used to obtain the security token.
The Differences Between SAML vs LDAP
SAML vs. LDAP: Everything You Need to Know
The difference between SAML and LDAP is that SAML is designed for cloud-based connections using only an IdP and SP to communicate user data. LDAP, however, is typically used for accessing on-premises resources by installing a client on the user's device to connect with a directory service.