I am tasked with preventing a path traversal attack over HTTP by intercepting and inspecting the (unencrypted) transported data without direct access to the target server.

From some research it seems that a lot of the methods to prevent such an attack are through either server configurations or programs that look at the actual server files.

My initial idea was to find all of the possible encodings of ".", "/", "\" and using regex, find any combination of these that makes up "../" or "..\" in the GET request URI.

However, it seems that there is a myriad of ways to obfuscate a character and I will probably miss something. Are there any better avenues of research I should look into in order to tackle this problem?


  • Do you have the ability to alter the requests, or just inspect them?
    – Daisetsu
    Mar 7, 2019 at 20:21
  • I can alter them yes, I am listening on an intercepting proxy.
    – Eloo
    Mar 7, 2019 at 20:21
  • Well depending on what language your interception proxy is in, you can just rewrite queries to get the canonicalized absolute pathname. That strips out the redundant ../ and ./ Then verify that it's a valid URL. E.g. realpath() in PHP.
    – Daisetsu
    Mar 7, 2019 at 20:27
  • 1
    Perhaps this seems like a stupid question but how are you going to prevent something if you do not have access to the source code?
    – Jeroen
    Mar 7, 2019 at 21:56

1 Answer 1


You cannot do this securely. It is a fundamentally broken approach. You need contextual information about the application and the filesystem, which you cannot gain from an external perspective. The best you can do is deploy a WAF such as Apache's mod_security and enable a bunch of path traversal rules to try to block path traversal attempts, but a determined attacker will eventually find a way around those rules.

If someone has given you this task, consider that the first step in any task is to perform a feasibility study. You work out if the task is possible, what the approaches are and what benefits and drawbacks they have, then you do a cost-benefit analysis. In this case the primary cost is risk. I suggest that you go back to whoever gave you that task and explain that you technically can do this, but it's a blacklist approach that isn't ironclad and it will involve standing up some additional infrastructure in front of the web server (and that means maintaining and patching it too, particularly the WAF part!). Then you can leave it to them to weigh those costs up against a more complete solution, such as getting the web application actually fixed.

If the web application in question is made by a third party, report the directory traversal as a security vulnerability. If it's a product or service that they sell, you can use responsible disclosure to push them to fix it if they're slow about it. If the web application is something that your organisation contracted a third party to make for you, you can check the contract to see if they are liable for fixing security vulnerabilities (you should also write this into your contracts!)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .