by Neil Smithline
Even with security provided by firewalls, application servers, and hardware security modules, a secure Web site still requires careful design and programming. Direct proof of the difficulties of writing secure applications can be found in the articles about Web site break-ins that fill newspapers. Some of the sites most focused on security have suffered from successful attacks. This article presents some suggestions for preventing the next break-in on your Web site.
This article discusses several common programming flaws that can lead to insecure Web sites, including password vulnerabilities, cross-site scripting vulnerabilities, insecure storage vulnerabilities, and denial-of-service vulnerabilities. For each vulnerability we will provide a summary, an example of typical attacks, an account of real-life attacks, and prevention strategies.
This article is intended for developers or architects who are interested in writing secure Web applications.
Despite the ever-increasing concern about security vulnerabilities, site break-ins continue to occur. According to the CSO Magazine/U.S. Secret Service/CERT Coordination Center E-Crime Watch Survey, 70 percent of organizations reported break-ins during 2003 (the last year for which data is available). CERT further reports that an estimated 137,529 separate break-ins occurred in that year. This so-called "cybercrime" cost the UK alone $461 billion in 2004.
J2EE provides security mechanisms for Web applications. Using the available declarative security of J2EE is the first step in creating a secure Web site. Through J2EE deployment descriptors, you can specify access control for servlets, only allowing users of specific roles access to a specific Web page or set of pages. When access control is used, the authentication mechanism must also be specified. This is one of BASIC, CLIENT-CERT, FORM, and optionally DIGEST (not supported by BEA WebLogic Server).
BEA WebLogic Server extends the standard authentication mechanisms with identity assertion. For further information about these authentication mechanisms, see the documentation. Furthermore, J2EE allows you to specify data integrity constraints to force the use of SSL/TLS, thereby ensuring that communication is secure. J2EE also provides for identity propagation so that identity flows across EJB calls, for example. Unfortunately, unless other attack remediation is used, even those applications that correctly use these J2EE security features are still open to successful attacks.
Before going into detail about various Web exploits, it's worth investigating just who engages in this behavior. Attackers come with a wide variety of skill levels ranging from brilliant engineers to "script kiddies" who run tools written by other people without any real awareness of what they are doing or how they work. Besides varying in skill, they have differing motivations. Many attackers break into sites because they think it is cool or they are looking to gain fame and status among fellow attackers. Others do it because they are angry with a site's management team, while still others attack sites for profit. The most sophisticated attackers are bright, highly motivated, in communication with other attackers, and have a lot of time to spend on an attack.
These sophisticated attackers begin to attack a site through a process of exploration. They then try to identify the hardware and software that is used, the versions that are in use, and the patch levels that are in place. They augment this with trying to identify the network layout, IP addresses, and other network information. Basically, they try to recreate an IT diagram of the Web site. As their explorations reveal information they try to find known vulnerabilities that can be exploited on the target system. (Many sites contain lists of known vulnerabilities including ones sponsored by product vendors such as BEA's advisory notifications as well as sites unaffiliated with vendor products such as US-CERT.) Throughout this process attackers might communicate with other attackers for information sharing and for social and status reasons.
Eventually an attacker accrues enough data to launch a successful attack. After an attack succeeds, the attacker might damage the site's content, steal confidential data, install a "back door" to allow future undetected access, and even write tools to allow other attackers to attack the site or similar sites.
Many vulnerabilities lead to successful Web site attacks. This section discusses some of these vulnerabilities and includes a brief summary of the attack for each vulnerability followed by typical attacks used to leverage the vulnerability. This section also looks at actual examples of the vulnerability that have been identified in Web sites as well as techniques for preventing the vulnerability.
To the best of my knowledge, all real-life examples of vulnerabilities presented here have actually occurred, have been reported to the vendor, and have been resolved. As a matter of responsible reporting, no unresolved vulnerabilities are referenced. Furthermore, the vulnerabilities used were chosen because they demonstrate a particular point; they are in no way a reflection of the companies' products.
Summary: Passwords often can be compromised simply by careless user behavior (for example, a user may write down a password in an unsafe location or choose a password that is easily guessed), or by unsafe password storage and transmission. Passwords can be compromised on the server, in transit, or on the client. Passwords also are often exposed in Web pages or email messages. Email is perhaps the most dangerous place to store passwords but is one of the most common means of communicating them. Even if you assume that the email is secure while it is in transit on the Internet, surely system administrators at your ISP or company have access to it once it is received. Furthermore, email is typically backed up offsite, providing easy access to people who work at the storage facility and even to the truck drivers who transport backup tapes.
Typical Attacks: Many password vulnerabilities can be exploited from the local machine. This includes the reading of clear-text passwords from on-disk or in-memory artifacts or from disk backups. Attacks that occur outside the server's environment include email snooping, browser memory snooping, and the most simple: watching passwords being typed as they are echoed onto the screen (for example, many sites type passwords as asterisks when you enter them but then have a security question whose answer is typed in clear-text and whose answer can be used to change the password).
Examples: The most common type of password vulnerabilities are the innumerable "phishing" attacks that jam our email inboxes. Phishing is when one Web site poses as another in order to gather username, password, and other confidential information. Phishing emails have subjects such as "Important account update required."
One specific example occurred in CA's eTrust EZ Antivirus program, version 7.x. In that program, a login form would get pre-filled with a username and password to a back-end system, allowing an attacker on the same machine to extract the password from the browser's memory. (Look at Secunia's site for details.)
Prevention: One of the best ways to avoid local server password vulnerabilities is to not store passwords on the server. One remedy is to hash the password and store the hash of the password although recent attacks on hashing algorithms make this a less secure approach than previously thought. When hashing is not possible because the passwords must be rendered in clear-text form (for example, for connecting to a remote machine), then encryption should be used.
You should avoid sending passwords by email whenever possible, but if this method is necessary, then you should use temporary passwords or passwords that must immediately be changed. While these techniques do not prevent a password from being stolen, they do decrease the window of time in which they can be stolen and can increase the chance of the theft being detected.
Many alternatives and extensions to passwords can be used. Some of these alternatives are still new (for example, biometrics such as retinal scans) while others are better known and understood. RSA SecurID is one example of a commonly used password extension. X.509 certificates frequently are used to replace passwords altogether. Another technique that is beginning to grow in usage is one-use passwords where users are given an ordered list of passwords and can only use each password once.
Pages: 1, 2