Cross-site scripting attacks, often abbreviated as XSS, are a type of attack in which malicious scripts are injected into websites and web applications and run on an end user’s platform. XSS attacks are a common and widespread type of attack, using unsanitized or unvalidated user inputs, aimed at the generated output.
The XSS attack does not have to choose a specific target; the attacker simply exploits the vulnerability of the application or site, taking advantage of anyone unlucky enough to trigger an attack. Using XSS attacks, a web application or web site becomes the vector of delivering malicious scripts to the browsers of several victims.
How cross-site scripting works
Now that we know what a cross-site scripting attack is let's see how it works.
XSS attacks occur when a security vulnerability is used on a web page, often with a malicious link or an insecure user input field that allows an attacker to inject a malicious script into a website or application.
After this script is inserted into a web page, the unsuspecting user or target often launches the execution of malicious code when accessing a site or application. It can occur in several different ways, and the most common of which is when the target clicks on a malicious link or every time a page is loaded from the server.
In order for the attack to be successful, attackers need to find a way to transmit malicious code to the target system via the visited web application or website. Social engineering is a common method that allows people to visit vulnerabilities, such as a hacked web page, which then transmits a malicious code to the victim's browser.
XSS attacks are standard attack vectors for websites that do not sanitize user input. Sanitizing user input means that potentially dangerous characters are removed from the information before processing. An attacker can take advantage of user input fields, especially when they are not sanitized, to merely reference the malicious script at the end of their secure input.
What are the consequences of cross-site scripting (XSS) attacks?
Cross-site scripting attacks, regardless of type, lead to the same set of consequences. The difference in the attack vector affects only the delivery methods, not the final result.
Severe XSS attacks can result in the user's session cookie being disclosed, which will allow an attacker to take over the user's account and hijack their session. There can also be the disclosure of end user’s files, installed malware, unexpected site redirects, and content presentation modification. XSS attacks can lead to compromise of usernames and passwords leakage of sensitive data, and theft of confidential or trade secrets.
XSS attacks can allow attackers to modify the content in their benefit, allowing them to create falsified information that can impact or harm the target individuals; this is known as content spoofing.
Different types of cross-site scripting attacks
Stored (persistent) XSS
Stored or persistent XSS attacks occur when the malicious scripts are permanently stored on the targeted server(s); this can occur in a database, on a message board, in comment fields, or on other user input pages. Victims receive a malicious script when the information is requested from the server.
A reflected attack occurs when the malicious script is not contained on the server but is included in the input sent to the server. Errors messages and search results are two commonly used vectors.
These attacks are often delivered to the target via an email or on another site, often by tricking the target into choosing a link containing the malicious script or through user submitting the malicious form. The malicious code then reflects to the user's browser. This reflection causes the browser to believe that the script is trustworthy and prompts the browser to execute the script.
DOM based attacks
There is a third type of attack, known as a DOM-based attack, which is not common but can occur. The document object model, or DOM, is the application programming interface (API) used for valid HTML and XML documents. A DOM-based attack occurs when the DOM environment is modified in the target's web browser. This modification causes the client-side code to run in unexpected ways.
DOM-based attacks are different in that they do not exploit the flaws in the server-side code, instead of relying on the client-side scripts.
Cross-site scripting attacks (XSS) examples
Although this example is an old one, it shows the simplicity of executing an XSS attack on a target. The image above shows how an attacker implements a malicious script to extract the user's cookie data, including the user ID and password from the browser. There's also an HTML image tag being used to provide this information to the attacker through a monitor file on his server.
The image above shows a message once it is posted on the message board and gives a user private cookie data to the attacker due to the operation of the malicious script. This example is simple and easy to identify as a malicious attack, but there are ways to enhance these attacks and hide the malicious actions from target users.
Cross-site scripting (XSS) vulnerabilities
Cross-site scripting vulnerabilities arise when user input that is entered into a web application does not pass proper validation steps or when browser's output is not encoded in HTML format.
Input validation is the process of ensuring that properly formed data is the only one entering a website. If input validation is executed early in the data input handling, it will be more successful.
HTML coding occurs when documents or input data is converted to a standard form, which means that the browser interprets a text and displays it correctly. The purpose of HTML coding is to ensure that browsers display the information correctly and do not interpret it as code.
XSS attack prevention/mitigation
While cross-site scripting attacks can be dangerous and difficult to detect, there are ways to prevent and mitigate them. The basic principles of input handling are validation, sanitization and escaping.
The validation process ensures that the user input is legitimate and properly formatted according to a fixed set of validation rules. The theory here is to treat all data or inputs as untrusted until they are met with certain criteria such as type and length requirements. For example, The Phone Number input field can contain only numbers and cannot be submitted when a user is trying to type letters or special symbols to this field.
Keep in mind that some user input that doesn’t contain any malicious scripts can still be a source of errors in the application database. Data might become corrupted in the process of saving it due to how databases handle some special symbols. For this reason, during input sanitation, you also need to perform encoding of database-sensitive content. This process is required not only for preventing attacks but for overall application stability.
The «<» and «>»characters are often removed from use to prevent a possibility to display HTML code from other user input. For example, if an attacker put some harmful code inside his or her username on a social network, the escaping process will not allow the code to be executed after you see an attacker’s profile.
Web Application Firewalls (WAF) are a widely used application firewall that is effective in reducing and preventing XSS attacks. These firewalls apply a set of rules to HTTP conversations that help to protect servers, web applications, and ultimately, the users. These firewalls come in a variety of forms, and they may need to be customized according to the needs of a user or an organization.
PT AF — Web Application Firewall
Our web application firewall is an innovative protection system that detects and blocks attacks including the OWASP Top 10, WASC, layer 7 DDoS, and zero-day attacks with pinpoint accuracy. It ensures continuous security for applications, APIs, users, and infrastructure while supporting compliance with security standards including PCI DSS.