Web pages never trust that the user input has the appropriate size or contains the appropriate characters. You should always validate user input before you use it to make a decision. The best option is to create a COM + component so that you can call the component from an ASP page to validate the user's 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 a database connection string in an ASP page by connecting a string entered by a user. Malicious users can gain access to the database by inserting code into their input. If you are using a SQL database, use a stored procedure to create a database connection string.
Do not use the default SQL administrator account name SA. Every user who uses SQL knows that the SA account exists. Create additional SQL management accounts with secure and reliable passwords, and delete the SA account.
Before you store the password for the client user, use a hashing algorithm for these passwords, Base64 encoding, or use Server.HTMLEncode or Server.URLEncode for encoding. You can also use a code example at the bottom of this page to verify the characters in the client password.
Do not place the Admin account name or password in the admin script or ASP page.
Do not make decisions in your code based on the request headers, because the header data can be forged by malicious users. Always encode or use the following code example to verify the characters it contains before you use the request data.
Do not store the security data in a Cookie or hide the input fields in a Web page.
Secure Sockets Layer (SSL) is always used for session-based applications to avoid the risk of sending them without encrypting the session Cookie. If the session cookie is not encrypted, a malicious user can use the session cookie in one application to access another application in the same process.
When writing an ISAPI application, filter, or COM + object, be aware of a buffer overflow caused by variables and data size. Also note the normalization issues that may result from interpretation, such as the absolute pathname being interpreted as a relative path name or URL.
The impersonation token will become obsolete when an ASP application running within a single apartment (STA) is switched to a multithreaded apartment (MTA). This can cause the application to run without impersonation and to run efficiently with the identity of the process that may allow access to other resources. If you must switch the threading model, disable the application and uninstall it before making any changes.
code example
This code example contains a function that deletes potentially harmful characters from a string that is sent to the function. In the two examples above, specify the code page to ensure proper encoding. The following example uses Microsoft Visual basic®scripting Edition (VBScript):
<%@ language= "VBScript"%>
<%
Response.CodePage = 1252
Response.Write ("Hello," & Removebadcharacters (Request.Form ("UserName"))
Response.Write ("<br>this is why to 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 following example uses the 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;
}
%>
