Cross-site scripting (also known as XSS) is one of those vulnerabilities that is commonly misunderstood by beginner security professionals due to its somewhat confusing nature. When most people think of web application vulnerabilities, they think of them in terms of "how can I exploit this web application vulnerability in order to hack this website?". In other words, they limit their thinking of web application vulnerabilities to just exploiting the website or web server itself.
In simple terms, XSS is a vulnerability that is an attack on a user or users of a web site, not the website itself. The website is just the means by which the attack is performed on the user. XSS attacks normally consist of manipulating the user's browser to do unintended things, like redirecting the user to some other website, sending the password of a user to some attacker controlled server, or even seeing what a user types into websites. All this is possible due to JavaScript, which is heavily used on most websites these days.
So how does this XSS vulnerability arise? We primarily see it through websites not filtering input given to it and displaying said input on a web page, which treats it as part of the web page's actual HTML code. What makes this attack quite dangerous is that it allows you to execute arbitrary JavaScript code in a user's browser under the context of that website, so the sky is the limit as to what you can do with this vulnerability.
Let's see this in action. We're going to keep using the DVWA to demonstrate the simplest version of the XSS vulnerability called Reflective XSS. In laymen terms, it's a version of XSS that "reflects" off a web application back to the user in their browser. They are non-persistent, meaning that you can typically see the exploit within the URL of the application instead of within the website itself. This means that all you need to do is get someone to click a link with the URL that includes the malicious code (most likely through social engineering) and it'll execute.
DVWA XSS Page
We have a text box in which we can submit input. When we type in Hello World into the text box and press submit, the website prints back "Hello" in front of whatever you type in the text box. So in my case, it'll say Hello Hello World. This seems simple enough. The key takeaway here is that whatever you put in this box gets put (or “reflected” back) onto the web page.
Entering “Hello World” into the text box
Input gets “reflected” onto the web page with “Hello” in front of it, resulting in “Hello Hello World”
Now let's get a little more complex and type in the following in the search box: <script>alert('XSS Vulnerability')</script> . This is HTML code that pops up a message box when it is put on a webpage. The HTML <script> tag says that anything that is put in here will be interpreted as JavaScript code that should executed in the user's browser. In a securely coded web application, submitting this kind of input would result in it just being displayed on the web page, similar to the “Hello Hello World” from before. When we press Submit, however, we can see that an interesting pop up appears on our browser.
Putting the <script> payload into the text box
Web page reflects the text onto the web page like before, but the web page interprets the text as actual web page code, resulting in the pop up box
Instead of treating it as regular input, the web site treated it as actual code on the website and executed it as if it were part of the website. Also, notice the URL: http://localhost:8080/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28%27XSS+Vulnerability%27%29%3C%2Fscript%3E#. Notice that the exploit is right in the URL itself. This means that if you can get someone to go to this URL, you can have the JavaScript within the <script> tags do something more malicious than just popping up an alert box. For example, you can use the following <script> tag to redirect the user to a completely different (often attacker controlled) website: <script>window.location.replace("https://www.google.com")</script> .
This is beginner example of how XSS works. There are other forms of it, such as stored XSS or DOM XSS, but those can be topics for another day.