An Introduction to Secure Web Practice

About This Document

Since the early years of the Web, the process of designing and building a Web site has changed. The availability of pre-packaged software for many common tasks - content management, blogging, forum systems and so forth - has improved. Many third party services are now available. Web frameworks of varying complexity are available in almost any common programming language. Templating systems are commonplace - sites making use of advanced features such as AJAX functionality will often make use of a framework to simplify design. The fact that the design and complexity of the tools has increased does not mean that security is now out of the hands of the site developer. Some frameworks explicitly handle certain security issues, but it is good practice to work with security in mind. This document provides guidelines on some of these issues.

Platform Security Issues

Every component in your web site, including the Web server and underlying frameworks or platforms, may suffer from security flaws. As they are discovered, the developers behind that software package will issue advisories regarding security flaws, as well as software patches, upgrades or workarounds. Ongoing maintenance of a web site involves keeping an eye out for advisories, perhaps on appropriate mailing lists or RSS newsfeeds, and prompt action when such issues are discovered. Remember to plan for this essential ongoing maintenance work in your budget. Note that using popular components is likely to help security - issues are discovered and fixed quickly.

User Authentication

In general, user authentication is a difficult piece of functionality to write from scratch. If your project parameters permit you to use an existing system, or to tie your authentication into an existing system such as PHP's sessioning, consider the option. Ideally, do not store user passwords in plain text, because of the possibility that the passwords could be retrieved and used to compromise users' accounts elsewhere - in practice, users often maintain one password for several systems or sites. Make use of a hashing function, such as an md5sum s2], and store the result instead.

User Input

Many security flaws result from the assumption that user input is trustworthy, and that it contains what the programmer intended the user to input. Others result from the use of client-side code, such as JavaScript, to check the user's input before it is posted. The client's browser is not a secure environment - the user can alter browser behaviour. Even if client-side code is used, the check must be run again on the server.Examples of Common Vulnerabilities

• Remote execution of code - a user, aware that their user input will be run as part of a shell or system command, tries to append additional code to their input so that a different command is run, or so that the command returns different information.
• Denial of Service - a malicious user inputs data that causes your Web application to stop responding correctly.
• Cross-site scripting - displaying unchecked user data provides malicious users with a method of injecting information into your web pages, providing an opportunity to confuse or mislead your users and perhaps gain private information or compromise user accounts.
• SQL injection - many websites make use of a backend database. If unsafe user input is sent to the database - input to which is appended additional SQL commands - the malicious user can design commands to compromise other users' accounts, alter account information or delete information.

Conclusions

Make security a priority at all stages in the design and build process. Plan for maintenance in your budget. When specifying an application, page or component that takes user input, write down a list of possible vulnerabilities and ensure that you have addressed these during the design and build phases. Test your Web applications - provide unexpected input, and see if you can find any way to break them. Provide custom error pages - diagnostic information on errors can be useful for malicious users. Speak to a security expert if possible, and ensure that you have taken reasonable precautions. A secure application can only be ensured by an ongoing commitment to that aim.

References

1. Common Security Vulnerabilities in eCommerce Applications, K. K. Mookhey,
   <http://www.securityfocus.com/infocus/1775>
2. 2. Consider MD5 checksums for application passwords, Scott Stephens,
   <http://www.builderau.com.au/architect/soa/Consider_MD5_checksums_for_application_passwords/0,39024564,39130325,00.htm>