My Portal Project

Hat-tip to Jim Anderton for his review of “How to Break Web Software“, which finally forced me to get off my butt and start a developers checklist for browser application security. The list is in draft mode, and I will soon circulate it amongst my team and peers at work. Most of these are .NET centric, but most are universal. Alot of these itesm fall under the header of “you cannot trust the client, period”, but I wanted to provide some specifics on why. As usual, any comments or corrections are welcome.

1. Remember that Try-Catch is your friend. Never let the language environment show your errors.

2. In the web.config, the debug setting in the compilation section should always be set to false in production. Errors that get returned to the user should be generic with more specific error information being written to a log file on the server. In fact, when moving code into production, do not copy the web.config file, but maintain two seperate versions.

3. No sample applications should ever be installed in the production environment regardless of their origin. Sample applications should be tested/hacked before ever seeing the light of day.

4. If you are using forms based authentication, there should always be a max-attempts and lockout functions. If your information is very sensitive (like credit card information), then your application should also track the IP address of each browser session, and lockout users when the IP address changes. This will help prevent session hijacking, but it can produce false positives if a company uses certain Network Address Translation configurations.

5. NO security through obscurity.

6. If application displays personal or member information, make sure that you provide a Sign-out/Log-out link, along with an auto-logout function. Local Javascripts can fire after a predetermined amount of time, and clear the users session, and return to the login screen. Also make sure that these pages cannot be cached. Do not rely on the META tags to do this, but use the VB.NET code at the bottom of the page_load event:

Response.CacheControl = “no-cache”
Response.AddHeader “Pragma”, “no-cache”
Response.Expires = -1

7. No comments in uncompiled production code (HTML/Javascript/VBScript/etc..). Comment information can be used by malicious users to determine programmers names, and other social engineering exploits.

8. Client side javascript validation is a courtesy, nothing more. Data must always be validated on the server. Usage of HTML settings like MAXLENGTH on a field, and drop-down boxes can easily be bypassed with browser proxy programs like Paros, and PageSpy. In addition, local DOM scripting tools like GreaseMonkey, and FireBug can allow a user to rewrite a page locally before posting back to the server.

9. When validating input on the server, it is always a better practice to validate for what SHOULD be there instead of looking for what should NOT be there. For example, if a user is entering a number, you should not bother looking for text, but simply ensure that each character is a number (vb.net Integer.TryParse).

10. Parameters that get posted to the server also contain header information that shows the byte-length of all parameters. If there is a difference between the size of data you received, and this parameters value, you may have someone trying to game your application.

11. If page-sequencing is critical, do not rely on client side stored values to determine the sequence of pages. Use of server SESSION objects is preferred.

12. In fact, do not rely on ANY client stored data that is critical to the flow/processing of your application. Cookie data, hidden field, URL parameters are all changed too easily to be relied upon.

13. NEVER insert user provided data directly into a SQL statement. See this article on SQL injection.

14. For database driven application, all data access should be done through stored procedures. The credentials used for the application should NOT have select/insert/update access to ANY tables. This forces stronger typing of data sent to the database, lowering the risk of SQL injection attacks.

15…….. to be continued

This entry was posted on Thursday, August 24th, 2006 at 10:31 am and is filed under Web Development. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.