The Sneaky Slash

James+Stephen

The Sneaky Slash

How a Double Forward Slash Bypassed My HAProxy Security Rules

Introduction

Yesterday, I discovered a concerning security hole in my HAProxy configuration that made me question how secure my admin area really was. I’m sharing this finding and solution to help others who might have the same vulnerability without realizing it.

The Discovery

I had set up HAProxy to protect my website’s admin panel using a seemingly solid approach:

acl protected path_beg /editor001/
http-request deny if protected !{ src 192.168.1.0/24 }

This configuration was supposed to restrict access to the /editor001/ directory to only IP addresses within my internal network. It worked perfectly in all my tests - until I accidentally found a bypass.

By simply adding an extra slash in the URL:

https://blog00.jjj123.com//editor001/

I was able to access the protected admin area from an external IP address! The double slash completely bypassed my security rule.

Why It Happens

The issue occurs because path_beg does a simple string comparison looking for paths that begin with the exact string /editor001/. When you add an extra slash, the path becomes //editor001/, which no longer matches the exact beginning pattern I specified.

HAProxy sees these as different paths:

  • /editor001/ → matches my rule
  • //editor001/ → doesn’t match my rule!

But the web server normalizes these paths, treating them as identical and serving the same content. This creates a perfect security bypass scenario.

The Solution

After testing several approaches, I found a simple and elegant fix using regular expressions instead of exact path matching:

acl protected path_reg ^/+editor001/
http-request deny if protected !{ src 192.168.1.0/24 }

The key difference is path_reg ^/+editor001/ which uses:

  • ^ to match the beginning of the path
  • /+ to match one or more forward slashes
  • Followed by my protected directory name and another slash

This catches all variations:

  • /editor001/
  • //editor001/
  • ///editor001/ (and so on)

Other Considerations

I initially considered using path normalization:

http-request replace-path /+ /

But after test, I found this adds processing overhead to every request, and it will cause other recgonization error. The regular expression solution is the only and more efficient since it directly addresses the problem without modifying requests.

Lesson Learned

Security configurations need to account for edge cases and protocol quirks. Even a simple thing like an extra slash can create a serious vulnerability if not handled properly.

When setting up access controls in HAProxy or similar tools:

  1. Use regular expressions for more robust pattern matching
  2. Consider how URLs might be manipulated to bypass your rules
  3. Test with unexpected input patterns, not just the “happy path”

Double-check your HAProxy configurations if you’re using path_beg for security rules. That extra slash could be exposing your protected areas to the world!

About Me

I’m a system administrator who believes in security through transparency. By sharing my findings, I hope to help strengthen our collective security posture. Feel free to share this post with other HAProxy users who might benefit from this information.

Note: I’ve changed some domain names and paths for privacy reasons, but the core issue and solution remain accurate.