I am a software engineer and have been watching a lot of videos about XSS.
But I fail to understand how is it dangerous if it runs on the client side and does not execute on the server side which contains the databases, and many important files.
Below are the things an attacker can do if there is XSS vulnerability. Content taken from somdev blog
- Ad-Jacking - If you manage to get stored XSS on a website, just inject your ads in it to make money ;)
- Click-Jacking - You can create a hidden overlay on a page to hijack clicks of the victim to perform malicious actions.
Credential Harvesting - The most fun part. You can use a fancy popup to harvest credentials. WiFi firmware has been updated, re-enter your credentials to authenticate.
Forced Downloads - So the victim isn’t downloading your malicious flash player from absolutely-safe.com? Don’t worry, you will have more luck trying to force a download from the trusted website your victim is visiting.
Crypto Mining - Yes, you can use the victim’s CPU to mine some bitcoin for you!
Keylogging - You know what this is.
Crashing Browsers - Yes! You can crash browser with flooding them with….stuff.
Stealing Information - Grab information from the webpage and send it to your server. Simple!
Tabnapping - Just a fancy version of redirection. For example, if no keyboard or mouse events have been received for more than a minute, it could mean that the user is afk and you can sneakily replace the current webpage with a fake one.
Capturing Screenshots - Thanks to HTML5 again, now you can take screenshot of a webpage. Blind XSS detection tools have been doing this before it was cool.
Perform Actions - You are controlling the browser,
Maybe a real life example would help to understand how dangerous an apparently minor security flaw, like XSS, can be.
As part of a security assessment my company was tasked with trying to access the CEO personal e-mails.
I managed to get its personal e-mail address through some OSint, now one could go for a spear phishing with a custom version of one of the many info stealer malware but I prolonged the information gathering phase a little longer.
It turned out the CEO loved boats and it was selling one of theirs in a boat-selling site.
The site seems pretty amateur, I registered and fooled around a bit. And what have I found?
The site lets you manage your password prefilling a password field with the current one, spurred on by this I investigate the site a little bit more.
I came across a stored XSS vulnerability: when you answer an offer you can put arbitrary HTML code, including scripting, in it and it will be executed in the reader browser!
Seem pretty "innocuous", doesn't it? What if you combine it with the badly management of the password?
So I crafted a script that fetched the password page (it's an intra-domain request, SOP is satisfied), extracted the password and the client information (UA, OS and similar) and send it to a C&C of mine.
Then instilled a sense of urge to the CEO by carefully writing an e-mail informing them about my "intention" to buy.
After a day I received the password they used to log in the boats site.
As expected it was the same password used for their e-mail (there was no 2FA, I can't remember if it was a thing yet) and I was able to access the webmail (the client information was used to simulate a legitimate access, in case it was necessary to keep a low profile).
Long story short, an attack is not a single atomic step, it's made of little conquers. If you give your adversary room for a step, you'll never know what they can do from there. An XSS is room for the attacker, as you have seen quite a bit of it.
Attacker-controlled code, which runs within the context of the web application on the client side, has full control over what the client does and can also read the DOM of the HTML page, etc.
This means it can both steal secrets which are inside this page (passwords, etc.) and also do things as logged in client (like buy something, send bomb threats in a mail client, etc.). Note that this kind of activity can often be hidden from the client so that he/she does not realize that he/she is currently attacked.
When XSS was ﬁrst becoming widely known in the web application security community, some professional penetration testers were inclined to regard XSS as a “lame” vulnerability
source: Web Application Hackers Handbook
An XSS attack is not a danger to the server. It's a danger to the reason you have a server. Not in a technical sense but very much a human one, as any kind of XSS attack originating from your site usually ends with your reputation down the toilet. A few test cases:
Most of the possible consequences of XSS vulnerabilities affect the user, not your server. So if you don't care about your user getting their accounts on your website compromised or your users seeing content on your website which doesn't come from your server, sure, ignore those vulnerabilities.
To give you a real life example where XSS was used to directly take over the server in an incident about 10 years ago (although I have forgotten the name of the (small/unimportant) website and I doubt it exists anymore):
Report to webmaster: "There is XSS vulnerability on your website. You should fix this. How should I send you the details?"
Answer of the wannabe webmaster: "Show me how you would misuse this. My server is super secure! Try it if you want but you will have no chance."
Answer of the reporter: "Then take a look at my profile page on your website."
Additional damage could have been done by sending a request to the hosting company to cancel the subscription of the server and of the domain and transfer money from his banking account (provided the webmaster was logged in the hoster/domain registrar/bank and they had no CSRF-protection which wasn't that uncommon 10 years ago).
Also don't forget XSS-worms like the MySpace-worm Samy that spread over all profile pages and might DDOS your server or harm your users.
It looks like you're looking for danger to the server (including SQL etc.), not the client, so many dangers don't apply.
But there is a danger to the server from what the client is allowed to do on the server. If the client has permission to change the database, so can an attacker. And the same goes for anything a client has permission to do on the server.
You have from other answers a very good list of technical reasons why XSS is a problem. I will give another perspective.
XSS is a vulnerability which is quite easy to bring into your code, and is discoverable by scanners. This is probably one of the reasons why it is relatively well known to the "general public", including journalists (in the sense of "I heard about that").
If you have one publicly available, it may then be described as
Sai Kumar LLC has an extremely vulnerable site, because it has an XSS. XSS is a Very Dangerous Vulnerability. Very. It is.
It allows all your data to be stolen. It does. The͟ ̨da҉t͘a̵ ͢haś ̴al͞r̀ead́y ͠b̷e̷e̶n̨ s͝t͜o̢l͝e͜n. Įt̨ ̷ha̵s.
You can then do all kind of belly dancing explaining that it is not the vulnerability, the erratum will be posted in font 3 pt on page 74, grayed out.
This is why I systematically raise the CVSS of XSS findings on my public web sites (when they are revealed by a pentest, scan or other tests).