Building secure distributed Web applications is challenging. Your application is only as secure as its weakest link. With distributed applications, you have a lot of moving parts and making those parts work together in a secure fashion requires a working knowledge that spans products and technologies.
You already have a lot to consider; integrating various technologies, staying current with technology, and keeping a step ahead of the competition. If you don’t already know how to build secure applications, can you afford the time and effort to learn? More to the point, can you afford not to?
If you already know how to build secure applications, are you able to apply what you know when you build .NET Web applications? Are you able to apply your knowledge in today’s landscape of Web-based distributed applications, where Web services connect businesses to other business and business to customers and where applications offer various degrees of exposure; for example, to users on intranets, extranets, and the Internet?
Consider some of the fundamental characteristics of this connected landscape:
Web services use standards such as SOAP, Extensible Markup Language (XML), and Hypertext Transport Protocol (HTTP), but fundamentally they pass potentially sensitive information using plain text.
Internet business-to-consumer applications pass sensitive data over the Web.
Extranet business-to-business applications blur the lines of trust and allow applications to be called by other applications in partner companies.
Intranet applications are not without their risks considering the sensitive nature of payroll and Human Resource (HR) applications. Such applications are particularly vulnerable to rogue administrators and disgruntled employees.
Any successful application security strategy is built on the foundations of a solid approach to authentication and authorization together with secure communication to provide privacy and integrity for sensitive data. Before we go on, it is important to define these core concepts. In Chapter 3, we will show you how the various authentication and authorization mechanisms can be combined to provide a solid security design.
Authentication is the process of positively identifying the clients of your application; clients might include end-users, services, processes or computers. In security parlance, authenticated clients are referred to as principals.
Authentication occurs across the tiers of a distributed Web application. End users are initially authenticated by the Web application, typically by a username and password. Subsequently, as the end-user’s request is processed by middle tier application servers (if your architecture has one) and the database server, they perform authentication in order to validate and process the request.
In many applications, the downstream servers and components do not authenticate the end user. Instead they authenticate the entity that is the upstream application, having trusted that application to correctly authenticate and authorize the request prior to forwarding it.
The many authentication mechanisms that apply to ASP.NET application development are discussed further in Chapter 2.
The authorization process governs which resources and operations the authenticated client is allowed to access. Resources include files, databases, tables, rows and so on, together with system level resources such as registry keys and configuration data.
Primarily for reasons of scalability and manageability, many Web applications authorize access to operations exposed via methods, rather than directly to the underlying resources. That said it is still essential to secure system level resources using platform level security such as Windows ACLs and so on. Many of the most common application level authorization schemes use roles to categorize groups of users who share the same privileges within the application.
The various authorization options and gatekeepers available to ASP.NET application developers are discussed further in Chapter 2.
Many applications pass sensitive data among the application tiers, from database server to browser and vice-versa. Examples of sensitive data include bank account details, credit card numbers, payroll data and so on. Additionally, applications must secure logon credentials as they are passed across the network.
Secure communication provides the following two features:
Privacy. Privacy is concerned with ensuring that data remains private and confidential, and cannot be viewed by eavesdroppers who may be armed with network monitoring software. Privacy is usually provided by means of encryption.
Integrity. Secure communication channels must also ensure that data is protected from accidental or deliberate (malicious) modification while in transit. Integrity is usually provided by using Message Authentication Codes (MACs).
It’s important to apply secure communication techniques both inside and outside of the firewall as many unwanted forms of information disclosure and security breeches occur internally on corporate networks.
Secure communication and the various approaches available are discussed further in Chapter 4.
ASP.NET Web applications are developed using many different technologies and products. Various approaches to authentication, authorization and secure communication are required throughout your application’s multiple tiers to ensure a defense in depth security strategy.
Figure 1 on the next page summarizes the various technologies together with the primary authentication and authorization options provided by each one.
There are a number of overarching principles that apply to the guidance presented in later chapters. You should learn these principles and apply them to your application designs:
Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.
The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges (using the ASPNET account). This change was implemented for the initial release of the .NET Framework. During beta releases, ASP.NET ran as SYSTEM, an inherently less secure setting.
Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, script injection, and buffer overflow.
Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform features or proven techniques for securing your data.
Check at the gate. You don’t always need to flow a user’s security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.
If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller’s security context all the way through to your application’s data tier.
Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.
Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.
Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; in other words, don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
If you don’t use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn’t use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.