Working of Cross-site scripting
When the attacker exploits a vulnerability on the software of a website, only then can they inject their code into a web page of the victim's website. After successfully exploiting the vulnerability, attackers can inject their script, which will be executed using the browser of the victim.
The cross-site scripting attack will be very useful when most of the publically available pages on the website have vulnerabilities. In this case, the malicious code can be injected by adding their malicious content, phishing prompt, ads on the website to target the website's visitors.
Types of Cross-site scripting attacks
There are various ways to use cross-site scripting on the basis of our goals. The most common type of cross-site scripting attacks is as follows:
Stored Cross-site scripting attack
When a payload is stored by the attacker on the compromised server, in this case, a stored cross-site scripting attack will occur. Due to this, the malicious code will be delivered by the website to the other visitors. In this attack, the initial action is only required by the attacker, and due to this, many visitors have to be compromised. The stored cross-site attack is the most dangerous cross-site scripting. An example of this attack includes the fields of our profile like our email id, username, which are stored by the server and displayed on our account page.
Reflected Cross-site scripting attack
When the data is sent from browser to server, and the payload is stored in that data, in this case, reflected cross-site scripting would occur. An example of this attack includes a contact form or website's search data sent to the target and contains a malicious script. Search form is another type of reflected cross-site attack in which a search query is sent by the visitor to the server, and the result can only be seen by visitors. Victim's custom links are sent by the attackers that direct visitors towards the vulnerable page.
Self Cross-site scripting attack
When the vulnerability is exploited by the attacker, which requires manual changes and extremely specific context, in this case, self cross-site scripting attack will occur. Specific changes include setting our information to a payload or cookies values types of things.
Blind Cross-site scripting attack
When the result of an attack cannot be seen by an attacker, in this case, blind cross-site scripting will occur. In a blind cross-site scripting attack, the vulnerability lies on that page, which can only be accessed by authorized users. If the attacker wants to successfully launch an attack, this requires more preparation for this. The attack will not get any notification if the payload fails. Hackers can also use polyglots if they want to increase the success rate of these types of attacks. Polyglots can work in different scenarios like a script tag, plain text, and attributes.
DOM-Based Cross-site scripting attack
Prevention of Cross-site scripting attacks
The website vulnerabilities can be exploited using the variety of methods leveraged by an attacker. If we want to reduce the risk of cross-site scripting, there is no single strategy. Unsafe user input helps the cross-site scripting attacks because it is directly rendered onto the website's web page. This attack would be impossible if the inputs of the user are properly sanitized. We can ensure that the inputs of users cannot be escaped on our website using multiple ways. Using the following protective measures, we can harden our web applications and protect our website.
We can restrict the input of a user to a specific whitelist. This practice allows us to only send the safe and known value to the server. If we know about the receiving data, like the content of the drop-down menu, the restricted user input will only work.
Restrict HTML in Inputs
HTML is limited to trusted users. If we want to allow formatting and styling on an input, we can use Markdown instead of HTML to generate the content. If we want to use HTML, we should sanitize it with a robust sanitizer like DOMPurify, which is used to remove all the unsafe code.
If we are using content on a page generated by a user, we should ensure that it would not result in HTML content by using entities in place of unsafe characters. The appearance of regular characters and entities are the same, but the entity cannot generate HTML.
Use HTTPOnly Flags on Cookies
We can virtually patch attacks against our website using the firewall. This method is used to intercept the requests like SQLi, RCE, XSS before our website get malicious requests. The large scale attacks like DDOS can also be protected by it.