Classic ASP - Cross Site Scripting (XSS) [x02]

And we're back for more Classic ASP!... I'm sorry it had to be you. In this post, I will be describing how Cross-Site Scripting (XSS) can be a very real issue in Classic ASP. In fact, it's the issue I find most commonly when auditing code.

What is Cross-Site Scripting?

To save my own sanity, Cross-Site Scripting will be from here on out be referred to as XSS. Whew. Glad, we got that over with.

OWASP defines XSS as:

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it. - https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

In simpler terms, anytime user input is placed into the output of your ASP page through any means, there's potential for XSS. Let's show some examples to help drive the issue home.

XSS Examples - Common Problems (Do NOT DO These)

So, what's actually wrong with these examples? In every example, user-input from querystrings or POST-body parameters is being used directly in the ASP response. The syntax "<%= %>" is equivalent to a Response.Write. A malicious user can add closing HTML tags, and then open their own HTML content which the page will happily return for your user. This is classic HTML Injection with the potential for easy XSS.

Fixing / Protecting from XSS Attacks

The first step to protecting your web application is to understand the context of where you are placing user-defined variables. There are 3 primary areas I will focus on that you should be aware of:

1. URL redirect values
2. HTML field values / arbitrary HTML
3. Dynamic javascript

The first issue references my first example above. When you are creating dynamic links or form post locations, ALWAYS wrap user-defined variables in Server.URLEncode. This will sanitize the link by escaping any special characters that can't be used in a URL. Special characters will get converted to their percent equivalent defined in the RFC.

The second issue references my second example above. When you are assigning field values using user-defined values or inserting user-defined variables into HTML, always wrap them in Server.HTMLEncode. This will escape all HTML special characters like "<" and "=" such that the browser does not render their HTML equivalent but instead their ASCII equivalent. Keep in mind, HTMLEncode does break links, so do not use this for links/form locations.

The third issue references my third example above. When you are using Classic ASP to generate dynamic javascript, you need to again escape user-defined variables. The problem with javascript is that Classic ASP does not have a built-in function to escape javascript. However, the author over at Dave Heavy Industries provided a nice method stub to properly escape javascript (http://www.daveheavyindustries.com/2011/10/25/asp-classic-escape-string-for-js/). That method needs some additional work, but it's a great start for properly escaping javascript special characters.

Sanitize Your Output!

At the end of the day, you should always properly escape/sanitize your output. Just always remember to consider where you are outputting to, and encode appropriately. And as always, never trust the user's input. Never. Ever.

Thanks for reading this far. Next up is SQL Injection... Stay tuned!

Classic ASP - Intro to User Input [x01]

This the beginning of a promised multi-part set of posts on Classic ASP. Why might I even write a post about such a dated language? Well, I personally maintain a very large chunk of Classic ASP for my job, but it also still has quite a foothold on the internet (including ASP.NET because .ASPX and other random decisions by Microsoft). Low and behold, the internet is still stuck on a lot of old, dated technology. These factors need to be kept in mind when evaluating the security of a site, web app, or any other web service.

Source: http://trends.builtwith.com/framework 

The Research Phase...

I made the terrible mistake of googling about for Classic ASP best security practices which led to some rather hilarious examples of horrible things to do. Granted, most articles were written five to ten years ago, soo... I guess they are excused. Either way, I found some good, some terrible, and some mildly in-between. I'll be sharing my opinions and the opinions of the others for the rest of these blog posts. Expect about one (maybe two) OWASP Top 10 items to appear in a post.

Let's Talk About User Input

Web, like all other types of programming, has areas where the user can input information. These are the areas which matter the most for almost ALL attacks. Before securing Classic ASP, you need to know how input from the user is gathered. Listed below are most (I'm not perfect) methods for obtaining information from the user.

• Request.Form() -- Data in the POST body of a web request
• Request.QueryString() -- Data in the request's URL query string (ex. foo.com?item=1)
• Request.ServerVariables() -- Other data in the request (ex. User Agent, Referrer, etc)
• ex. Request.ServerVariables("HTTP_USER_AGENT")
• Request.Cookies() -- Cookies attached to the request

Refer to the MSDN Article on Request for more information.

These calls will be very important for almost every other post. As with most security practices, the user is to NEVER be trusted. It's always best to assume all users are malicious.

XKCD 327 - Bobby Tables (aka Why Not to Trust User Input)

That ends this part of my Classic ASP series. Up next is Cross-Site Scripting (XSS)... Stay tuned!

Fond Beginnings

Everything starts somewhere, so let's just begin the nonsense starting here...

A Little About Me

I'm Sean, and I'm currently a college student on the fast track to graduate (I think I'm about 4 months out or so). I currently work in the Information Security field, primarily focused on Web Application Security. My primary focus with this blog is to convey interesting (hopefully relevant) security knowledge as well as new technologies that I stumble across. I've been meaning to throw together a blog forever, so I hope this thing actually takes off this time. Guess we'll see!

What's Next?

The plan is to write things as I come across them however, I do have some ideas lined up for a Classic ASP set of posts regarding good security practices while using the frigging ancient language. I fortunately have the pleasure to work with it on a daily basis, and I have seen some of the absolute worst atrocities the language allows. Stay tuned for that saga.

That's about it for now. Thanks for reading this far, whoever you are.