Ttdfjt

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.



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

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 ...). Note that this kind of activity can often be hidden from the client so that he does not realize that he 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.

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.

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.

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.