Search: Go
 Transact SQL
 Other Articles
 Software Reviews

 Canon EOS 300D Samples
 Akihabara Maids!
 More Galleries...

 2009: China
 2008: Tokyo
 2007: Tokyo
 2006: Hong Kong
 2005: New York City

 Search Engine Optimisation
 Build an ASP Search Engine
 My Tropical Fishtank
 SQL Month Name
 SQL Get Date Today
 SQL Year Month
 Other New Stuff...

 Regular Expressions
 Index Server & ASP
 JavaScript Ad Rotator

Home > ASP.NET Articles

Improving ASP and ASP.NET Website Security - Part Four

Ideas for improving the security of ASP and ASP.NET web applications.

Part 1 | Part 2 | Part 3 | Part 4 | Part 5

Do not use descriptive error messages on login or other pages

When creating a standard username/password login page, care should be taken to ensure that malicious users are not given clues about the nature of the login system. The following error messages should be avoided when displaying a failed login attempt.

"The password for this user is incorrect" - This confirms that the malicious user has a valid username.

"The password should be 6 characters long" - The malicious user now knows the length of a valid password.

"The username could not be found" - The malicious user can simply keep trying until they enter a valid username.

Displaying a more generic error message along the lines of "The username or password you entered is incorrect" offers fewer clues about the nature of the login system in use. This makes it just a little bit more difficult for someone to login using someone else's account credentials.

Limit the number of login attempts

The accessible nature of web based applications together with the ease of writing automated login scripts mean that it is relatively easy to write a script to automatically guess website login credentials. The task is made even easier if the malicious user already knows a login name or the website does not support the use of strong passwords (i.e. case sensitive, mixed case passwords mandatory or passwords that include non-alphanumeric characters).

For this reason, it is recommended to ensure that each session has a limit to the number of failed login attempts. Since most automated HTTP scripting methods do not support sessions, it is also recommended to ensure there are not more than a certain number of failed login attempts from a specific IP address in a specific time period.

Monitoring the IIS web server log files for signs of repeated, failed login attempts is also highly recommended. A utility such as Microsoft's Log Parser can be used to achieve this.

It may also be worth considering either temporarily or permanently disabling the accounts of users that appear to have a large number of failed login attempts in a specific time period.

Switch Directory browsing off

Again, this is basic advice, but it is essential to ensure that the directory browsing setting within IIS is set to off. If directory browsing is on, it means that a user will automatically see the contents of a folder that does not contain a default document (i.e. default.htm or default.asp on most IIS servers).

This is especially hazardous if you have confidential information on your website or the website earns its revenue from selling content that is downloaded from the website itself, such as documents or software download files.

Needless to say, you should also ensure that IIS is also configured to enable default documents. Switching the directory browsing off and enabling default documents should be done at the website level, so that any new sub-folders created on the website inherit the settings.

Part 1 | Part 2 | Part 3 | Part 4 | Part 5

  Site Map | Privacy Policy

All content is 1995 - 2012