When something is accessible to someone other than yourself, the first thing that crosses your mind is how to securely share your information with the rest of the world? In the current world where information is becoming digital and accessible to everyone, at the same time, it’s important to understand the restriction on the accessibility of the information, which ultimately leads to the question of how to ensure security of the information which is restricted in nature but at the same time, easily accessible to the community.
When we talk about web security, which is a very wide area, the most common security threat that an engineer hears about again and again is the Cross Site Scripting (XSS), Today, I shall try to explain what Cross Site Scripting (XSS) is all about, what common types it has, what some of the common prevention method adopted to prevent it, and what are some common tools to detect vulnerabilities in a link being sent. My main focus of Cross Site Scripting (XSS) attack will be from client side security attack perspective.
![]()
Before the advancements in the web security domain, the aftershocks of Cross Site Scripting (XSS) attacks were usually made the responsibility of the end-user because he/she has opened a website unknown to him/her, but, along with the advancements in both hacking and web security domains, website companies become equally responsible to prevent Cross Site Scripting (XSS) attacks happening particular on their websites. As an example, let's say that the end-user receives a link of an authenticated website, but, in reality, that link is sent from a hacker to steal the information of the end user, so, in this scenario the responsibility lies equally on the website company to prevent the hacking.
Cross Site Scripting (XSS)
This is injection of malicious code into trustworthy web sites in order to extract vital information about the end-user from the website or to propagate virus to end-user system.
How does XSS attack occurs?
- Email ->
Email is received from an authenticated web link of known website, tempting the end-user to open the link.
- Social Engineering Techniques ->
Use of Social Engineering Techniques to convince the end-user to open the malicious link.
Consequence of Malicious XSS Attack via JavaScript
- Cookie Theft ->
Stealing of the sensitive information via cookies associated with websites. In this scenario, the attacker can access the victim's cookies associated with the website using document.cookie, send them to his own server, and then use them to extract sensitive information like session IDs.
- Keylogging->
Stealing user inputs e.g. password, credit card etc. via hooking keyboard listener. In this scenario, the attacker can register a keyboard event listener using addEventListener and then send all of the user's keystrokes to his own server, potentially recording sensitive information such as passwords and credit card numbers.
- Phishing->
Inserting fake forms e.g. login forms, by manipulating DOM and stealing user credentials. In this scenario, the attacker can insert a fake login form into the page using DOM manipulation, set the form's action attribute to target his own server, and then trick the user into submitting sensitive information.
What is Phishing?
The fraudulent practice of sending emails purporting to be from reputable companies in order to induce individuals to reveal personal information, such as passwords and credit card numbers online.
Cross Site Scripting (XSS) Type
Stored (Persistent) XSS
![]()
Injecting malicious script permanently into web application databases; e.g. via comments. The most damaging type of XSS is stored (Persistent) XSS. Stored XSS attacks involve an attacker injecting a script (referred to as the payload) that is permanently stored (persisted) on the target application (for instance within a database). The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.
I have taken the above diagram from here, I do not own it. Let me explain what the above diagram shows step by step i.e.
- In step-1, the attacker uses comment box on a website's to insert a malicious string into the website's database.
- In step-2, the end-user (victim) opens the page from that website which contains comments along with the malicious comment from the attacker.
- In step-3, when the website receives the end-user request, it simply compiles the response which also includes the malicious string from the database that the hacker previously injected via comment in the response and sends it to the end-user (victim).
- In final step-4, when end-user (victim) receives the response, the browser of the end-user will executes the malicious script inside the response, sending the end-user's (victim's) cookies to the attacker's server.
Reflected XSS
This is injecting malicious script into web applications via HTTP Request e.g. request parameter of URL in case of searching. The second, and by far the most common type of XSS is Reflected XSS. In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.
DOM-based XSS
Advanced malicious code injection via DOM manipulation. DOM-based XSS, where the vulnerability is in the client-side code rather than the server-side code. The most dangerous part of DOM-based XSS is that the attack is often a client-side attack, and the attacker’s payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers analyzing the server’s logs since they will never even see the attack.
XSS Attack Prevention Techniques
- Data Validation
Restrict user input on both server and client side by either rejecting script based input or via data sanitization.
- Date Encoding
Encode request parameters in URL and encode user input, so, that browser interprets input as data and not as code.
- Content Security Policy (CSP)
The disadvantage of protecting against XSS by using only secure input handling is that even a single lapse of security can compromise your website. A recent web standard called Content Security Policy (CSP) can mitigate this risk. CSP is used to constrain the browser viewing your page so that it can only use resources downloaded from trusted sources. A resource is a script, a stylesheet, an image, or some other type of file referred to by the page. This means that even if an attacker succeeds in injecting malicious content into your website, CSP can prevent it from ever being executed.
A web security standard introduced in 2004 to prevent cross cite scripting by defining prevention rules i.e.
- No untrusted sources -> External resources can only be loaded from a set of clearly defined trusted sources.
- No inline resources -> Inline JavaScript and CSS will not be evaluated.
- No eval -> The JavaScript eval function cannot be used.
Tools for Testing XSS Vulnerabilities
- XSS Scanner
- Scan My Server
- SUCRI
- SSL Labs
- Acunetix
Disclaimer
Apart from title image, all other images have been taken from the internet. I do not own any image used above here except for the title image.