Off the back of a fantastic week at TechED on the Gold Coast, I wanted to share some information. I was inspired by a few sessions but 1 in particular was Rocky Heckman’s hacking top five attacks. So in a 5 part series I hope to share some information I learnt but also some of my own knowledge.
Cross-Site Scripting (XSS) Attacks
XSS attacks use various techniques that allows attackers to perform a variety of "bad things". Some of them include the following;
– appear to rewrite the text of your web site
– abuse the user’s trust in your website to steal browser session information and cookies
– take over client sessions and potentially access the client computer where the browser is being run from
XSS attacks can occur even if Internet Explorer security zones are set as high and if the website is access over SSL or HTTPS. The attacks can be caused by failing to constrain and validate input, failing to encode output or trusting data retrieved from a database. Once an attacker is writing scriptable code, then you can pretty much give away the keys to the castle.
Example Vulnerable Code:
<asp:Label runat="server" ID="lblXSS"></asp:Label> lblXSS.Text = Request.QueryString["Text"].ToString();
Expected Input: hello
Malicious Input: hello<script>alert(‘xss’);</script>
Some example malicious inputs;
2. <script src=[link to code]></script>
3. <div style=width: expression();>
So how can I perform some testing myself?
– create the primary use cases of the website or web application
– identify input points into the website or web application
– list test cases ie.
But I’m an infrastructure guy, why should I care about application security? Are you serious? GET YOUR HEAD OUT OF THE SAND! Remember, this application is running on your infrastructure, give a shit! Security is everyone’s problem not just application folk. </endrant>
Defending against XSS is not too difficult either. Here are some quick and easy steps you can follow.
– validate text fields
– Validate numeric, currency, date, integer, double fields
– on IIS web servers, Disable ASP.NET request validation using ValidateRequest="false"
– in the web.config on the IIS virtual directory, make sure you use ASP.NET RequestValidation – Set validateRequest to true
<pages buffer="true" validateRequest="true" />
– Set the correct character encoding in the web.config
– use the HttpOnly cookie option (System.Net.Cookie class contains an HttpOnly property)
– use the <frame> security attribute (<frame security="restricted“ src="http://www.site.com/page.htm"> </frame>)
– Use innerText to build a page instead of innerHTML
Now here’s an example of some updated code which takes into account XSS mitigants;
String strText = Request.QueryString["Text"].ToString()
if (Regex.IsMatch(strText ,@"^[a-zA-Z0-9]+$"))
lblXSS.Text = Microsoft.Security.Application.AntiXss.HtmlEncode(strText );
If your web application is running on IIS, you should be installing URLScan and configuring this. I’m sure your favourite search engine can help you find URLScan, version 3.0 is the latest.
If your web application is being published with ISA or TMG, you can configure the HTTP filter to block some of the known bad strings, this is a very powerful filter but you need to know how your application actually works. HTTP filters can be configured independently on each publishing rule. This website give you a good overview of what can be done – http://www.krneki.net/blog/2008/10/sql-injectioncss-attacks-and-isa-http.html
If you follow some of the basic rules above for creating your own tests, you can even test this on applications which you are deploying For more information, check out the following links;
In part 2, we’ll look at SQL injection attacks.
Shout out – Rocky Heckman http://blogs.msdn.com/b/rockyh/ (thanks for the inspiration)