Chapter 1 Web Application Security In this chapter: OWASP Top 10..........................................................2 General Principles to Live By.............................................. 4 Summary............................................................... 7 The late 1990s was a time of increasing network and operating system based attacks. Nearly every company had buffer overflow problems. New exploits for Microsoft Windows NT, Windows 2000, and Internet Information Services (IIS) were released almost on a daily basis. Most of the big software companies learned their lessons from that time and realized that they must treat security as a regular and important product feature. This realization resulted in changed development processes and, often, in the creation of more robust and secure code. Microsoft is a prime example of a company that has managed to reduce the number of critical vulnerabilities in its software by implementing a development process that incorporates security features design and testing as integral parts; and also very important, these parts of the software design process are incorporated from the very beginning of the cycle. You can read about the Microsoft Security Development Lifecycle (SDL) and how it works at http://msdn.microsoft.com/ msdnmag/issues/05/11/sdl/default.aspx and in Michael Howard and Steve Lipner s latest book, The Security Development Lifecycle (Microsoft Press, 2006). These (good) changes in the software industry meant in turn that it became harder and harder to attack systems at the operating system level. Attackers started looking for more attractive targets. They moved a few layers up in the ISO model, and Web applications became the doomed new target for many reasons. First, Web applications are very easy to attack. HTTP, the underlying protocol, is very, very simple. It is text-based and stateless, which means that you don t need specialized tools to encode binary data a simple telnet client is enough to craft HTTP packets. The statelessness of the protocol implies that every roundtrip to a Web application contains all necessary data, which makes it easy for replays as well because often there is no need to set up first some kind of session to mount an attack. Another fact of life is that nearly all HTTP-based applications allow anonymous access even if only to show a login page. This page is already part of the actual application and can be used to attack the application code. Another typical characteristic of Web applications is that they are most often a gateway, or put differently, they are the last bastion between the Internet and internal resources such as databases. Again, this makes them very attractive targets. 1
2 Developing More-Secure Microsoft ASP.NET 2.0 Applications On the other hand, advances in Web application development environments make building complex, data-driven Web applications very easy. Bringing the desktop Windows Forms-based programming paradigm to the Web attracted a lot of companies and developers. Traditionally, security has not been given much focus in classic intranet-based applications, but the move to a completely different environment such as the Internet changed this situation completely. It meant that millions of developers with little or no security background and experience started writing applications that were suddenly available to every criminal on the Internet. This doesn t mean that the developers are bad programmers it is just that the threats have changed completely. Although the general guidelines for creating robust applications (such as input validation) haven t changed, more criminally motivated testers are out there trying to find flaws in code. In addition, some new types of attacks and vulnerabilities come with the technologies used in Web applications, such as HTML injection. As I wrote this book, I tried to focus not so much on the different technologies that Microsoft ASP.NET has to offer, but more on the typical problems and decisions a developer faces every day and how issues can be solved using ASP.NET. In the remainder of this chapter, I introduce you to the most common vulnerabilities and where in this book you can find in-depth coverage and solutions for the issues discussed. I also offer some general guidelines you should always take into account when you are making design decisions. You ll notice that at some point you will develop an intuitive feeling for what s OK security-wise and what s not. OWASP Top 10 The popularity of Web applications and their security problems have led to the development of a whole industry that has Web security as its center of focus but also to a whole ecosystem of open-sourced methodologies and white papers as well as attack and defense tools. In particular, one open source organization named the Open Source Web Application Security Project (OWASP) works constantly in the Web application security area and publishes an updated top 10 list of the most common security vulnerabilities. The following list discusses those top 10 vulnerabilities and in which chapter of this book each is covered (see http://www.owasp.org/index.php/owasp_top_ten_project): 1. Unvalidated input Information from Web requests is not validated before being used by a Web application. Attackers can use these flaws to attack back-end components through a Web application. Input validation is covered in Chapter 3, Input Validation. 2. Broken access control Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users accounts, view sensitive files,
Chapter 1 Web Application Security 3 or use unauthorized functions. Authorization in ASP.NET is covered in Chapter 5, Authentication and Authorization. 3. Broken authentication and session management Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users identities. Authentication in ASP.NET is covered in Chapter 5. 4. Cross-site scripting The Web application can be used as a mechanism to transport an attack to an end user s browser. A successful attack can disclose the end user s session token, attack the local machine, or spoof content to fool the user. Cross-site scripting and its mitigation techniques are covered in Chapter 3. 5. Buffer overflow In some languages, Web application components that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include Common Gateway Interface (CGI), libraries, drivers, and Web application server components. Fortunately, buffer overflows are very uncommon in ASP.NET, but technically they are input validation flaws; such problems are covered in Chapter 3. 6. Injection flaws Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system might execute those commands on behalf of the Web application. Injection flaws result from flaws in input validation, which is covered in Chapter 3. 7. Improper error handling Error conditions that occur during normal operation are not handled properly. If attackers can cause errors to occur that the Web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server. Error handling and logging techniques are covered in Chapter 7, Logging and Instrumentation. 8. Insecure storage Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proved difficult to code properly, frequently resulting in weak protection. Protecting data and cryptography are covered in Chapter 4, Storing Secrets. 9. Application denial of service Attackers can consume Web application resources to a point at which other legitimate users can no longer access or use the application. Attackers can also lock users out of
4 Developing More-Secure Microsoft ASP.NET 2.0 Applications users accounts or even cause the entire application to fail. This really affects everything you are doing in your application and is not specifically covered in any one chapter you have to read the whole book. 10. Insecure configuration management Having a strong server configuration standard is critical to a secure Web application. Servers have many configuration options that affect security and are not secure out of the box. Deployment and hardening of the server and ASP.NET are covered in Chapter 9, Deployment and Configuration. General Principles to Live By Besides solutions to specific problems, you should always have in the back of your head a number of general principles when designing and implementing your application. These principles are technology independent and apply to every part of your system. Security Is a Feature Security is a feature of your application just like performance or nice GUIs treat it as such. This implies that you design security features as part of your requirement analysis, which also means that you have to incorporate security and testing for security in your development life cycle. Note It strikes me that requirements documents usually don t address security. That s not because it is not a requirement but because today, security is implied. Nobody really likes to pay for security, but if something goes wrong, it s the developers fault. The hardest part of making security a feature of your application is discovering the potential security problems in your design and in which parts of your application you have the highest risk for vulnerabilities. Threat modeling is a great way to find both. After threat modeling, it becomes almost mechanical to implement the countermeasures. I highly recommend looking at Threat Modeling by Frank Swiderski and Window Snyder (Microsoft Press, 2004) and the second edition of Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, 2002). These books include tons of great information and details about the several threat-modeling techniques and approaches. Also, a very nice tool that can help you visualize access to your applications and generate use cases along with a list of possible attacks and countermeasures is the new Microsoft Threat Analysis and Modeling tool (http://msdn.microsoft.com/security/ securecode/threatmodeling/acetm/). Keep in mind that security and security testing take time and money usually less money than it takes to fix a vulnerability, however, which is a fact you should consider throughout project management. Also consider doing third-party penetration testing at several stages in the development life cycle. It is amazing how much you can discover during a black-box test.
Chapter 1 Web Application Security 5 Use Least Privilege Always design your applications so that they work correctly under normal (meaning, not elevated) user accounts. It is a very bad idea to run a Web application using high-privileged accounts. Web apps are direct targets of attacks, and if an attacker manages to take over the application, the attacker usually gains the same privileges as the process in which the application runs and this really shouldn t be Administrator or System. There are always situations in which parts of your application need elevated privileges, but usually you can factor those parts out and run them in a different process with a defined communication channel between the front end and the elevated code. This is much better than running the whole application with high privileges. (Appendix C has more information on that.) Prevention, Detection, and Reaction A secure system does not solely consist of countermeasures (that is, protection). You also need mechanisms in place to detect attacks as well as a strategy for reacting after an incident. Chapter 7 covers the details of how to implement such features. Layer Your Defenses Web applications are usually the last bastion between users (or attackers) and back-end resources such as the corporate database. Be aware of their responsibility for keeping back-end systems protected. A good example is input validation. ASP.NET provides some built-in services to filter out malicious input, but you should always do additional input validation and also enforce input restrictions in your database by using data types, length restriction, and so forth. There Is No Trusted Input Input is everything that is not known at application compile time. At run time, you will get input from various sources such as the user, databases, or configuration files. If your application relies on the correctness of that input to function correctly, you better make sure that unexpected input cannot bring down your application, regardless of the source of that input. Pay Attention to Failure Modes Developers usually focus on functionality. Attackers focus on error conditions. In your last project, what percentage of your error handlers and catch blocks were tested? Fifty percent or more or less? It is very hard to test every error condition thoroughly. Unit testing in combination with code coverage has proved to be a good way to automate testing and reduces the chances of forgetting an important test or condition. Also, try typical penetration
6 Developing More-Secure Microsoft ASP.NET 2.0 Applications testing tools (have a look at Chapter 10, Tools and Resources ) against your application; you ll be surprised at the kind of errors these tools trigger in your code. In every case, be very careful how much information about the error condition you give your users. Error messages should be very vague but you should always log a detailed version of them in some logging store. Beware of Application Denial of Services Denial of service (DoS) attacks traditionally are network-based. But you can also unintentionally build DoS-exploitable features in your own applications. Prime examples are automatic lockouts for failed logon attempts especially when you don t have an auto-unlock mechanism. Another example is storing a lot of data in ASP.NET session state for every anonymous connection that comes in. An attacker can easily create a lot of connections to your site (maybe even with spoofed IP addresses) until you run out of memory. Prefer Secure Defaults If you are building an application that will be installed by other people, try to use secure default settings. For example, it is better to force the installer to choose a password than it is to use a known default password. If your application contains optional parts, don t install them by default: they sometimes are not as thoroughly tested as the core functionality and are dead code on the server if not in use. Consider Microsoft Windows Server 2003 as an example. After installation, only the base services are installed and you have to select other installation packages specifically. This reduces attack surface. When you are writing code, always think defensively. Take the following two code examples: // Variation 1 if (ACCESS_DENIED = ValidateUser(username, password)) return false; else return true // Variation 2 if (ACCESS_ALLOWED = ValidateUser(username, password) return true; else return false; Can you spot the fundamental difference? Variation 1 checks only for access denied. If another return code such as DATABASE_ERROR would have been returned from ValidateUser, the user would still be allowed to log on even with invalid credentials. Variation 2 specifically checks for the one and only condition that means the credentials are valid. Variation 2 takes a negative outcome as the default, which is the more secure value.
Chapter 1 Web Application Security 7 Cryptography Doesn t Ensure Security One of the common myths in security is that cryptography ensures security. Whenever you hear or read the statement This is secure because it is encrypted, be very suspicious. Cryptography alone does not provide any security it must always be used in combination with a lot of other influencing factors. Obvious questions are as follows: Which algorithm is used? How are the keys generated? Are low-entropy passwords used as a source? How are passwords stored and transmitted? How often are passwords changed? Chapter 4 introduces you to cryptographic methods that can improve the security of your application but always keep in mind that cryptography is not the silver bullet. Firewalls Don t Ensure Security Summary Firewalls are devices that prohibit access to parts of your network that should not be accessible. Your applications exist only to be accessible to someone. So, why should a firewall help protect an application? Firewalls can reduce the attack surface of servers and networks, but usually they can t help with any application security related problems. Besides some HTTP/HTML specialties, no completely new types of attacks against Web applications have been invented. But just the fact that they exist means Web applications will be attacked. Moving an application from your intranet to the Internet automatically attracts people that will attempt to find flaws in your code. This is why we need to focus so much more on security in such applications. Always follow the general principles as outlined here and apply them to the technical information found in the rest of this book.