Cross-Site Scripting (XSS)
What is cross-site scripting?
The XSS vulnerability or Cross-site Scripting is a vulnerability, which affects a web application’s front-end.
This vulnerability has been named for the first time in January 2000 by Microsoft and it is one of the most common web application vulnerabilities (Cross-site scripting).
According to the OWASP website, it is present on two-thirds of the web (A7:2017-Cross-Site Scripting (XSS) | OWASP).
Despite its simplicity, it can be classified into three different forms.
What are the types of cross site scripting?
An explicit name because malicious content is saved in a database and it appears every time the web application’s page is visited.
Non persistent vulnerability
It uses the HTTP parameters (POST & GET). The server sends it to the user’s browser only once.
Document object model (DOM-based) vulnerability:
Unlike the two others described before, malicious payload is not sent to a server but executed directly by the user’s browser.
With the stored cross-site scripting attacks, the server stores the script in the database and returns it only when a user’s browser visits the page.
It is impossible for the victim to anticipate an attack before getting the page, making the stored XSS vulnerability probably the most dangerous one in the XSS family.
Reflected and DOM-based XSS attacks are the opposite of this and must be placed in the settings of a query, especially in the URL.
This means that these two types of XSS attacks can be present in links and are used by hackers in emails. Using a bit of social engineering, hackers can have their victim click on a URL and the malicious script will be executed.
XSS attacks can be performed in many ways, from a tag on a forum, to code in source attribute of an image.
Example of Cross-Site Scripting attack on the web server
1. A chat’s basic use
We have two users: Loris, the hacker and Paul, the victim.
The goal of Loris is to redirect Paul’s browser on his web server to steal his cookies.
When he clicks on the «Post» button, the message is sent to the server.
When he clicks on the « Post » button the message is sent to the server.
The server will then store it in the database.
When Paul actualizes the chat, the server will send back the message, which will then be inserted in the HTML code.
Loris’s message will be displayed normally on his browser.
2. How to detect cross-site scripting?
Same as the first message, the server will store it and then send it back to Paul.
The <strong> tag will be considered as HTML code and put inside the DOM like the other tags.
The message will be displayed in bold and red on the user’s browser. This example was used by Loris to test if the application was vulnerable to XSS. He can now perform a XSS injection with malicious content.
3. What is an XSS attack example?
Loris knows the chat is vulnerable to a stored XSS attack and decides to steal Paul’s cookies.
- document.location that can be used to redirect a browser to another URL.
- document.cookie that contains cookies of an user on the actual website.
All he has to do now is log on to his website to get Paul’s cookies.
This case represents a simple example of XSS injection but it’s up to the attacker to imagine the technique of his choice to achieve his objective (encoding, obfuscation of the code, etc.).
OWASP best practice example
The Open Web Application Security Project (OWASP) provides a list of rules to apply to protect your web applications:
To implement this rule, you can use functions available in the various programming languages or use bookstores intended for sanitizing the user’s input.
It should be noted that most modern frameworks like Angular, React or Vue implement this feature natively.
- Content Security Policy is a computer security standard used to prevent from XSS and code injections attacks (Content Security Policy).
So integrating a Content-Security-Policy header into HTTP data is also a good way to protect users’ browsers because it lets them use only resources from the server.
You should notice that Content Security Policy needs to be well configured because it can leak to other security vulnerabilities.
- Another interesting header and the X-XSS-Protection that automatically filters some XSS attack, it is enabled by default.
You can check all recommendations of the OWASP here: Cross Site Scripting Prevention – OWASP Cheat Sheet Series
How to protect your web application against XSS with R&S®Cloud Protector
To protect a web application against XSS vulnerabilities, R&S®Cloud Protector can do two things:
The Blacklisting strategyIt is used on all levels of protection:
The Scoring list
Scoring List is activated on Advanced and High level of protection:
At the end of the analysis, if the score is above the defined limit, the input is considered as an XSS attack so the request will be blocked and redirected.
Request your 14 days free trial
What are you waiting for?