iRule Security 101 - #05 - Avoiding Path Traversal

Path Traversal is an attempt to access files and/or directories stored outside web root folder. If successful this could allow malicious users to view content they were not intended to see, execute programs that have lax permissions and were thought secure because they were stored outside the web root or even, in the case of a system that allows anonymous uploads, allow them to upload executable scripts into locations where they may be exploited. You can read more about this kind of attack here. Other articles in the series:

• iRule Security 101 – #1 – HTTP Version
• iRule Security 101 – #02 – HTTP Methods and Cross Site Tracing
• iRule Security 101 – #03 – HTML Comments
• iRule Security 101 – #04 – Masking Application Platform
• iRule Security 101 – #05 – Avoiding Path Traversal
• iRule Security 101 – #06 – HTTP Referer
• iRule Security 101 – #07 – FTP Proxy
• iRule Security 101 – #08 – Limiting POST Data
• iRule Security 101 – #09 – Command Execution

Obviously this attack is more severe the more access you allow users, as is often the case. If you are allowing anonymous uploads to your webserver you're already playing with fire, but many sites require this functionality today with more and more user driven content. The first solution that comes to mind is likely file-system security. While it's true that proper permissions management and webserver settings may help mitigate a large portion of this attack, it's all too easy to overlook some of those things when managing multiple systems.

So what else can be done? Enter iRules. With a relatively simple iRule you can configure your BIG-IP to look for any suspicious looking file paths being requested, and to handle those requests differently. It's up to you to choose whether to inspect all requests or just some (just POSTS to certain forms, perhaps) as well as what information to look for to block. In the below examples we're just looking for file names that start with "../" or "/" as these are a couple of the common examples of Path Traversal attempts.

These attempts could come through in the URI, in which case you'd use something similar to the following example to look for them:

 
when HTTP_REQUEST { 
  set file [regexp -inline {filename=(.+)} [HTTP::uri] ] 
  if { ($file starts_with "/") or ($file starts_with "../") } { 
    log local0. "[IP::client_addr] requested $file" 
    HTTP::respond "I'm sorry, but your request for $file is contains invalid characters. Please try your request again." 
    HTTP::close 
  } 
} 

The offending data could also come through in the body of the request itself depending on your environment, in which case we'd have to do a little bit deeper inspection to find the information we're looking for before performing the same respond and close to block the request. The below example is looking through HTTP POSTs to look for this particular attack.

 
when HTTP_REQUEST { 
  if { [HTTP::method] equals "POST" } {
    HTTP::collect 
  } 
} 

when HTTP_REQUEST_DATA { 
  set file [regexp -inline {filename=(.+)} [HTTP::payload] ] 
  if { ($file starts_with "/") or ($file starts_with "../") } { 
    log local0. "[IP::client_addr] requested $file" 
    HTTP::respond "I'm sorry, but your request for $file is contains invalid characters. Please try your request again." 
    HTTP::close 
  } 
  HTTP::release 
} 

These are relatively basic examples but should give you a place to start and the idea of what to look for. In a real world environment these rules could check for many more potential Traversal attempts, only filter requests to/from certain locations, use classes to store the different search patterns, etc. Given the flexibility of iRules, there's nearly no limit to the ways you could customize this for your particular environment.