Checklist: ASP Security
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
The following is a list of issues to keep in mind when you are developing Web pages using ASP.
| Step | Reference | |
|---|---|---|
Never trust user input to be of an appropriate size or contain appropriate characters. Always verify user input before using it to make decisions. The best option is to create a COM+ component which you can call from an ASP page to verify user input. You can also use the Server. HTMLEncode method, the Server. URLEncode method, or one of the code examples at the bottom of this page. |
||
Do not create database connection strings in an ASP page by concatenating strings of user input together. Malicious users can inject code in their input to gain access to your database. If you are using an SQL database, use stored procedures for creating database connection strings. |
||
Do not use the default SQL administrator account name, sa. Everyone who uses SQL knows that the sa account exists. Create a different SQL administrative account with a strong password and delete the sa account. |
"Passwords" in Help and Support Center for Windows 2003. |
|
Before you store client user passwords, hash them, base64encode them, or use Server.HTMLEncode or Server.URLEncode to encode them. You can also use one of the code examples at the bottom of this page to verify the characters in the client's password. |
"Encrypting File System" in Help and Support Center for Windows 2003. |
|
Do not put administrative account names or passwords in administration scripts or ASP pages. |
||
Do not make decisions in your code based on request headers because header data can be fabricated by a malicious user. Before using request data, always encode it or use one of the code examples below to verify the characters it contains. |
||
Do not store secure data in cookies or hidden input fields in your Web pages. |
||
When writing ISAPI applications, filters, or COM+ objects, watch out for buffer over-runs caused by assuming sizes of variables and data. Also watch out for canonicalization issues that can be caused by interpreting things, like absolute path names, as relative path names or URLs. |
||
When you switch an ASP application from running in Single Threaded Apartment (STA) to Multi-Threaded Apartment (MTA), the impersonation token becomes obsolete. This can cause the application to run with no impersonation, effectively letting it run with the identity of the process which might allow access to other resources. If you must switch threading models, disable the application and unload it before you make the change. |
Configuring Applications to Use COM+ Services; "COM+ Services" in the IIS Software Development Kit (SDK) |
Code Example
This code example includes a function that removes potentially harmful characters from a string that is sent to the function. In both examples above, the code page is specified to ensure proper encoding. The example below is in Microsoft Visual Basic Scripting Edition (VBScript):
<%@ LANGUAGE="VBScript" %>
<%
Response.CodePage = 1252
Response.Write("Hello, " & RemoveBadCharacters(Request.Form("UserName")))
Response.Write("<BR>This is why you received an error:")
Function RemoveBadCharacters(strTemp)
Dim regEx
Set regEx = New RegExp
regEx.Pattern = "[^\s\w]"
regEx.Global = True
RemoveBadCharacters = regEx.Replace(strTemp, "")
End Function
%>
The example below is in Microsoft JScript:
<%@ LANGUAGE="JScript" %>
<%
Response.CodePage = 1252;
Response.Write("Hello, " + RemoveBadCharacters(Request.Form("UserName")));
Response.Write("<BR>This is why you received an error:");
function RemoveBadCharacters(strTemp) {
strTemp = strTemp.replace(/[^\s\w]/g,"");
return strTemp;
}
%>