Hcfyk

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.



• Session Hijacking - HTTP cookies can be accessed
  by JavaScript if the HTTP ONLY flag is not present in the cookies.




• Content Spoofing - JavaScript has full access to client side code of
  a web app and hence you can use it show/modify desired content.




• 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!




• Bypassing CSRF
  protection - You can make POST requests with JavaScript, you can
  collect and submit a CSRF token with JavaScript, what else do you
  need?




• Keylogging - You know what this is.




• Recording Audio - It
  requires authorization from the user but you access victim’s
  microphone. Thanks to HTML5 and JavaScript.




• Taking pictures - It
  requires authorization from the user but you access victim’s webcam.
  Thanks to HTML5 and JavaScript.




• Geo-location - It requires
  authorization from the user but you access victim’s Geo-location.
  Thanks to HTML5 and JavaScript. Works better with devices with GPS.




• Stealing HTML5 web storage data - HTML5 introduced a new feature, web
  storage. Now a website can store data in the browser for later use
  and of course, JavaScript can access that storage via
  window.localStorage() and window.webStorage() Browser & System




• Fingerprinting - JavaScript makes it a piece of cake to find your
  browser name, version, installed plugins and their versions, your
  operating system, architecture, system time, language and screen
  resolution.




• Network Scanning - Victim’s browser can be abused to scan
  ports and hosts with JavaScript.




• 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!




• Redirecting - You can use javascript to redirect users to a webpage
  of your choice.




• 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 first 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

XSS is a command injection of the client side, like the other user pointed out, it can result in any action that can be performed by the user. Mostly XSS is used for session hijacking where the attacker using javascript makes the victim transmit session cookies to an attacker-controlled server and from there the attacker can perform "session riding".

But XSS can also result in complete application takeover. Consider a scenario in which you inject javascript and it gets stored. The admin then loads that into a web browser (usually logs or CMS). If an XSS is present there you now have the admin session tokens. That is why XSS can be very dangerous.

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:

• Someone redirects from your site to a fake login page. Now you have a potential mass security breach of user accounts on your site.


• Someone puts a cryptominer on your site. This will make your visitors' machines work overtime and when spotted, makes you look either grossly greedy and/or grossly incompetent as a sysadmin. Neither of which is a good look.


• Someone redirects traffic from your site to a competitor. I shouldn't have to explain why this is bad.


• Someone puts some javascript in there that makes your site unusable or even crash browsers. Again, should be obvious why this is bad.


• Someone puts DDOS code in your site to try take down your site or a third party. If aimed at you, should be obvious why this is bad. If aimed at someone else and your site is deemed culpable, your hosting provider can cut you off if you do not fix your site for breach of contract.


• Someone replaces your ads with their own. If you rely on ad revenue, they're stealing that revenue.


• Someone uses it to snoop on your users. Hel-lo, breach of GDPR.

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.

But if your users have admin rights, then an XSS vulnerability can easily lead to unintentional admin actions. A classic case of that is a log viewer in your admin area which isn't XSS-proof. Some javascript snippets in your access logs might get executed by your admins and perform administrative actions under their account. This is why you sometimes see javascript snippets in the HTTP headers of the bots which try to hack your website.

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."

The webmaster did this and suddenly the whole website was dead. What happened? The reporter used a XSS vulnerability to insert JavaScript code on his profile page.

The JavaScript code (running in the browser and session of the webmaster) sent requests to the server to:

1. add a new account with with highest rights (for demonstration purposes)


2. to rename PHP-files and SQL-tables on the server (the website had a administration section which allowed this for administration purposes like updates or installing widgets similar to many CMS-systems)

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).