ASP Security Issues

Article
06/16/2017

The following is a list of issues to keep in mind when you are developing Web pages using ASP.

Issue	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.	See Validating User Input to Avoid Attacks, Writing Secure Code.
Do not create database connection strings in an ASP page by concatenating strings of user input together. A malicious attacker can inject code in their input to gain access to your database. If you are using a SQL database, use stored procedures for creating database connection strings.	See Writing Secure Code.
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.	See "Passwords" in Windows Help.
Before you store client user passwords, hash them, base64 encode 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.	See "Encrypting File System" in Windows Help.
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.	See Writing Secure Code.
Do not store secure data in cookies or hidden input fields in your Web pages.	See Writing Secure Code.
Always use Secure Sockets Layer (SSL) for session-based applications so that you never risk sending session cookies without encrypting them. If session cookies are not encrypted, a malicious user can use a session cookie from one application to gain entry to another application that resides in the same process as the first application.	See the topics titled "Secure Sockets Layer (SSL)" and "Encryption" in IIS Help, which is accessible from IIS Manager.
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 or URLs as relative path names or URLs.	See Writing Secure Code.
When you switch an ASP application from running in Single Threaded Apartment (STA) to Multi-Threaded Apartment (MTA) (or from MTA to STA), 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.	See Configuring COM+ Services in IIS , and see "Configuring Applications to use COM+ Services" in IIS Help, which is accessible from IIS Manager.