16 Jun 2006
In the first part of this article, Brett provides ideas for improving the security of ASP and ASP.NET web applications.
This article has not yet been rated.|
Views (Total / Last 10 Days):
|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
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.
|Guard web applications against SQL Injection Attacks|
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
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.
|Clean user input before redisplaying|
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
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
when someone views a page containing their script input. They could, however,
user's browser to automatically go to a different URL when they visit your
To remove all HTML tags from user input, a regular
expression substitution can be used, such as the one shown in the function
Set RegularExpressionObject = New RegExp
.Pattern = "<[^>]+>"
.IgnoreCase = True
.Global = True
stripHTMLtags =RegularExpressionObject.Replace(HTMLstring, "")
Set RegularExpressionObject = nothing
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
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.
|Regularly examine IIS log files for signs of unusual
If you have access to your web server's log files then it is
extremely worthwhile spending time examining them in order to identify
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.
No comments posted yet.