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.

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.

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 http://www.captcha.net/), or to include certain dynamically-generated, hidden fields within the form that must also be present when the form is submitted.

When building a website that connects to a SQL database (i.e. Microsoft Access or SQL Server) it is of crucial importance that care is taken to be aware of SQL Injection Attacks.  These typically occur when the website allows the website user to enter content through online forms (particularly textboxes).  However, the lack of strong variable typing in classic ASP means that any variable that is retrieved from the user's browser can be vulnerable to being used in a SQL injection attack.  At the very least, it would allow the user to perhaps login to a website without needing to know a username and/or password.  Depending on the security settings in the website's database, they may even be able to delete data or execute arbitrary system commands on the machine hosting the database server.

Classic ASP is particularly vulnerable to SQL injection attacks.  For example, a web page that retrieves a particular record from a database table row by retrieving the row's primary key from the querystring can be potentially used in a SQL injection attack.  If the user visits a URL, such as http://www.ajobwebsite.com/jobs/showjob.asp?JobID=12227, then they may be able to append a certain sequence of characters to the end of the JobID in order to force a SQL injection attack.  Fortunately, this particular SQL injection attack can be mitigated by ensuring that showjob.asp converts the JobID query string parameter to a number by using the Cint() function in VBScript or Math.round() in JScript.

Ideally, all user input derived from query string parameters and form fields should be cleansed in order to remove any characters that do not need to be present in a particular variable.  For example, a number field should only contain numbers.  Using the VBScript Replace function can easily achieve this.  Particular care should be taken to remove single quotes or dashes from user input, unless they are specifically needed in a particular variable (for a person's name).  Single quotes should also be converted to double quotes before the variable is used in a SQL statement.

There are two other ways of minimizing the chance of SQL injection attacks occurring.  The first is to use stored procedures to carry out all database queries, rather than constructing SQL statements in the web page itself.  The second is to use the ADO or ADO.NET Command object to carry out database connectivity.  An article on ASPAlliance shows further details of this: http://aspalliance.com/385.

Finally, on an SQL Server, using a dedicated database user with the minimum set of permissions required will prevent a malicious user from being able to do too much, should they discover a way of performing SQL injection attacks against the database.

If you would like to know more about the dangers of SQL injection attacks, as well as information about some of the other dangers facing websites, then the NGS Software website has some useful whitepapers - see http://www.ngssoftware.com.  Of particular note are the whitepapers on SQL injection attacks: "Advanced SQL Injection in SQL Server Applications," http://www.ngssoftware.com/papers/advanced_sql_injection.pdf, "(more) Advanced SQL Injection", http://www.ngssoftware.com/papers/more_advanced_sql_injection.pdf and "Writing Secure ASP Scripts," http://www.ngssoftware.com/papers/asp.pdf.

As described earlier, care should be taken to clean up user input before it is used in SQL queries in order to fend against SQL injection attacks.  Unfortunately, similar techniques can be used by malicious users to perform other actions.  At the very least these can be a nuisance, but there is potential to perform actions that mislead your website's other users, make it easier to launch cross-site scripting attacks or to launch fishing attempts.

Any user input that is gathered by a web application and then redisplayed on a web page should be cleansed before it is displayed on that web page.  In particular, care should be taken to remove all of the HTML tags that a user may have entered or, alternatively, all HTML mark-ups should be removed except for a few "safe" tags, such as bold and italics tags and paragraph formatting tags.  Particular care should be taken to remove <script> tags entered by the user.  Failure to remove script tags will allow a malicious user to run JavaScripts within pages that display their input.  This is a particular problem on websites where one user's input is viewable by many people, such as on bulletin boards and discussion forums.  At the very least they might cause annoying JavaScript alert windows to appear when someone views a page containing their script input.  They could, however, potentially make use of the JavaScript document.location method to cause the user's browser to automatically go to a different URL when they visit your website.

To remove all HTML tags from user input, a regular expression substitution can be used, such as the one shown in the function below.

Function stripHTMLtags(HTMLstring)
Set RegularExpressionObject = New RegExp
With RegularExpressionObject
.Pattern = "<[^>]+>"
.IgnoreCase = True
.Global = True
End With
stripHTMLtags =RegularExpressionObject.Replace(HTMLstring, "")
Set RegularExpressionObject = nothing
End Function

Alternatively, the user's input can be converted using the Server.HTMLEncode method in classic ASP or the HTMLEncode method of the HttpUtility class in the .NET Framework.  This method would prevent any of the user's inputted HTML from being interpreted by a web browser.

See the ASPAlliance articles http://authors.aspalliance.com/brettb/VBScriptRegularExpressions.asp and http://aspalliance.com/555 for further information about using Regular Expressions in ASP.  Regular Expressions are also available in ASP.NET through the System.Text.RegularExpressions namespace.

A safer alternative to allowing users to enter HTML is to permit them to use the Bulletin Board Code (BBCode) text formatting system that is commonly used on many web based bulletin boards.  There are a number of ASP scripts available that will safely convert BBCode formatting to HTML using ASP.

If you have access to your web server's log files then it is extremely worthwhile spending time examining them in order to identify suspicious use.

Even if you use a website's statistics analysis application, there is a good chance that irregular behavior will go unreported.  This is largely due to the fact that most websites' statistics packages are concerned with analyzing the typical usage of website users, rather than flagging up non-standard website usage.

For example, I once worked at a large organization that was periodically experiencing regular surges in the number of website visitors.  Although the commercial website's statistics package in use by the organization was able to identify when the peaks in traffic occurred, it took a manual analysis of the IIS log files to discover the cause of the traffic peaks.

Although manual examination of web server logs is effective, it is worthwhile investigating the various automatic forensic log tools available.  A particularly useful utility is Microsoft's Log Parser.  This utility allows any type of log file to be queried by using a standard SQL syntax, making it a powerful tool for extracting, sorting and displaying summaries of activity from web server log files.  Log Parser may be obtained from the Microsoft download site or from http://www.logparser.com/.  A particularly useful article about using Log Parser to examine web server log files for abnormal activity is "Forensic Log Parsing with Microsoft's LogParser" at SecurityFocus, http://www.securityfocus.com/infocus/1712.

When manually looking at log files, it is also recommended to use a text editor that offers a fuller feature list than the Notepad application supplied with Windows.  Two text editors that are particularly good at handling log files are TextPad (http://www.textpad.com/) and UltraEdit (http://www.ultraedit.com/).  Both of these editors will open files much larger than those that can be opened in Notepad.  They also offer more sophisticated search facilities and allow specific lines to be pasted into new documents.

Unfortunately, there does not appear to be any software packages available that will automatically analyze log files in order to identify suspicious activity.  To a certain extent this may be because the determined hackers with full access to the compromised system will often modify the log files so that they are undetected anyway.  It is, however, possible to obtain Intrusion Detection Systems (IDS) that can be used to identify suspicious activity in near real time.