Cross site scripting(XSS) in 10 mins
Tags: security, javascript
Published: 2021-07-07 20:19:27

What if we have control over the JavaScript of another website? Let your imagination run wild on this one! What could be the possibilities in this case?

We know that JavaScript has access to the HTML documents via the DOM API's which are provided by the browser itself. This means we can manipulate the DOM and make it look different, like changing the styling or the HTML structure of the page or we can read some cookies using `document.cookie` and send it over to your website via Ajax request or form submission or some other way.

But I think you get the idea that I am trying to convey here, having access to JavaScript on another website in a different user's context can be very problematic.

Now the question is can we really inject some JavaScript into another web page? Well, the answer is yes!!!

And that's exactly what we call XSS or cross-site scripting. In simple words, it is merely a JavaScript injection technique.
Now to explain this with an example let's do a demonstration of an XSS attack. Note that doing an XSS testing is a punishable offense(read cybercrime) so do not do it on an actual website. For learning purposes there are some sites and tools available, we will use: https://xss-game.appspot.com/level1/frame?
Now once you visit this link you will see the following page:
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5ayjbhy2kpk87mbgm3ay.png)Now what happens here is whenever you enter a query into the search box and click search an HTTP request is sent to the server along with the query that you entered, the server then processes the request and gives a response accordingly which is then displayed on your webpage.(Note this site will always return no results found for any query as the purpose of this site is to make you understand XSS and not serve requests)
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bmi58dpk1eg0tforu2qn.png)
Here we type 'hello' and hit search which sends the request to the server with our entered query as a parameter and the server responds with no results.
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0zx526kanuwa9u22wvgn.png)
Notice the query='hello' parameter being sent in the request in the above image.
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3qs2zm1vxo35oerijq1b.png)
Notice the response sent back by the server in the above image.
 
Now let's inject some JavaScript using the script tag and cause an XSS attack, see the image below:
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0ydycew5lp5qymvbwlhv.png)
Here we are injecting the JavaScript alert function using the script tag through the input element of the page. And when we hit the search button this code will be executed and we will have an alert box on the page.
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8e2up4scknbsx3qo0jiy.png)
![image](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/41ub3dmloo233moiy93z.png) Also, check the network tab in the above image, the response is an HTML page and the browser does not know that the input that we sent is being reflected in the response It assumes the whole response is HTML, and thus you can see that our inserted code became a part of that HTML response as script tags are allowed in HTML pages and thus the code gets executed. An attacker can insert his code in this manner and can steal confidential information or user credentials or tokens thus leaving the site vulnerable.(Note: HTML tags or style tags can also be inserted in the above case to deface the page).
There are different types of XSS:
1. Reflected XSS

     We just saw this in the above example where the input was reflected in the response and identified as a script block and then got executed.
2. Stored XSS

     This is the same as the first one but the input is not just reflected but instead, it is persisted or stored in the database and then shown back to the user by pulling it out from the place it was stored. This is an even more powerful attack as the malicious input is stored in the DB and injects everyone who views the page that depended on your input. An example would be the comments section of any website, now if you use the comment section to inject malicious code then the comments containing the malicious code would be stored in the DB and will affect every user that views that comment on the site. Check this video: https://www.youtube.com/watch?v=2GtbY1XWGlQ
3. DOM XSS

    In this the user's input directly lands inside the dangerous part of the JavaScript code, this happens on the client-side.
4. Mutated XSS

    Here the user input is mutated or changed in some way by the browser before inserting it into the DOM which can sometimes lead to cross-site scripting.

Thus Cross-site scripting aka XSS is basically a JS injection. If you are an application developer you will eventually come across this vulnerability and will have to work your way to fix it or mitigate the risk. It is a huge concept and there as some libraries like DOMPurfiy that sanitizes JS and spits out clean HTML.