Short Intro to Cross Site Scripting XSS
Video Tutorial
The video shows a couple of simple examples in C#, basic testing with Owasp ZAP and mitigation using .NET.
Background
XSS occurs when the developer has trusted some input, but in the case of XSS the input is malicious code usually javascript.
What is it?
The website has taken the input, trusted it and outputted it somehow to the browser where it is executed!
There are two varieties. Stored and Reflected.
Stored XSS is when the malicious input is persisted such as into a database. When the record is loaded and presented to the user, the script is executed.
Using the example from the video, in this image script is being entered into the textbox which will be saved to the database.
The user clicks the Save button. The script is saved to the database completely unsantised. When the user clicks the Load button the developer intended for the label that says "[Output goes here]" to be filled with the text. What will actually happen? You guessed it, the script is sent to the client and executed.
The second type of XSS is Reflected XSS. The website takes an input and immediately returns it to the browser. A common example of this is in search features, where you search for an item and it returns "name of the item not found".
In this example from the video, the user has searched for "isa" (which is a type of UK bank account). Notice it returns the search term straight back to the screen...hence "reflected".
If we change the search term to something more malicious such as some script, what happens? Yup, the script is executed!
Dangers
XSS can lead to sessions being stolen, your machine becoming a zombie if the hacker is using BEEF which is the browser exploitation framework. Using this they can download browser extensions, steal information, and show popup dialogue boxes (that look like logins) and all sorts of other things. This is why unsolicited email is so dangerous because a dodgy link could make a request to a vulnerable site that then XSS's you.
This is why XSS is so dangerous and common. It is easy for developers to make mistakes and easy for hackers to exploit it!
Mitigation
There are some simple things developers can do to mitigate XSS. Don't trust any input and correctly encode data for the client.
You can have a whitelist of allowable characters that can be entered. When you think about it, most textboxes on websites are for things like name, addresses, searches and the like. Therefore things like alphanumeric characters and punctuation characters like ' " . , ! should be allowed. Does your website really need to accept < > % / and other characters? There will be exceptions, but you as a developer need to consider your input. Only you know what is acceptable.
As an extra layer of defence you could use the IIS Request Filtering module which can be handy for old sites that may be vulnerable. Bear in mind this will just mask the issue of vulnerable code. The best way to mitigate is to code correctly!
When sending data to the client ensure it is correctly encoded. For my examples in the video they are webpages so I need to html encode the output.
In C# I would do this Server.HtmlEncode("Your Text");
When this is done in my Reflected Demo instead of executing the script it just shows the text.
Testing
Resources
There's a load of information on XSS with far more depth than this. If you really want to find out all the facts about XSS check out Troy Hunts courses on Pluralsight such as Websecurity and the OWASP Top 10: The Big Picture.