Skip to main content
Version: 6.11.0

HTTP Header Injection

Response Header Injection is when user-supplied data is added into a response header in an unsafe way.

Overview​

If an attacker can inject newline characters into the header, then they can inject new HTTP headers. In addition, by injecting an empty line, they can break out of the headers into the message body and write arbitrary content into the application's response.

Any attack that can be delivered via cross-site scripting can usually be delivered via response header injection. It is also sometimes possible to leverage response header injection vulnerabilities to poison the cache of any proxy server via which users access the application. For example, if the proxy server can be manipulated to associate the injected response with another URL used within the application, then the attacker can perform a stored attack against this URL, which will compromise other users who request that URL in future.

Rule Options​

HTTP Endpoint (Optional)​

Here you can enter in a list of relative URIs to be protected, monitored, or whitelisted.  A relative URI only includes the path portion of the URL, and not the domain.  For example if the website address was http://www.victim.com/home/test.html, then /home/test.html is the relative URI or HTTP Endpoint.

The path within the relative URI must be absolute and begin with a leading /. In the above example /home/test.html is valid and home/text.html is not. In addition, relative paths may not contain .. or other similar characters denoting path shortcuts. For example, /home/test/user/test.html is valid, but ../test/user/test.html is not.

Injection Type​

  • Cookies - Protect against injection into HTTP response cookies.
  • Headers - Protect against injection into HTTP response headers.

Action​

  • Detect - The Agent will detect the attack, it will 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 attack from succeeding.

If multiple Response Header Injection rules are created, the Agent will not allow matching HTTP Endpoints to be specified between rules.

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 or 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.