Skip to main content

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites.

Overview

XSS attacks occur when an attacker forces a victims’s browser to unknowingly execute the attacker’s code. To accomplish this, the attacker uses a vulnerable web application as a delivery vehicle for the code.  The attacker, for example, places the code on the vulnerable web application, and the web application then serves this code to the victim, and the victim’s browser runs the malicious code. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application serves the attacker’s input within the output it send to the victim without validating or encoding it. The victim’s browser has no way to know that the script should not be trusted, and will execute the script. As the browser thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

There are several different types of XSS attacks:

Type 1: Non-Persistent (Reflected XSS) - This is when the attacker, rather than storing the code on the web application itself, tricks the victim into executing it by including it in the URL itself.  This often takes the form of a malicious web link sent in a phishing attack.

Type 2: Persistent (Stored XSS) - This is when the attacker stores the malicious script code on the web application itself, usually by storing it in the web application's database.  The malicious code is sent from the web application, where it is stored, to the victim's browser to execute.

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.

Policy Options​

  • Loose - Loose will allow user inputs that Waratek considers safe to be utilized or injected when submitting web forms, such as rich text input, in order to prevent breaking web applications that depend on this kind of benign user input.
  • Strict - Strict will consider any user input that escapes its HTML context an XSS attack.

The default is loose.

Do Not Trust Requests From​

These are the sources that Waratek will treat as untrusted.

  • HTTP - Data received by the application from HTTP requests (e.g. from a web browser).
  • Database - Data received by the application from a database.
  • Deserialization - 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.

Excluded/Whitelist Relative URIs (Optional)​

This is only supported on ARMR 2.5 or higher

When creating the XSS rule, if you would like to whitelist certain URIs in order to exclude them from XSS protection, then add them here. This field is optional, and leaving it blank adds no exclusions to any URIs listed in the HTTP Endpoint section (or all web pages if the Endpoint section is left blank). Validation follows the same format as described under the HTTP Endpoint (Optional) section above.

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 XSS rules are created, the Agent will not allow matching HTTP Endpoints or Excluded Relative URIs 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.

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.

Resources

More information on cross-site scripting can be found at:

  • the CWE’s community-developed website
  • the OWASP Foundation’s website