I have read so many articles and posts about Cross-Site Scripting (XSS) that I thought ....why not? Why not give it a go and make this as easy as possible.
What is XSS?
So what's the big deal?
Unfortunately, XSS is a very big deal. XSS was placed at the very top of the OWASP Top 10 list for 2007 where it is still leading the pack of application layer vulnerabilies. Now ... it would be reinventing the wheel to try and place all types of sample code on the page so i'll direct you to a nice list for your review. If you are interested in seeing a bit of code, I recommend the XSS Cheat Sheet.... a very nice list from RSnake. Typically, these attacks come in the following locations:
- Search forms
- Bulletin Boards
- Error Messages
Sample Attack Vectors
With XSS, we can look at a couple of simple attack scenarios that might be utilized against a site.
- Simple Script Tag
What I refer to as a simple script tag is basically the "hello world" of XSS. In some component of the application, perhaps a form field input area, a parameter in the URL, an error code in the URL (for example, mypage.aspx?error=xss_script_here) may all be points for injection. A sample would be:
Additionally, we might also discuss what is referred to as Appended URL XSS which would look like:
- Remote Script Call
Calling a remote script is also a nice option with XSS. The opportunity to create your own script and place it on some server and then perform the injection is also very effective. If we were to have created a script and placed it on server "x.com", we might inject the following:
- JS Events
Keep in mind that there are numerous other attack vectors ... I am only listing a couple here.
What about remediation?
Fortunately, (as with most things in this world) the fix is not terribly difficult. There are two things that we need to be concerned about:
- Input Validation
- Outbound Encoding
So let's tackle the Input Validation issue first. With any type of input validation discussion, we can quickly get off on the subject of "White vs. Black" lists and here is my thought -- USE WHITE LISTS. If you're not familiar with White vs. Black lists, the answer is simple. White lists tell your application what you will accept and Black lists tell your application what to look for and to not accept. If I were going to have a party at my house and wanted to invite my friends over -- I would much rather give the door-man a list of my friends and who could come in rather than handing him a list of everyone else in the world (minus my friends) to look for and deny. Not terribly difficult.
So once we have figured out what data we are going to let in to my application, we want to make sure that we HTMLencode data before it is returned to the user. Now....there are a number of ways to use HTMLEncode (each language handles this in their own way; however, here I will show you a nice, clean example in C#.
public string HtmlEncode(
Now...as mentioned before, there are a number of methods to perform HTMLEncode .... seek out your flavor and light it up!