Web-based applications and the technology that enables them are fantastic, but they’re bringing a new set of security considerations and challenges along with. This is destined to become a bigger and bigger issue as Web 2.0 applications gain traction, and particularly as they move into the enterprise. 
This list represents an attempt to compile those considerations and the proper way to handle them. This is by no means a comprehensive list, but rather is meant to be a starting point for entrepreneurs or individuals curious about the security of a specific application.
I realize that not all companies will be able to comply with all of the requirements, especially in the back-end section. However, keep in mind that these requirements all need to be addressed to comply with the Sarbanes-Oxley Act (SoX). If a company chooses not to take them into consideration they’re most likely going to be cutting all publicly traded companies (and the companies that do business with them) out of their potential customer base. On a side note, I hope this checklist will eat a chunk out of the SoX auditing extortion racket. Back when I had to go through making a company SoX-compliant, I was never able to find anything like this. Because there’s nothing in the Act itself about IT, a small cottage industry has sprung up around telling companies what they need to do to become compliant and then auditing them so that their partners know that they’re "SoX Cerified". Well, if you meet the bullets on this checklist you’re most likely going to pass. I had to figure these out the hard way, that is, by paying consultants boku bucks to tell me what they were 
Sensitive User Information
The crux of this list and SoX is protecting "sensitive user information". Here’s a basic list of what constitutes that vague term (I probably left some out so please leave feedback if you think of something I missed):
- Account number and identifiers
- Customer numbers
- User names
- Credit card or bank information of any kind
- Passwords
- Private messages and blog posts
- Wage information
- Social security and driver’s license numbers
- Birthdates
Front-End Security
The first list applies to the application front end, with special consideration given to AJAX and Web services calls:
- The application should use Digest authentication or SSL when accepting a user’s password for authentication.
- User passwords should be stored as an MD5 hash of the password in the database rather than as plain text.
- No sensitive account stored by the application should ever be rendered to the client. This includes database logins, email logins, third-party site logins, etc.
- User sessions should not be identified using cookies or IP addresses, both of which can be easily compromised.
- No sensitive information should be stored in cookies.
- Strong passwords (more than 8 characters, mixed alphanumeric and special characters, mixed upper- and lower-case) should be enforced if users select their own passwords.
- HTTP POST requests should be used instead of GET requests whenever possible. This isn’t more secure per se, but it raises the bar for potential hackers and makes it more difficult to crack your system.
- GET and POST requests should not be vulnerable to SQL injection attacks. All forms should check for special characters such as single or double quotes before sending the information to the database. Preferably, stored procedures should be used for all database access since they are not vulnerable to SQL injection attacks.
- All input validation should be done on the server, even if it was already done on the client. Doing this will avoid the possibility of using Javascript injection attacks.
- If sensitive user information is sent or received from Web services: The WS-Security SOAP header or SSL should be used.
- If sensitive user information is sent or received using XmlHttpRequest (AJAX calls): The entire page utilizing XmlHttpRequest needs to be secured using SSL (which will secure the XmlHttpRequest calls from that page using SSL as well). SSL is currently the only 100% secure way of making XmlHttpRequest calls, all other methods are vulnerable to man in the middle attacks.
Back-End Security
This list applies primarily to the internal database and network:
- The database administrator password should not be used for application access. If possible it should be renamed from the default name (sa, for example), and only known by somebody outside of the IT department.
- If the database contains sensitive customer information, the number of people who know the application database login or have unrestricted access to the database should be strictly limited. Backups should be encrypted and stored off-site in a secured location.
- Anyone who has access to the production database should be required to change their password at least every 90 days.
- If you must store credit card information, it should be encrypted and preferably wiped out after processing is completed.
- Change your network Administrator account name (so that it’s not "Administrator").
- Domain administrator accounts should rarely if ever be given out, and the list of people with that access should be documented and readily available.
- Security violations (such as a user entering the wrong password three times in a row) should be logged to a secure location and reviewed by the company Security Officer on a regular basis.
- The physical servers that hold sensitive customer information need to be secured and protected as well. Typically this is taken care of in a hosted environment, but if you’re hosting your application from your basement then you’d better make sure that you have the basement locked and you make the water heater repair man sign in and out.
Perimeter (Network) Security
Here are some requirements that are just good practices for building secure Web-based applications, particularly when they’re hosted on the Internet:
- The firewall should only allow ports 80 and 443 (HTTP and SSL) except when other applications such as BitTorrent or FTP need to be used.
- The Web servers should be on a separate network, separated from the database and other internal servers by a firewall which only allows the database application port to be used.
- The default database application port should be changed if possible.
Hope this helps everyone out there, please help me flesh this out if I missed something.
