Path Traversal Security Feature

Overview

An application is vulnerable to Path Traversal (also known as Directory Traversal) attacks when unvalidated or unsanitized user input is used to construct a path that is intended to identify a file or directory located underneath a restricted parent directory. For such an application, the user can construct a path name that traverses the file system to a location outside the scope of the restricted parent directory.

There are two types of Path Traversal attacks:

• Relative Path Traversal

• Absolute Path Traversal

Path Traversal vulnerabilities are covered by CWE-22. Specifically, Relative Path Traversal is covered by CWE-23 and Absolute Path Traversal is covered by CWE-36.

The Path Traversal rule can be used to protect against both relative and absolute path traversal attacks. That is:

• Protect against file operations where a user-constructed path allows the user to traverse back to the parent path.

• Protect against file operations where a user-constructed path allows the user to specify an absolute path to a file or a directory.

Given (Condition)

The Path Traversal security feature is enabled using the ARMR filesytem rule. With this rule the user can specify a single condition - input.

input	This allows the user to specify the source of the untrusted data. The following three sources are supported:- http data introduced via HTTP/HTTPS requests

• database data introduced via JDBC connections

• deserialization data introduced via Java or XML deserializationThe rule will trigger if the source of the untrusted data matches that specified in the rule.If no value is specified then a default value of http is used.An exception will be thrown if an unsupported value is provided. |

This rule provides protection only when user input is received via an API that is enabled in the input declaration of the rule.

When (Event)

traversal	This is a mandatory condition that allows the user to specify the type of path traversal protection to enable. The following protection types are supported:- relative

• absoluteEach rule may contain a single protection type.If no value is specified then by default protection will be enabled for both relative and absolute path traversal attacks. |

Then (Action)

protect	Path traversal attacks are blocked by the agent. If configured, a log message is generated with details of the event.
detect	Monitoring mode: the application behaves as normal. Path Traversal attacks are allowed by the agent. If configured, a log message is generated with details of the event.

Example

The following filesystem rule is used to protect an application from both relative and absolute path traversal attacks.

The input declaration is satisfied when the untrusted data originates from an HTTP/HTTPS request. Since no value is specified inside the traversal declaration, the rule will trigger when the resulting path either allows the user to traverse back to the parent path, or to specify an absolute path to a file or a directory.

An action of protect is defined to ensure that the agent blocks such requests. A log message and severity are both specified which will be included in any generated log entries if an attack is detected.

app("Path Traversal mod"):
  requires(version: ARMR/2.2)
  filesystem("Protect against relative and absolute path traversal attacks"):
    input(http)
    traversal()
    protect(message: "Path Traversal attack blocked", severity: 8)
  endfilesystem
endapp

Logging

When the above filesystem rule is triggered a log entry similar to the following is generated:

• relative

  <10> 1 2020-06-10T12:27:19.198+01:00 l-qa02 java 17097 - - CEF:0|ARMR:Path Traversal mod|Path Traversal mod|2.2|Protect against relative and absolute path traversal attacks|Execute Rule|High|rt=Jun 10 2020 12:27:19.196 +0100 dvchost=l-qa02 procid=17097 outcome=success act=protect msg=Path Traversal attack blocked path={"Path":"/home/spiracle/pathTraversal/testFilesParent/testFilesChild/../TestFile"} metadata="HeaderInfo":{"remoteAddr":"0:0:0:0:0:0:0:1","requestURI":"/spiracle/FileServlet01","sessionId":"3767AF331E581A52923E6A274332EF72","cookieNames":{"JSESSIONID":"3767AF331E581A52923E6A274332EF72","CUSTOMER_UUID":"05b7b9d7-2046-4014-b8c9-bc53c79790c5"}}

• absolute

  <10> 1 2020-06-10T12:29:33.877+01:00 l-qa02 java 17097 - - CEF:0|ARMR:Path Traversal mod|Path Traversal mod|2.2|Protect against relative and absolute path traversal attacks|Execute Rule|High|rt=Jun 10 2020 12:29:33.877 +0100 dvchost=l-qa02 procid=17097 outcome=success act=protect msg=Path Traversal attack blocked path={"Path":"/tmp/somefile.txt"} metadata="HeaderInfo":{"remoteAddr":"0:0:0:0:0:0:0:1","requestURI":"/spiracle/FileServlet03","sessionId":"3767AF331E581A52923E6A274332EF72","cookieNames":{"JSESSIONID":"3767AF331E581A52923E6A274332EF72","CUSTOMER_UUID":"05b7b9d7-2046-4014-b8c9-bc53c79790c5"}}

Further Examples

The following mod protects against relative path traversal attacks that originate from a JDBC connection:

app("Path Traversal mod 2"):
  requires(version: ARMR/2.2)
  filesystem("Protect against relative path traversal attacks"):
    input(database)
    traversal(relative)
    protect(message: "Path Traversal attack blocked", severity: High)
  endfilesystem
endapp

The following mod monitors for absolute path traversal attacks that originate from an HTTP/HTTPS request:

app("Path Traversal mod 3"):
  requires(version: ARMR/2.2)
  filesystem("Detect and log absolute path traversal attacks"):
    input(http)
    traversal(absolute)
    detect(message: "Path Traversal attack detected", severity: Medium)
  endfilesystem
endapp

The following mod protects against both relative path traversal attacks that originate from various untrusted sources. Logging is switched off by the omission of the log message parameter.

app("Path Traversal mod 4"):
  requires(version: ARMR/2.2)
  filesystem("Protect against relative and absolute path traversal attacks"):
    input(deserialization, http, database)
    traversal()
    protect()
  endfilesystem
endapp