Cross-Site Scripting (XSS) is a web application vulnerability that can provide attackers an opportunity to run malicious code on web pages and steal the information of web users. XSS is the injection of JavaScript code into web pages.
By using XSS attacks, cybercriminals can steal website user credentials, sensitive information and XSS can lead to serious social engineering attacks and client-side attacks.
For cross-site scripting example, let suppose there is malicious code that can steal the user credentials and other sensitive information from websites session. Now think for a second, if your website is allowing users to fill in forms or do commenting, and someone places that malicious code in the form or comments. Yes, this can happen because your webserver will accept this input as a code and will execute it whenever someone opens that webpage.
When any user opens that page, all the sensitive information stored in the cookies of that user will be transferred to the attacker's machine. This is called Cross-Site Scripting.
According to Verizon 2020 Data Breach Investigation Report, 43% of all data breaches in 2020 involved web applications. While according to Precise Security, 40% of all cyber-attacks in 2019 were caused by Cross-Site Scripting. Companies are spending millions in bug bounty programs against XSS and still, XSS remains in the top 10 vulnerabilities according to the 4th Annual Hacker Powered Security Report.
Types of Cross-Site Scripting
There are three major types of Cross-Site Scripting:
1. Reflected Cross-Site Scripting
Reflected cross-site scripting arises when an application receives data in an HTTP request and includes that data within the immediate response in an unsafe way.
In reflected cross-site scripting, the threat actor will send a modified malicious link of the XSS vulnerable website to the victim user by the mean of email or use the phishing attack technique. The user will click the URL of the website, which is vulnerable to XSS, and the webserver of that website will respond to the user by reflecting that modified malicious code. Finally, the user browser will execute that malicious code because web browsers are supposed to execute the code sent by webservers. Execution of that malicious code can send the victim sensitive data to the threat actor machine.
A question may arise here: is the next user of that website going to be the victim of this attack? The answer is “No” because this malicious code will be discarded by the web server once it is reflected to the user. Therefore, this type of XSS is called Reflected Cross-Site Scripting. The attacker must have to create a new malicious link for each user.
2. Stored or Persistent Cross-Site Scripting
This type of XSS does not require separate malicious code for every victim. The example given earlier in the article is related to stored XSS. In this XSS type, threat actors first find the XSS vulnerable website and store their malicious code in its web server. This can be done via comment sections or filling in the forms. So, whenever any user accesses those injected webpages, they will be the victim of XSS and their browser will execute that injected malicious code, and their sensitive information will be leaked.
This type of XSS is called stored or persistent because the malicious code is stored in the database of the webserver, and it keeps sending that code persistently to every user who accesses that page.
3. DOM Cross-Site Scripting
DOM XSS can only happen if a web application is using DOM (Document Object Model). In DOM, the stored data remains on the client-side instead of the server-side. So, in this situation, only the browser reads and displays the output.
In DOM XSS, threat actors inject the malicious code in DOM using URL or sink with browser API. Whenever a user visits the URL or executes any action on that injected page, the browser updates the DOM and executes the code to display output. While displaying output, injected malicious code also gets executed and sends the user confidential data to the attacker machine.
How to Prevent Cross-Site Scripting
Code Sanitization: Keep your code sanitized, your application code must not deliver the data to the browser for output without the scan for malicious code.
Awareness: To keep your web application safe, you must provide training to your developers, QA staff, and DevOps about what cross-site scripting is and the risk associated with it.
Web Application Firewall: You must use a web application security system to block malicious activity or bots and attacks can be prevented before any malicious script is executed.
Content Security Policy: CSP can be helpful in preventing XSS by defining the functions which are allowed for a website to perform and preventing any inline script to execute.
Escaping/Encoding: Use the escape/encode technique to tell the browser not to execute the code at user input and treat it like simple data. You can use ESAPI escaping library from OWASP or AntiXSS from Microsoft to protect XSS with escaping/encoding.
Conclusion
Cross-Site Scripting is the injection of malicious code in the webpages and stealing confidential data from users of those webpages. XSS is a serious threat to web applications nowadays. At the topmost, SMB’s must consider this and schedule the website vulnerability assessment frequently. XSS is a high potential critical cyber threat for companies. Prevention from XSS is mandatory to keep the website and web applications up and running.
