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!