Search: Go
 Transact SQL
 Other Articles
 Software Reviews

 Canon EOS 300D Samples
 Akihabara Maids!
 More Galleries...

 2009: China
 2008: Tokyo
 2007: Tokyo
 2006: Hong Kong
 2005: New York City

 Search Engine Optimisation
 Build an ASP Search Engine
 My Tropical Fishtank
 SQL Month Name
 SQL Get Date Today
 SQL Year Month
 Other New Stuff...

 Regular Expressions
 Index Server & ASP
 JavaScript Ad Rotator

Home > ASP.NET Articles

Improving ASP and ASP.NET Website Security - Part One

Ideas for improving the security of ASP and ASP.NET web applications.

Part 1 | Part 2 | Part 3 | Part 4 | Part 5

Suppress Server Errors

Hackers and other people with dubious intentions are always on the lookout for websites that display technical error messages. ASP or ASP.NET error messages are often useful to such people. In some cases the hackers can actually think of ways of causing the error messages to appear, such as by playing around with the parameters in the query string.

There have also been instances of hackers looking for certain error messages that indicate known vulnerabilities by looking for specific terms on search engines, such as Google. Therefore, suppressing error messages is an extremely important tool in helping to avoid drawing the attentions of malicious users.

Thankfully, suppressing errors on Microsoft based web servers is very straightforward. In ASP it can be achieved by ensuring that pages use the On Error Resume Next directive. Do not forget that this directive should also be used within each subroutine in the Global.asa, if you are using one. The most common source of ASP errors on live websites are database or filesystem errors. Your application should always check for these, for example by checking the Errors collection of the ADODB Connection object to ensure a database connection has been successful.

IIS also has a setting that allows a website's errors to be replaced with an operator-supplied generic message.

In ASP.NET, application errors can be suppressed by altering the customErrors setting within the application's web.config file. By default, the .NET Framework usually hides the specific details application errors unless the website is being viewed on the local machine.

Do not use .inc as default makes it readable in browser

When using ASP include files, it is usually better to use the .asp file extension rather than .inc. This is because many IIS web servers do not recognize that the .inc files contain ASP content. Although it is possible to associate files with .inc file extensions with the ASP interpreter via the Application Mappings settings within IIS, not many websites are configured to do this.

If IIS is not aware of .inc files containing ASP, then HTTP requests for them will be returned to the client as plain text. This does of course mean that the source code in the file will be viewable by anyone. This is a particular hazard if there is sensitive data contained within them, such as passwords or database connection strings.

Although it is possible that your .inc files may go unnoticed, there are several methods by which they may get discovered.

A malicious user may come across them if they are in a sub-folder with a guessable name (such as "includes") and the folder has directory browsing switched on. Turning off directory browsing will help alleviate this issue.

An ASP error on a page using the include file will show the path to the include file if the error was encountered in that include file. Turning off ASP errors will avoid this issue.

The other advantage of this is that file editors, such as Visual InterDev, will automatically recognize the file as containing ASP code and will syntax highlight and color code the source code appropriately.

Do not rely on HTTP_REFERER Server Variable

The HTTP_REFERER server variable records the URL of the page the user's browser visited before the current page. As such, it is sometimes used to check that a form was submitted from the correct form and that the submission did not originate from elsewhere.

While this is a useful technique to guard against automated form submissions, there are, however, a number of issues with using the HTTP_REFERER server variable.

Some proxy servers and content filtering services mask the value of the HTTP_REFERER or even strip it out altogether before the request arrives at the destination server.

An increasing number of Internet web robots are being used with a fake value for the HTTP_REFERER server variable.

The HTTP_REFERER server variable can be easily faked by many of the tools used to create automated web-crawling robots and form submission utilities.

Consequently, there are disadvantages to using the HTTP_REFERER server variable to increase the security of web applications. Alternative strategies to securing forms would be to include using a graphical sequence of characters that a user has to type into the form before submission (i.e. a Captcha, see, or to include certain dynamically-generated, hidden fields within the form that must also be present when the form is submitted.

Part 1 | Part 2 | Part 3 | Part 4 | Part 5
  Site Map | Privacy Policy

All content is 1995 - 2012