How to develop secure Web apps

by Mandy Andress

April 10, 2001 —

The best way to prevent Web application attacks is through education and vigilance. Developers should be educated on secure coding practices, and management should be educated on the risks involved in taking a system live before it has been thoroughly tested. Additionally, administrators and security professionals should constantly monitor vendor Web sites, security Web sites, and security mailing lists to ferret out potential vulnerabilities in the applications and servers used by their Web applications.

Secure coding is only one of many components needed to develop a secure Web application. Ideally, security should be discussed, planned for, and included in all phases of application development, and procedures should be established for ongoing monitoring and maintenance of the Web application. When this occurs, the end result will be a stable, secure Web application.

Developers take notice

* First and foremost, developers should learn never to trust incoming data. A heightened distrust of the end-user goes a long way toward developing a secure Web application; developers should trust only what they control. Because they cannot control the end-user, developers should view all data inputs as potentially hostile and should design controls in the application to validate end-user data inputs.

For example, never assume that anything sent to a client's browser is returned unchanged or that the data entered into a Web form is what it should be. Does a form field that asks for a customer's address really need to contain a "<" symbol? Such symbols usually indicate code to a hacker. Adding filters and input checks significantly reduces the risk of many types of Web application attacks.

* Developers should include all security measures in the application as they are coding it. Using an anonymous Web server account during development to save time even though each end-user will authenticate to the live application with a user name and password can cause problems. Bugs may arise in the authentication code, not to be discovered until a few days before, or even after, the application goes live. Finding bugs at the last minute means that the application launch will be delayed or that it will be launched with bugs. Neither choice is optimal; so include all of the application's elements throughout the development process.

Whenever possible, do not use administrator or superuser accounts to run the application. Although you may save yourself time dealing with access rights and permissions, running everything as root is asking for trouble. With a superuser account, the Web application user will have write access to all database tables. Modifying a few URLs with SQL code, a malicious user can easily wipe out the entire database. Following the security principle of "least privilege" is a must. Least privilege means giving a user the lowest level of permissions necessary for performing a certain task. The user can still enjoy the Web application, and the company can feel safe by knowing that malicious users cannot easily perform illegal operations because their access does not allow it.

* Using HTTP GET requests to send sensitive data from the client to the server introduces numerous security holes and should be avoided. GET requests are logged by the Web server in clear text, allowing anyone who gains access to the log file the ability to read its contents. For example, a credit card nnumber sent to the server by a GET request will be rendered in the Web server logs as clear text. Using database encryption to protect credit card numbers is useless if all an attacker needs to do is gain access to the Web server logs. SSL (Secure Sockets Layer) does not prevent this issue, either. SSL encrypts the data only during transmission; the GET request will still be logged in clear text on the Web server. The request may also be stored in the customer's browser history file.

Instead, the HTTP POST command should be used to send data between the client and the Web server. The POST command uses the HTTP body to pass information, so the Web server does not log it. The information is still sent in clear text, however, so SSL should be used to prevent network-sniffing attacks.

* Java Server Pages (JSP) and Active Server Pages (ASP) are frequently used in Web application development and often contain hard-coded passwords for connection to directories, databases, and so on. Some developers believe this is OK because the server should process the code and display only the resulting Web page, but numerous vulnerabilities exist. One of the simplest exploits is the Internet Information Server (IIS) bug that shows the source code of an ASP when ::$DATA is appended to the end of a URL. For example, submitting www.site.com/page.asp::$DATA will display the page's source code and all the juicy secrets it contains.

* Developers should always be cognizant of HTML code comments and error messages that may leak information. An attacker can learn enough about the application's architecture to design a successful attack. For example, including a commented-out connection string that was once part of a server script may give an attacker valuable information.

Error messages also need to be looked at. Some error messages provide information regarding the physical path of the Web server that can then be used to launch an attack on the system. Other error messages provide information on the specific database or application servers being used. Overall, error messages do not pose any specific danger, but as with commented code, the information gleaned from them can be used to better understand the architecture of the application and fine-tune an attack.

* Cross-site scripting is a vulnerability that is difficult to defend. The current consensus is to use HTML encoding. When sent to the browser, encoded characters such as "<" and ">" will be displayed instead of executed as "& lt" and "& gt", respectively. To prevent the bulletin board attack described in "Web apps are Trojan horses for hackers," input data needs to be encoded. Some products provide tools for this. On IIS for example, the Server object has HTMLEncode that takes an input string and outputs the data in encoded format.

Postdevelopment tools and solutions

Although they help significantly, secure coding practices alone may not ensure the security of a Web application. Several tools and applications exist to help audit and secure Web applications.

If your Web application uses CGI scripts, you should scan it with Rain Forest Puppy's whisker.pl script. This Perl script scans a site for known CGI vulnerabilities. It is freely available at www.wiretrip.net/rfp.

Complete source code reviews are also critical. Although it may be too costly to hire a consultant for a full-blown review, several tools exist to help with the process in-house. NuMega (www.numega.com), L0pht (www.l0pht.com/slint.html), Cigital's ITS4 (www.cigital.com/its4), and Lclint (lclint.cs.virginia.edu) all provide source code review programs.

Several products specifically address Web application security -- and their number is growing rapidly. Sanctum's AppShield (see our review, "AppShield stops Web app hackers cold") protects Web sites from all the vulnerabilities discussed in this article. AppShield acts as a firewall for the Web application, allowing only approved data and requests to be passed to the application. Sanctum also offers AppScan, which can be used to test applications for vulnerabilities.

WebInspect from SPI Dynamics (www.spidynamics.com) scans Web pages, scripts, proprietary code, cookies, and other Web application components for vulnerabilities. WebDefend, which is similar to Sanctum's AppShield, provides real-time detection, alert, and response to Web application attacks.

A few other products on the market help protect Web applications from some Web attacks. Entercept and the open-source Saint Jude are intrusion-prevention applications that stop attacks at the OS level before they occur. These products can protect Web applications from buffer overflow attacks or cross-site scripting that try to invoke processes at the OS level. Additionally, SecureStack from SecureWave (www.securewave.com/products/securestack/secure_stack.html) provides buffer overflow protection for Windows NT and Windows 2000 servers.

Web application attacks, or Web perversion as Sanctum calls this phenomenon, are a rapidly growing threat. Education and vigilance are key to protecting the data and resources made accessible to end-users by a Web application. By implementing the steps outlined in this article, you are well on your way to alleviating Web application security issues.

InfoWorld