What is Cross-Site Scripting
Cross-site scripting (XSS) is a client-side code injection attack. The web security vulnerability allows an attacker to compromise the interactions that users have with a vulnerable application.
In XSS attacks, a hacker executes malicious scripts in a victim’s web browser by including malicious code in a legitimate web page or web application. In this case, the cybercriminal circumvents the same-origin policy designed to segregate different websites from each other.
The actual attack occurs when a victim visits the web page or web application that executes the malicious code. The web page or web app becomes a vehicle to deliver the malicious script to the user’s browser. Other methods used to launch XSS attacks include forums, message boards, and web pages that allow comments.
How Cross-Site Scripting Works
A web page or web app is vulnerable to XSS if it uses unsanitized user input in the output it generates. The victim’s browser then parses the user input.
To run malicious JavaScript code in a victim’s browser, a hacker finds a way to inject malicious code (payload) into a web page that victims visit. A user must visit the web page with the malicious code. In case the attack targets particular victims, an attack can use social engineering or phishing to forward malicious URLs to the user.
XSS attacks are possible in VBScript, ActiveX, Flash, and CSS. The attacks are common in JavaScript since the language is fundamental to most browsing experiences.
Types Cross-Site Scripting Attacks
There are three main types of XSS attacks.
- Reflected XSS – a malicious script comes from the current HTTP request
- Stored XSS – a malicious script comes from the website’s database
- DOM-based XSS – the vulnerability exists in the client-side code rather than server-side code
Impacts of Cross-Site Scripting
An attacker abuses XSS vulnerability on a web page or web app to execute arbitrary JavaScript in a user’s browser. The security of the vulnerable website or app and its users is compromised, affecting both the site owner and users.
In some cases, attackers use XSS to deface a website. They use injected scripts to change the site’s content or redirect a user browser to another web page containing malicious code.
Malicious JavaScript in cross-site scripting has access to all the objects that the rest of the web page can access, including users’ cookies with session tokens. If an attacker obtains the cookie information, they can easily impersonate that user, perform actions on behalf of the victim, and access the user’s sensitive data.
In other instances, malicious scripts can read and modify the browser DOM. Fortunately, this action is only possible within the page where the malicious JavaScript is running.
In modern browsers, JavaScript can use HTML5 APIs to perform various activities like access user’s geolocation, webcam, microphone, and even specific files from the user’s file system. The APIs require user opt-in. However, an attacker can leverage social engineering to go around that limitation.
XSS vulnerabilities allow an attacker to masquerade as a victim user to carry out any actions that a user can perform and access any user’s data. In case the victim has privileged access within the application, then the attacker might gain full control over all the application’s functionalities and data.
Overall, cybercriminals can combine cross-site scripting with other attacks such as social engineering to pull off advanced attacks, including cookie theft, planting trojans, phishing, identity theft, and keylogging.
Are You Vulnerable to Cross-Site Scripting?
The Open Web Application Security Project (OWASP) organization lists XSS vulnerability as the second most prevalent issue in their OWASP Top 10 2017.
You can test if your web application or website is vulnerable to XSS by running automated web scans using web vulnerability scanners. You can also use a systematic manual set of tests to detect XSS vulnerability.
Preventing Cross-Site Scripting
Follow these steps to prevent XSS vulnerability:
- Sanitize your input to stay safe from XSS. Your web application code should never output data received as input directly to the browser without checking it for malicious code
- Train everyone involved in building the web application to create awareness of XSS risks
- Deploy existing libraries for escaping, such as HTML escape, JavaScript escape, CSS escape, and URL escape, depending on where user input is used
- Set the HttpOnly flag for cookies that blocks cookie access via client-side JavaScript to mitigate the consequences of a possible XSS vulnerability
- Deploy a Content Security Policy (CSP), which is an HTTP response header that allows you to declare the dynamic resources that are permitted to load depending on the request source
