What is an XSS vulnerability?
Cross-Site Scripting (XSS) is an injection attack where malicious JavaScript gets injected into a web application with the intention of being executed by other users.
If you can get JavaScript to run on a victim’s computer, there are numerous things you can achieve. This can range from stealing the victim’s cookies to take over their session, running a keylogger that will log every key the user presses on their keyboard while visiting the website, redirecting the user to a totally different website altogether, or performing some kind of action on the website such as placing an order or resetting their password, etc.
Types of XSS vulnerabilities:
- DOM
DOM stands for Document Object Model and is a programming interface for HTML and XML documents. It represents the page so that programs can change the document structure, style, and content. A web page is a document, and this document can be either displayed in the browser window or as the HTML source.
DOM Based XSS is where the JavaScript execution happens directly in the browser without any new pages being loaded or data submitted to backend code. Execution occurs when the website’s JavaScript code acts on input or user interaction.
- Reflected
Reflected XSS happens when user-supplied data in an HTTP request is included in the webpage source without any validation. An example of this could be an error message which is in a query string of a URL that is reflected onto the webpage.
- Stored
As the name infers, the XSS payload is stored on the web application (in a database, for example) and then gets run when other users visit the site or web page. This type of XSS can be particularly damaging due to the number of victims that may be affected. An example of this could be a blog that allows visitors to leave comments. If a visitor’s message is not properly validated and checked for XSS payloads, then every subsequent visit to the blog page would run the malicious JavaScript code.
- Blind
Blind XSS is similar to a stored XSS in that your payload gets stored on the website for another user to view, but in this instance, you can’t see the payload working or be able to test it against yourself first. An example of this could be a contact form. In the contact form, your message could contain an XSS payload, which when a member of staff views the message it gets executed.
This was a good learning. We made use of Stored XSS to change the password of the malicious account and disable the malicious plugin.
