Skip to main content
Version: 6.10.1

Path Traversal

Path Traversal is when an attacker uses some mechanism (such as unsanitized user input to a web form) in order to access directories outside of those that the attacker is supposed to be restricted from.

Overview​

An example of a Path Traversal is when a user that is otherwise restricted to /usr/public/sandbox might construct a user input that allows them to access files in a directory such as ../../local/bin/vulnerableScript.sh.  This is a relative path attack and essentially backs the attacker out of the supposedly restricted /public/sandbox, and allows them to access files in /local/bin, all under /usr.  There are 2 types of these attacks, and they are described below in the Wizard Parameters’s Attack Type section.

Rule Options​

Do Not Trust Requests From​

These are the sources that the Actions section will act upon when a traversal is detected.

  • HTTP - The untrusted data is data received by the application from HTTP requests (e.g. from a web browser).
  • Database - The untrusted data is data received by the application from a database.
  • Deserialization - The untrusted data is data received by the application via deserialization APIs (e.g. RMI, JMX, java.io.ObjectInputStream, etc.)

You may select one or many of these, but at least one selection is required. The default value is HTTP.

Attack Type​

  • Relative Path Traversal (CWE-23) - the attacker attempts to navigate the directory structure using the current directory as a starting point such that all paths are relevant to the on that the Waratek protected application lives in.  For example, if the application utilized the directory /usr/public/sandbox and the attacker wanted to get to the script.sh file in /usr/local/bin, the attacker would provide a path of ../../local/bin/script.sh
  • Absolute Path Traversal (CWE-36) - in the case the absolute path can be given. For example, if the application utilized the directory /usr/public/sandbox and the attacker wanted to get to the script.sh file in /usr/local/bin, the attacker would provide a path of /usr/local/bin/script.sh

Action​

  • Detect - The Agent will detect the lookup of listed address(es), log the event to the event database, and the event will be viewable on the Security Events pages in the Portal, but the Agent will take no further action
  • Protect - In addition to the Detect actions, the Waratek Agent will also actively prevent the lookup of the address(es) from succeeding.

Only a single Path Traversal rule is allowed per agent. This rule can specify protection for relative or absolute path traversal attacks, or both.

Log Messaging​

The logs provide a message field, which can be customized. Text entered here is the message that will be seen on the log file’s when the rule has been triggered, regardless of the Action. If the field is left blank, then the default logging message will be displayed in the message portion of the event log.

Severity​

The log files allow you to select a custom severity level for the event: Low, Medium, High or Critical.  A severity is required, and there is no default selection.

Advanced Options​

Disable Logging - By checking this option, no logging will be performed when a rule is triggered. Subsequently the Portal will not see these events, and they will not appear anywhere in the Portal, nor will they be searchable in Event Storage.

This option will be greyed out if the rule action is set to Detect.

Enable Stack Trace - By checking this option, when a rule is triggered, the stack trace will be included in the event log, and will be available for viewing in the Portal UI for each triggering security event.