What is Cross-site Scripting
Cross-site scripting (XSS) is a security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. XSS relies on the user’s trust of the site.
By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
While XSS can be taken advantage of within VBScript, ActiveX and Flash (although now considered legacy or even obsolete), unquestionably, the most widely abused is JavaScript – primarily because JavaScript is fundamental to most browsing experiences.
There are two major types of XSS attacks. The frst and easiest to create is non-persistent cross-site scripting, also known as reflected cross site scripting. Reflected Cross-site Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The script is activated through a link, which sends a request to a website with a vulnerability that enables execution of malicious scripts. The vulnerability is typically a result of incoming requests not being sufficiently sanitized, which allows for the manipulation of a web application’s functions and the activation of malicious scripts. To distribute the malicious link, a perpetrator typically embeds it into an email or third party website. The link is embedded inside an anchor text that provokes the user to clicking on the it, which initiates the XSS request to an exploited website, reflecting the attack back to the user.
The second, often more complex attack, is a persistent XSS, also known as a stored XSS. A persistent cross-site scripting attack requires the site that is exploited to store the exploit. This is usually done by uploading the exploit code into the website or application in a way that will cause it to be displayed to visitors to the site. The persistent (or stored) XSS vulnerability is a more devastating variant of a cross-site scripting flaw: it occurs when the data provided by the attacker is saved by the server, and then permanently displayed on "normal" pages returned to other users in the course of regular browsing, without proper HTML escaping.
As is with most web-based attacks, exploiting Stored XSS vulnerabilities requires some research. Usually attackers search vulnerable websites that can be used to carry out an attack. There are some types of websites which are prone to such vulnerabilities because they allow content sharing between users, and consequently they constitute the starting points of research in this respect:
- Forums / message boards
- Blogging websites
- Social networks
- Web-based collaboration tools
- Web-based CRM/ERP systems
- Web-based email server consoles and web-based email clients
Once a website is identified as being potentially vulnerable, attackers will try to inject script code into data that is going to be stored on the server. Then, they will access the web pages that are serving back the content they have posted and test if the script executes.
The malicious code itself is usually delivered manually by the attacker in input fields on the vulnerable web pages, but there are cases where attackers build tools that regularly inject scripts automatically.
Unlike Non-Persistent XSS, Persistent XSS does not require a social engineering phase, as victims of this attack do not need to be lured into clicking on a crafted link. However when exploiting Persistent XSS vulnerabilities, attackers will try to get more and more victims to visit the vulnerable web page so they will most probably still send SPAM messages or promote it on social networking websites.
Preventing XSS
There are several common techniques that can help decrease the likelihood of successful cross-site scripting exploits. They include:
- Stripping code out of user input To do this, programmers need to wrap user input in escape codes that indicate that no code inside of them should be run. When XSS was frst discovered, simple defenses would just strip out the
- Validating user input User input is often well known and can be validated against expected data inside of the application. For example, if users are putting in a phone number, their data shouldn’t include words. Any input from the user should be validated wherever possible.
- Cookie data validation Cookies are typically set by a website, but that doesn’t mean that malicious users can’t modify them. If the site or application trusts the cookies it sets without validating them against expected inputs, attackers can place cross-site scripting attacks into the cookie data itself.
Did you find this tutorial helpful? Don’t forget to share your views with us.