What is Cross Site Scripting (XSS)?

Cross Site Scripting (XSS) is the first test in a series of controls which exist to protect user data, prevent fraud and secure the organization’s web application and environment.

Cross Site Scripting (XSS) is a common application layer web attack that, despite originating from a website is actually executed on the users’ computer.

In this scenario, an attacker has discovered a way to execute a script (a routine usually programmed in JavaScript or VB Script) delivered to the end user once they access a website or click a malicious web link (URL). These scripts can be introduced by loopholes or coding deficiencies discovered in web apps/websites or by phishing attacks.

Persistent Attacks

Persistent attacks refer to attacks that remain stored on a page, within a website plugin, or a database.

One very simple example of a persistent XSS attack would be from the exploitation of a poorly coded comments section of a website. In this case, if the website is not properly coded to restrict or sterilize code entered as a comment, the browser might actually run the code snippet upon loading the website.

For example, say I drop the following comment into a website:

XSS Example

If the website is not properly configured to encode the special characters, your browser might very well execute the JavaScript. The code executed could be anything the attacker decided to leave in place. In this case, it simply launches a JavaScript alert.

Non-Persistent Attacks

Non-persistent attacks work differently in that they require action from the user such as clicking a link. The link will in turn contain a reference to a malicious script. For example (borrowed from OSASP.org):

XSS Example2

These malicious links might be sent out to potential victims through emails, IMs or even posted to forums. The malicious hyperlink may be disguised as something different (click my OSASP.org URL above to see that it disguises the much longer URL: https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_%28OTG-INPVAL-001%29).

Questions to ask when Auditing for Cross Site Scripting (XSS)?

Control Statement
(1) Periodic penetration testing must be performed against the website.
Penetration test should include the following attributes:
(1.1) Cross Site Scripting (XSS)  

1. How is user input encoded to prevent XSS attacks?

If text inputted by users is not properly encoded, the browser will interpret and execute the script as it does the rest of the web page.

Web browsers can be instructed to encode HTML to prevent XSS attacks. In this scenario, certain characters that might be required to complete the pieces of a malicious script are in fact interpreted as different characters when the browser parses the HTML of the website:

HTML Encoding

Encoding considerations should be considered regardless of the language being developed in.

2. How are phishing attacks prevented?

Phishing is an attempt to acquire sensitive information by masquerading as a trustworthy source through an electronic communication (usually an email).

A phishing attack is a great way to trick a user into clicking an HTML link that is actually malicious and contains an XSS reference embedded in the URL.

User Education is the most effective way to prevent phishing attacks. Creating a consistent experience for users and educating them on the signs of a phishing attack is the first line of defense. Further, there are other development techniques your team may undertake like:

  • Avoiding the use of iFrames in coding (sometimes not possible when using a third party payment processor who uses iFrames to integrate seamlessly into your organization’s website.
  • Avoiding the use of popups.
  • Implement “Anti-Leeching” to disallow attackers from linking directly to company hosted images and assets to plug into their phishing emails.
  • Always point users to a URL (not IP address) and use SSL as often as possible.

3. What Data Validation strategies are in place?

Data validation builds on ensuring data is properly encoded. While encoding data stops most attacks from occurring in the first place, data validation takes defense a step further.

In this case the auditor should be concerned with the following:

  • How is data managed? COBIT Control Objective DS11.1 thoroughly covers the business requirements for data management including integrity of backups, management of storage and securely disposing of data. This is where you start.
  • What Integrity Checks are in place? Ask the developer/auditee to demonstrate how they prevent data from being tampered with.
  • What Validation checks are in place and where? What logic or safeguards are in place to control for incorrect syntax, non-permitted characters, length boundaries are adhered to? Are validation checks included anywhere that data passes between trusted and untrusted boundaries/networks.
  • Are intrusion detection systems (IDS) in place to detect repeated attacks and suspicious activity on the network.
PBC Requests:
1. The most recent Penetration Test from a reputable Third Party Provider
2. Walk-through of the companies web applications and source code Vulnerability and Patching Policy and Procedures,
3. Observation and walk-through of  data validation and data encoding in the application.
Note: Check out OWASP.org for technical testing procedures.



This post is meant to give the IT auditor or IT manager a starting point for understanding Cross Site Scripting and assist with formulating the correct questions to ask when auditing or working with penetration testers and software/web developers and engineers. Please feel free to add more in the comments below and we will keep compiling the list!

For a more in depth understanding of how Cross Site Scripting works on a technical level and deeper dives in preventing XSS attacks, check out The Open Web Application Security Project’s many articles on Cross Site Scripting at: https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 and be sure to notice the HTML encoding in the URL [ %28 = ( and %29 = ) ].