View RSS Feed

jmurrayhead

ASP Application Security Tips

Rating: 4 votes, 2.75 average.
by on August 17th, 2008 at 10:09 AM (1676 Views)
I posted this as a thread in the ASP Development forum, but now that we have a blog here, I felt this would be a more suitable place for it

Introduction
Although many developers are aware of the importance of application security, many do not know the first place to begin. This will serve as a guide to help you make your ASP application more secure.

Using MS Access Database
Many developers choose to use Microsoft Access as the backend to their application. However, the database is too often placed in a web accessible folder. This is a security risk as it allows web users to guess the database name and download the database. For example, let's say you have a database named mysite.mdb. It is placed within the "/db" folder inside your web root. A malicious user could browse to 'www.yoursite.com/db/mysite.mdb' and gain access to all of your data. To avoid this, you should place your database inside a folder that is not web accessible. This will usually be a higher directory than the root or base directory of your web site. You will then have to modify your connection string to contain the physical path to your database. If your site is hosted and they do not allow you to place your database higher than your website root, then it is recommended that you change your database name to something obscure that can't be easily guessed. For example, 129056AHD544JUH.mdb will be much more difficult to guess than mysite.mdb.

Filtering Input from QueryStrings and Input Boxes
All input that is used in a database query should be filtered for inappropriate content. A method known as whitelisting should be used on all input. Whitelisting allows for only specific types of data to be entered into a field or querystring. For example, let's say you have a field that is used for users to enter their phone number.

Typical US phone numbers look like this: 1-555-555-5555 or 1 (555) 555-5555
Whichever format you choose, you would only want to allow users to enter 11 digits separated by either hyphens or hyphens with parenthesis around the area code. You would not allow any other characters. Regular expressions are great for this type of validation. Also keep in mind the length of characters that should be allowed for each field.

Another example, is if your query takes a value from a querystring. Let's say this value represents a numeric ID. Since the database expects a numeric value, (as the field in the database is numeric), it would throw an error if a string variable was passed to it. In situations like this, you can use the IsNumeric() function to check if a value is numeric or not before you pass it to a query.

When filtering input, it is best to use a combination of client-side (JavaScript) and server-side (VBScript) validation. Using client-side validation allows you to quickly validate input before a request to the server is even made. Server-side validation is the safety net. If a user has turned off JavaScript then client-side validation won't work, but any validation errors will still be caught server-side.

Parameterized Queries
Whether you're using MS Access, MySQL or MS SQL as your database platform, you can and should use parameterized queries. Although you can do all kinds of validation checks, parameterized queries provide an easy way to secure your application against SQL Injection attacks.

For examples of using parameterized queries, see the following:
How To Call a Parameterized Query to an Access Database with ADO
4GuysFromRolla.com - Using Parameterized Queries in ASP

The above links provide two different methods of doing so.

Stored Procedures
Stored procedures offer you an even greater sense of security. Used with parameterized queries, they restrict users to perform only specific CRUD (Create, Read, Update, Delete) operations. For example, if you are using MS SQL Server, you can deny all CRUD operations to the user on table objects and only allow them Execute permissions on specific stored procedures.

Cross-Site Scripting
Cross-Site Scripting (XSS) is a vulnerabilty which allows code injection by malicous users. For example, let's say we have a form field that performs no validation. The input taken from this field is saved in the database and then displayed on the page. Now let's say the user entered the following text and submitted the form:
Code:
<br><br>Please login with the form below before proceeding:<form 
action="destination.asp"><table><tr><td>Login:</td><td><input type=text length=20 
name=login></td></tr><tr><td>Password:</td><td><input type=text length=20 name=password></td></tr></table><input 
type=submit value=LOGIN></form>
This would display a login form on the site to all users. Something like this could be used to capture usernames and passwords from users. This is why validation is important. To prevent database data from rendering HTML, JavaScript or any other code to your pages, use the ASP Server.HtmlEncode method when outputting to a page (unless you are
outputting to form fields). This method applies HTML encoding to a specified string.
Code:
Response.Write Server.HtmlEncode(Request.Querystring("contact"))
Response.Write Server.HtmlEncode(rs("contact"))
The above will output an HTML encoded string which will not render the HTML or Javascript elements to the page, rather, you will see them as regular page text.

Conclusion
Hopefully this guide will help you to build secure ASP applications. There is much more involved in application security, which will be covered at a later time. This should be used only as a guide to securing your ASP applications.

Submit "ASP Application Security Tips" to Digg Submit "ASP Application Security Tips" to del.icio.us Submit "ASP Application Security Tips" to StumbleUpon Submit "ASP Application Security Tips" to Google

Categories
ASP Classic

Comments

  1. don94403 -
    don94403's Avatar
    Good stuff. Security is too often overlooked, with disastrous results. Hey, it would be easier to read, though, if you took out the extra line feeds.
    • |
    • permalink
  2. Memnoch -
    Memnoch's Avatar
    This section could/should be broadened out to include all areas that should be addressed to make an application secure, such as:

    1) Account Harvesting
    2) Handling Login and submission of sensitive information (200 OK server response is BAD).
    3) Cross-Site Request Forgery prevention
    4) Proper Input validation (in addition to querystrings & input boxes)

    etc...
    • |
    • permalink
  3. jmurrayhead -
    jmurrayhead's Avatar
    Yes, you're correct, Memnoch. Unfortunately, those items are not my area of expertise. Better someone like you write a blog on that
    • |
    • permalink

SEO by vBSEO