Modern web applications are the backbone of the internet world. A modern web application is a developed software application that is stored on a server and distributed over the web. A vulnerability in web applications means a vulnerability in the entire Internet.
Modern web applications are vulnerable in many ways. XSS is the most common among them. XSS is easy to find and easy to exploit but very dangerous for web applications. XSS occurs when an application fails to properly validate and sanitize user input, allowing malicious code to be injected into the application and executed in other users’ browsers.
The Definition of XSS
Vulnerable Code Example
Let’s see a simple example of how an XSS vulnerability may occur. If you are on Linux go to the temp folder, create an HTML file, then paste the following code and save.
<html> <body> <script> var url = new URLSearchParams(window.location.search); var p = url.get('p'); document.write(p); </script> </body> </html>
Run python3 HTTP server
python3 -m http.server 8080
Now start your browser and browse the following URL:
Type of XSS
It can be divided into three categories based on where XSS vulnerabilities exist or are found. Here:
- Stored XSS: This is the most dangerous XSS of all types. The XSS payload is stored in the backend of the web application. And the payload is executed whenever someone visits the page. Stored XSS affects comment boxes, post sections, review areas, and other functionality where user input can be generated and stored in the web application’s backend. Due to its continued existence in a web application, it can adversely affect the user of that application.
- Reflected XSS: It is slightly less harmful than stored XSS but no less dangerous. The XSS payload is not stored in the backend of the web application but when a user accesses the XSS payload rich link the user gets affected by it. To exploit reflected XSS, attackers will send a malicious link with an XSS payload to the user. Reflective XSS can be sophisticated through a mix of social engineering.
In mid-2012, cybersecurity researchers at OWASP decided to split XSS into new ways for greater clarity. Here:
- Server XSS: Server XSS occurs when an attacker-supplied payload is included in an HTTP response generated by the server. The payload can be obtained in both ways from a request or a stored location. In this attack the vulnerability is entirely on the server the browser is just showing and executing the code from the server.
By the behavior of payloads, XSS can be divided into two ways. Here:
- Visible XSS: After injecting the payload into the vulnerable location if the payload gets executed in the same location that means it’s a visible XSS. It’s easier for an attacker to execute visible XSS than the other ones.
- Blind XSS: Blind XSS is quite the opposite of visible XSS. After injecting the payload if the payload gets executed in another location that means it is a blind XSS. Because of its blindness, it is a bit harder for an attacker to execute it.
Impact of XSS
XSS can lead to account hijacking, malware attacks, phishing, etc. XSS vulnerabilities attack users of that web application that ruined one organization’s reputation.
A common myth about XSS is that attackers can hack web applications using XSS. But this is completely wrong, XSS can be so sophisticated that there is no guarantee that an admin of that web application will not click on a malicious link containing XSS payload. And an admin hack means the website is also compromised.
Prevention Of XSS
As easy to find an XSS in your web application it is that much easy to prevent an XSS from your website. Here:
- For website security, every input needs to be sanitized. There are many ways to sanitize inputs such as blacklisting characters, encoding each special character in HTML codes, etc. Sanitizing input will protect your web application from attackers injecting XSS payloads A good web developer can do the job.
- use the HTTP-only cookie flag because even attackers somehow exploit XSS vulnerabilities this flag ensures that cookies cannot be accessed by an attacker’s script.
- Sanitize output, preventing your website from running client-input scripts. There are a lot of automated tools that protect websites from client-input scripts.
- Use a Web Application Firewall (WAF), web application firewall will stop attackers from injecting any kind of malicious script into your website. WAF also prevents the website from executing any kind of client-input scripts.
- A web application pentester can find all kinds of XSS vulnerabilities in your website and fix them. You can read this article to learn more about pentesting. → The Process of Pentesting: how experts pentest your application.
- Secure file uploading method, sometimes attackers change file names to malicious scripts, and that gets executed inside of the server. That’s why you should carefully handle the file-uploading method. The best practice for file uploading is to change the file name automatical before storing it on the server.
- Security is a process, you need to continuously monitor your website for XSS vulnerabilities. In every update, you need to check your website for XSS. Keep updated security of the website against cyber threats.
In conclusion, XSS is one of the most annoying and notorious web application vulnerabilities. This is common to find in web applications. And prevention measures are very simple and easy to take. You should take those steps to protect yourself from XSS.