XSS (Cross site scripting) is a client-side vulnerability which means it is possible for a hacker using a browser to send malicious code through a web application.
And the word “injecting” means that wherever the website or the web app asks for user input such as the search field, comment area, update profile form, sign-in or signup forms or so, XSS (Cross site scripting) may be possible.
The MOST common XSS payload that you can find out is
If I talk about the types of XSS, there are three of them:
- DOM based XSS | Type 0
- Stored XSS | Persistent | Type-1
- Reflected XSS | Non-Persistent | Type-2
Stored XSS | Persistent | Type-1
When the injected malicious code gets saved on the server, database, logs, comment field, etc through an input field, it’s known as stored XSS. Now, whenever that resource is requested, XSS gets executed each time. This means it gets executed for each user/client requesting that resource.
Here’s an example
Let’s assume that you (a normal user) accessed a website say Facebook, and everything is running normally. Now, a hacker logs into FB and injects a malicious script (say
<script>alert('Hello')</script>) in a vulnerable comment field.
Now, this script gets permanently stored as a comment on FB and it executes along with the HTML code.
So, when you log in to the facebook, you will see a popup saying “Hello” whenever you try to access that picture (resource) which had this script as a comment. And this is essentially true for any other users as well.
Potential Attack Scenario
An attacker can redirect all the users to a different phishing page and steal the credentials of the users or can run some other malicious script on the user’s side (i.e. browsers) such as stealing cookies, stored passwords or mine cryptocurrencies, etc.
Reflected XSS | Non-Persistent | Type-2
This type of XSS is temporary since it gets executed only once and only for the attacker or the client who injected it.
Example attack scenario
Now, referring to the above example (in case of stored XSS), in this case, the vulnerable field may be a search bar which temporarily executes the script as a query along with the HTML code.
But, in this case, the results of that query will only be visible to the attacker who injected the script.
Now, you must be wondering that What harm can a reflected XSS cause?
Let me give you a thought.
There is an attack known as phishing where you make people believe that they are on a genuine website and people easily believe any information, alert or notice displayed on it to be real.
Now, let’s take an attack scenario where a hacker finds a bank website vulnerable to Reflected XSS. This means that every time this injected “GET” request is sent to the server, a result/response pre-known to the hacker will be sent back.
Let this link be:
So, attacker can simply copy this link and send
Studies show that most people instantly click on a link sent to them as soon as they see a known or a trusted domain such as this in our case
www.bank.com/?id=<script>alert(some_function())</script> without paying attention to the link body.
I think now you understand what will happen when you click on that link!
Now, if I talk about the occurences of these type of XSS, then the most common and easily found one is the Reflected XSS. After that is the Stored XSS and then the DOM based XSS.
You can do a lot when it comes to prevention. Here are some of the things that you can do to secure your website.
- Use a firewall to prevent any hacking attempts
- Follow Secure coding guidelines to close all possible doors for hackers
- Hire professionals to build and maintain your website
- Go for a security audit on your website to uncover most of underlying vulnerabilities beforehand and prevent them from happenning
Mitigating XSS attacks
The most common way to mitigate the XSS is
- To use encoding – Encoding the potential attack characters and keywords such as “<“, “>”, “(“, “)”
- filter/sanitize the input such as “script”, “alert”, etc.
Personally, I have experienced that most websites encodes input characters such as “&” to “amp;” or “%26”, “<” & “>” to “lt;” and “gt;”, etc.
Most common way to filter the input is to direct everthing to a firewall which checks the input against a set of rules. These rules can be a glob or matching some know keywords such as “script”, “<“, “>”, “/ “, etc.
That’s all about XSS! If you liked this information, comment below also do share and like it. Stay tuned for more such content:)