Transact SQL Other Articles Software Reviews
Improving ASP and ASP.NET Website Security - Part Five
Ideas for improving the security of ASP and ASP.NET web applications.Part 1 | Part 2 | Part 3 | Part 4 | Part 5
Use IP address restriction to improve administrative site security
If your website contains an administrative web user interface accessible via the Internet, then it is advisable to use as much security as possible. It is particularly advisable to restrict access to a single IP address or a range of IP addresses if only one or several machines are going to require access to the administrative functions.
Including IP address restrictions is possible through the IIS management console. IP address restrictions may be applied to entire websites, as well as individual folders and even files. It is also possible to put in IP address checks at the application level by making use of the REMOTE_ADDR server variable.
Be wary of using DNS-less Connections
DNS-less connections are fairly common on websites that make use of Microsoft Access. While DSN-less connections to file based databases are convenient in that they do not require access to the server in order to configure DSN connections, there are security implications associated with DNS-less connections. The main issue is that the DNS-less connection will usually contain the filename of the database, making it much easier for a malicious user to find the filename of the database should they be able to gain access to the website's source code.
See the following section for other suggestions about improving the security of Microsoft Access database driven websites.
Secure your Access database
If your website uses Microsoft Access (or other file based database) then particular care needs to be taken to ensure the information contained within it does not find its way into the hands of malicious users. Needless to say, sensitive information such as credit card numbers should never be stored within the database, especially in an unencrypted state.
The following points will help to secure your database:
Be wary of uploaded files
If you have a file upload facility within your website then it is critical to perform a check on the types of files that may be uploaded. This is especially critical if the uploaded content is going to be saved to a folder that is accessible via the web. This is because an uploaded file type could be executed on the server by a user who makes a standard browser request for the file once it has been uploaded.
Although it is essential to black-list certain file types (such as .asp, .aspx, and if your server supports it, .php), a safer alternative is to provide a white-list of specific file types that can be uploaded (such as .jpg, .gif and .png for an image upload facility). It is also worthwhile including a maximum file size that can be uploaded - most file uploading server components allow such a limit to be set.
If you are intending to use uploaded files (such as resumes submitted by candidates using a job vacancies site for example) then it is also a good idea to implement a virus checking facility before the content reaches a business processes that make use of the uploaded file.
Submit your application to performance testing
Strange things can often happen to web applications when they are under heavy loads. It is, however, worthwhile taking the time to test your web application using an application such as OpenSTA or one of the commercial web testing offerings.
Recently I subjected one of my own websites to performance testing, and while the application performed well, I discovered that the default setting for the ADODB.Connection's timeout was quite low. Increasing the timeout time ensured fewer users would ever see the timeout message. Whether they would stay around to wait for the page to load is another matter entirely!
While it is possible to write a quick Visual Basic application or script to repeatedly request the same URL via HTTP, it is advisable to test using an application that can perform real-world testing of your web application, such as performing searches on search facilities, logging in, submitting forms and other functionality.
Do not forget that it is very inadvisable to subject your live system to performance testing!Part 1 | Part 2 | Part 3 | Part 4 | Part 5