The OWASP Top Ten List
We’ll spend most of the rest of this book talking about web security vulnerabilities and principles, but just to whet your appetite for what’s to come, let’s start by getting familiar with the OWASP Top Ten List.
One of the most-respected authorities in the field of web application security is the organization OWASP, short for the Open Web Application Security Project. As its name implies, OWASP is an open-source project with the goal of improving web application security. (You can see a screenshot of the OWASP web site, www.owasp.org, in Figure 1-3.)
Figure 1-3 The OWASP web site www.owasp.org
OWASP is basically a loose coalition of individual contributors and sponsor companies who come together to contribute resources to the project. These resources include guidance documents to explain how to write more secure code, scanning tools to help you find vulnerabilities in your applications, and secure coding libraries you can use to prevent vulnerabilities from getting into your applications in the first place. But the best-known OWASP resource by far is its Top Ten List.
The OWASP Top Ten List of the Most Critical Web Application Security Risks is compiled from both objective and subjective data. OWASP sponsor organizations contribute objective data on the prevalence of different types of web application vulnerabilities: how many database attacks they’ve seen, how many browser attacks, and so on. OWASP-selected industry experts also contribute more subjective rankings of the severity or potential damage of these vulnerabilities.
As we mentioned earlier, web security risks change over time as new vulnerabilities are discovered (or invented). And it’s not all doom and gloom; new defenses are developed every year too. New versions of application frameworks, web servers, operating systems, and web browsers all often add defensive technology to prevent vulnerabilities or limit the impact of a successful attack.
Tip
Built-in browser defenses can be a great help, but don’t rely on them. It’s very unusual to be in a situation where you can guarantee that all your users are using the exact same browser. Certainly this won’t ever be the case if you have any public-facing web applications. And even if you’re only developing web sites for use inside an organizational intranet where you can mandate a specific browser, it’s likely that some users might configure their settings differently, inadvertently disabling the browser defenses. The bottom line here is that you should treat browser defenses as an unexpected bonus and not take them for granted. You are the one who needs to take responsibility for protecting your users. Don’t count on them to do it for you.
Since web application vulnerability risks change, becoming comparatively more or less critical over time, the OWASP Top Ten List is periodically updated to reflect these changes. The first version of the list was created in 2004, then updated in 2007 and again in 2010 (its most recent version as of this writing). The list is ranked from most risk to least risk, so the #1 issue (injection) is considered to be a bigger problem than the #2 issue (cross-site scripting), which is a bigger problem than broken authentication and session management, and so on.
As of 2010, the current version of the OWASP Top Ten List is as described in the following sections.
#1. Injection
One of an attacker’s primary goals is to find a way to run his own code on your web server. If he can do this, he may be able to read valuable confidential data stored in your databases or conscript it into a remote-controllable botnet of “zombie” machines. To accomplish this through a network-level attack, he might have to find a way to sneak an executable binary file through your firewall and run it. But with an application-level attack, he can accomplish his goal through much more subtle means.
A typical web application will pass user input to several other server-side applications for processing. For example, a search engine application will take the search text entered by the user, create a database query term from that text, and send that query to the database. However, unless you take special precautions to prevent it, an attacker may be able to input code that the application will then execute. In the example of the search engine, the attacker may enter database commands as his search text. The application then builds a query term from this text that includes the attacker’s commands, and sends it to the database where it’s executed. You can see a diagram of this attack in action in Figure 1-4.
Figure 1-4 An injection attack against an application’s SQL database
This particular attack is called SQL injection and is the most widespread form of injection attack, but there are many others. We see injection vulnerabilities in XML parsing code (XPath/XQuery injection), LDAP lookups (LDAP injection), and in an especially dangerous case where user input is passed directly as a command-line parameter to an operating system shell (command injection).
#2. Cross-Site Scripting (XSS)
Cross-site scripting vulnerabilities are actually a specific type of injection vulnerability in which the attacker injects his own script code (such as JavaScript) or HTML into a vulnerable web page. At first glance, this may not seem like an incredibly critical vulnerability, but attackers have used cross-site scripting holes to steal victims’ login passwords, set up phishing sites, and even to create self-replicating worms that spread throughout the target web site.
Cross-site scripting is dangerous not just because it can have such high-impact effects, but also because it’s the most pervasive web application vulnerability. You’re potentially creating cross-site scripting vulnerabilities whenever you accept input from a user and then display that input back to them—and this happens all the time. Think about blogs that let users write their own comments and replies to posts. Or collaborative wikis, which let the users themselves create the site content. Or even something as seemingly innocent as a search feature: if you display the user’s search term back to them (for example, “Your search for ‘pandas’ found 2498 results”), you could be opening the door to cross-site scripting attacks.
#3. Broken Authentication and Session Management
Authentication and authorization are usually considered to be network-level defenses, but web applications add some unique new possibilities for attackers. When you use a web application, your browser communicates with the application web server by sending and receiving messages using the Hypertext Transfer Protocol (HTTP). HTTP is a stateless protocol, which means that the server does not “remember” who you are between requests. It treats every message you send to it as being completely independent and disconnected from every other message you send to it. But web applications almost always need to associate incoming messages with a particular user. Since the underlying HTTP protocol doesn’t keep state, web applications are forced to implement their own state keeping methods.
Usually, the way they do this is to generate a unique token (a session identifier) for each user, associate that user’s state data with the token value, and then send the token back to the user. Then, whenever the user makes a subsequent request to the web application, he includes his session identifier token along with the request. When the application gets this request, it sees that the request includes an identifier token and pulls the corresponding state data for that token into memory.
There’s nothing inherently insecure with this design, but problems do come about because of insecure ways of implementing this design. For example, instead of using cryptographically strong random numbers for session identifiers, an application might be programmed to use incrementing integers. If you and I started sessions right after each other, my token value would be 1337 and yours would be 1338. It would be trivial for an attacker to alter his identifier token to different valid values and just walk through the list of everyone’s sessions.
Another example of a poor state management implementation is when the application returns the session token as part of the page URL, like www.site.cxx/page?sessionid=12345. It’s easy for a user to accidentally reveal this token. If a user copies and pastes the page URL from her browser and posts it on a blog, not only is she posting a link to the page she was looking at but she’s also posting her personal token, and now anyone who follows the link can impersonate her session.
#4. Insecure Direct Object References
There’s usually no good reason for a web application to reveal any internal resource names such as data file names. When an attacker sees a web application displaying internal references in its URL, like the “datafile” parameter in the URL http://www.myapp.cxx/page?datafile=12345.txt, he’ll certainly take the opportunity to change that parameter and see what other internal data he can get access to. He might set up an automated crawler to find all the datafiles in the system, from “1.txt” through “99999999.txt”. Or he might get even sneakier and try to break out of the application’s data directory entirely, by entering a datafile parameter like “../../../passwords.txt”.
Note
Throughout this book, you’ll see us use example URLs with a top-level domain of “.cxx”, like “http://www.myapp.cxx”. We do this because—as of this writing—there is no such real top-level domain “.cxx”, so there’s no chance that the example site actually exists. We don’t want to accidentally name a real web site when we’re talking about security vulnerabilities!
#5. Cross-Site Request Forgery
Cross-site request forgery (CSRF) attacks are another type of attack that takes advantage of the disconnected, stateless nature of HTTP. A web browser will automatically send any cookies it’s holding for a web site back to that web site every time it makes a request there. This includes any active session identification or authentication token cookies it has for that site too.
By sending you a specially crafted e-mail message or by luring you to a malicious web site, it’s very easy for an attacker to trick your browser into sending requests to any site on the Internet. The site receives the request, sees that the request includes your current session token, and assumes that you really did mean to send it.
The worst part about cross-site request forgery is that every site on the Internet that relies on cookies to identify its users—and there are millions of these sites—is vulnerable to this attack by default. You’ll need to use additional measures beyond just session identification cookies to properly validate that incoming requests are legitimate and not forgeries.
#6. Security Misconfiguration
You can code your application with every security best practice there is, crossing every “t” and dotting every “i”, but you can still end up with vulnerabilities if that application isn’t properly configured. You’ll often see these kinds of configuration vulnerabilities when development settings are accidentally carried over into production environments.
Web applications in particular are designed to be easy to deploy. Sometimes deployment is as simple as copying the files from the developer’s machine to the production server. However, developers usually set their configuration settings to give them as much debugging information as possible, to make it easier for them to fix bugs. If a developer accidentally deploys his configuration settings files onto the server, then that whole treasure trove of internal data may now be visible to potential attackers. This may not be a vulnerability in and of itself, but it can make it much easier for the attacker to exploit any other vulnerabilities he may find on the system.
#7. Insecure Cryptographic Storage
Sensitive data like passwords should never be stored unencrypted in plaintext on the server. In fact, it’s rarely necessary for passwords to be stored at all. Whenever you can, it’s better to store a one-way cryptographic hash of a user’s password rather than the password itself.
For example, instead of storing my password “CarrotCake143”, a web application could just store the Secure Hash Algorithm (SHA-1) digest value of “CarrotCake143”, which is a 40-character-long string of hexadecimal characters starting with “2d9b0”. When I go to log in to this web application and give it my username and password, it computes a new SHA-1 hash from the password that I give it. If the new hash matches the old hash, it figures that I knew the correct password and it lets me in. If the hashes don’t match, then I didn’t know the password, and it doesn’t let me in.
The benefit of this approach is that hash functions only work in one direction: it’s easy to compute the hash of a string, but it’s impossible to recompute the original string from the hash. Even if an attacker somehow manages to obtain the list of password hashes, he’ll still have to take a brute-force approach to testing for an original value that matches my “2d9b0…” SHA-1 hash. On the other hand, if the application stores my password in plaintext and an attacker manages to get ahold of it in that unprotected form, then he’s already won—and this is just one example of one misuse of one particular form of cryptography.
For an even better way to secure password hashes, you should add a random value (or “salt”) to the plaintext password before computing its hash value. This approach has multiple benefits. First, in case the hash value is ever leaked, it makes an attacker’s job of reverse-engineering the original password text from a pre-computed lookup table (or “rainbow table”) much more difficult. (In Figure 1-5, you can see a screenshot of a web site offering rainbow tables for download, which can be used to crack Windows XP user accounts.)
Figure 1-5 A web site offering Windows XP password rainbow tables for download
And second, without salt values, whenever two users have the same password, they’ll have the same password hash as well. Cracking just one user’s password from a leak of the hash list could end up revealing account information for potentially hundreds or thousands of other users as well.
#8. Failure to Restrict URL Access
One way that web applications sometimes keep unauthorized users out of certain pages on the site is to selectively hide or display the links to those pages. For example, if you’re the administrator for www.site.cxx, when you log in to the web site’s home page, you might see a link for “Administration” that takes you to admin.site.cxx. But if I log in to www.site.cxx, I won’t see that link since I’m not an authorized administrator there.
This design is fine as long as there’s some other kind of authorization mechanism in place to prevent me from accessing the administration site. If the only thing keeping me out is the fact that I’m not supposed to know the site is there, that’s not sufficient protection. If someone on the inside accidentally reveals the secret site, or if I just happen to guess it, then I’ll be able to just get straight in.
#9. Insufficient Transport Layer Protection
Using Hypertext Transfer Protocol Secure (HTTPS) for your web site gives you many security benefits that regular vanilla HTTP does not. HTTPS uses either the Secure Sockets Layer (SSL) protocol or, better yet, the Transport Layer Security (TLS) protocol, which provides cryptographic defenses against eavesdropping attackers or “men-in-the-middle.” SSL/TLS encrypts messages sent between the client and the web server, preventing eavesdroppers from reading the contents of those messages. But just preventing someone from reading your private messages isn’t enough—you also need to make sure that nobody changes or tampers with the message data as well—so SSL/TLS also uses message authentication codes (MACs) to ensure that the messages haven’t been modified in transit.
Finally, you need to know that the server you’re sending a message to is actually the server you want. Otherwise, an attacker could still intercept your messages, claim to be that server, and get you to send “secure” messages straight to him. SSL/TLS can prevent this scenario as well, by supporting authentication of the server (and optionally the client) through the use of verified, trusted digital certificates.
Without these protections, secure communications across the Internet would basically be impossible. You’d never send your credit card number to a web site, since you’d never know who else might be listening in on the conversation.
Unfortunately, because HTTPS is slower than standard HTTP (and therefore more expensive since you need more servers to serve the same number of users), many web applications don’t use HTTPS as thoroughly as they should. A classic example of this is when a web site only uses HTTPS to protect its login page. Now, protecting the login page is critical: Otherwise, an attacker could intercept the user’s unencrypted password. But it’s not enough just to protect that one message.
Assuming the user logs in successfully, the web site will return an authentication token to the user, usually in the form of a cookie. (Remember, HTTP is stateless.) If all of the subsequent pages that the user visits after he’s authenticated are not also served over HTTPS, an attacker could read the authentication token out of the message and then start using it for himself, impersonating the legitimate user.
While getting transport layer security right is a critical part of your application’s security, it should be evident by now that it’s not the only part of your application’s security. As with firewalls, far too many people tend to put far too much trust in the little HTTPS lock icon in their browser. Take SQL injection, for example: if your site is vulnerable to a SQL injection attack, all that you’ll get from using HTTPS is to create a secure channel that an attacker can use to exploit you.
#10. Unvalidated Redirects and Forwards
With web applications, it’s often the most simple and seemingly innocent functions of the application that lead to surprisingly damaging vulnerabilities. This is certainly the case with OWASP #10, Unvalidated Redirects and Forwards (usually just referred to as open redirect vulnerabilities).
Let’s say that you open your browser and browse to the page www.site.cxx/myaccount. This page is only accessible to authenticated users, so the application first redirects you to a login page, www.site.cxx/login. But once you’ve logged in, the site wants to send you to the myaccount page that you originally tried to go to. So when it redirects you to the login page, it keeps that original page you asked for as a parameter in the URL, like www.site.cxx/login?page=myaccount. After you successfully pass the login challenge, the application reads the parameter from the URL and redirects you there.
Again, it sounds very simple and innocent. But suppose an attacker were to send you a link to www.site.cxx/login?page=www.evilsite.cxx? You might follow the link and log in without noticing where the page was redirecting you to. And if the site www.evilsite.cxx was set up as a phishing site to impersonate the real www.site.cxx, you might keep using evilsite without realizing that you’re now getting phished.
Wrapping Up the OWASP Top Ten
You shouldn’t worry if you’re unfamiliar with some of the vulnerabilities in the Top Ten list or even all of them. We’ll cover all of these vulnerabilities and others in detail over the course of this book, starting with the very basic principles of the attack: Which targets is the attacker trying to compromise? What does he want to accomplish? What am I doing that allows him to do this? And most importantly: What can I do to stop him?
And again, remember that each of these vulnerabilities is just a symptom of a larger, more general security issue. Our real goal is to educate you on these larger principles. We don’t just want to “give you a fish” and tell you about the OWASP Top Ten, we want to “teach you to fish” so that if OWASP expands their list next year to be a Top 20 or Top 100, you’ll already have your applications covered.