XSS or Cross Site Scripting is a technique that allows malicious users to insert JavaScript code into a page from a target web site.
When the page is then displayed or refreshed, the attacker’s JavaScript is executed by the browser just like any legit JavaScript code contained in the code of the page.
If successful, this technique opens up a wide variety of options to the attacker:
– stealing cookies and impersonating a different user’s session (if this user happens to be an admin, it’s your lucky day),
– resetting other users’ passwords,
– redirecting users to a different and malicious web site,
– running a keylogger on the victim users’ machines, etc.
How do you do it?
There are different ways of attempting to inject JavaScript into a third party web site.
One of the techniques is to include the malicious JavaScript code (or payload) into the URL that the victim user will use to connect to the web site. However, you don’t typically get to type what you want into a remote third party user’s browser, right? So the tricky part is indeed to get the payload into that user’s URL bar in their browser.
One way of doing this is through a phishing attack, where the target user gets an e-mail and is tricked into clicking on a link. If the payload is in the link, then the JavaScript gets executed as the page is loaded and displayed. This is called reflective XSS.
Another common method is to type or paste the code into entry fields on a target web page, that then get reflected on the page. This is typically the case of search fields (when the search results are then displayed on the page), comment fields on blog posts, or even posts on forums, chats or other social media.
In this case, there is no need for phising attacks. Including the malicious code in a comment field on a blog post will store the code in the site’s content database. The code will then be executed every time a subsequent user will visit the post (and since the code is executed, it will not be treated as text and will not be displayed on the page, this means users will not actually see it on the page). This is called stored XSS.
Most of the time, web developers will sanitize their input streams by filtering out JavaScript code from their input fields and other entry points. In which case, XXS will not be so easy.
However, some web developers may lack a full understanding of XSS and leave their site insufficiently sanitized. That’s where an attacker can have leverage.
Hungry for more?
You can take things further with :
Bugcrowd University’s XSS video tutorial.
HackerSploit’s XSS video tutorial.
TryHackMe also has two XSS training rooms here and here.
Have fun!