Creating secure web applications

A webmaster is mostly affected by common issues and problems that internet criminals target. From the very minute that a web server is installed, a “window” (of opportunity) into a local network is opened. Anyone, anywhere with online access has the ability to “peer through” this window. Whilst most internet users are content with what they’re presented with and aren’t likely to “nose around” and peek at things that were never really intended for public consumption, many other individuals are “free” to figure out ways to snoop. This sort of behavior can be likened to not being able to “look without touching”. These individuals will attempt to force their way inside this opened window and cause programming or structural damage by, for instance inserting a “bug”.

Surfing the web may, to the general, innocent internet user, be viewed as a safe and anonymous environment. The simple truth is that the internet isn’t quite all that safe and anonymous at all. In a sense the internet “has eyes” everywhere. Web browsers can be easily exposed to viruses and malicious software, causing a user’s personal system to experience malfunctions and problems. Web browsers also leave an electronic “footprint” whenever websites are visited. This footprint leaves a record of the user’s web surfing history, which creates an opportunity for internet criminals to create a profile of individuals’ tastes and habits, and potentially cause disruptions and problems. Personal detail confidentiality is one area where hackers can breach security vulnerabilities and allow data to be transmitted across the World Wide Web.

Some Common Security issues of web applications

1. Validation of input and output data All data used by the website (from users, other servers, other websites and internal systems) must be validated for type (e.g. numeric, date, string), length (e.g. 200 characters maximum, or a positive integer) and syntax (e.g. product codes begin with 2 letters and are followed by 5 digits) and business rules (e.g. televisions can only cost between £100 and £2000, an order can contain at most 20 items, daily credit limit must not be exceeded). All data written as output (displayed) needs to be safe to view in a browser, email client or other software and the integrity of any data that is returned must be checked. Utilizing Asynchronous JavaScript and XML (AJAX) or Adobe Flex increase complexity and the possible attack vectors.

2. Direct data access (and theft) If data exists, it can potentially be viewed or extracted. Avoid storing data that you do not need on the website and its database(s) – for example some data relating to payment cards should never be stored. Poorly developed systems may allow access to data through SQL injection. Compromises, insufficient input and output data validation (see No 1 above) or poor system security.

One of the most common attack vectors with the most devastating results is SQL injection.  SQL injection occurs when a malicious user injects code into your website to modify, steal or even erase information stored in your database.  SQL injection is easily avoidable but tends to be overlooked or untested, especially in older websites. There are several proven methods employed to prevent this which we will always employ, but the most basic rule is to trust no data received from any user and properly validate all input.

Consider this query:

"SELECT * FROM table WHERE column = '" + parameter + "';"

If an attacker changed the URL parameter to pass in ' or '1'='1 this will cause the query to look like this:

"SELECT * FROM table WHERE column = '' OR '1'='1';"

Since '1' is equal to '1' this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed.

3.  Data poisoning if user’s can amend or delete data inappropriately and this is then used to update your internal systems, business information is being lost. This can be hard to detect and it is important that the business rules are examined and enforced to validate data changes to ensure poisoning is not occurring. If poisoning is not detected until well after it has occurred, it may be impossible to recover the original data.

4. Malicious file execution Uploaded files or other data feeds may not be what they seem. Never allow user-supplied input to be used in any file name or path (e.g. URLs or file system references). Uploaded files may also contain a malicious payload so should not be stored in web accessible locations.This can occur anywhere on your website where you allow users to upload files.  If they are successful in uploading a malicious file they will be able to gain full control of your website and most likely full access to your database. It is important to validate the firstly the file name and then the true nature of the file before storing it on your website.  For example it is fairly easy to disguise a malicious payload as an image file/word document, upload it to your website and execute it later.

5. Authentication and session management Websites rely on identifying users to provide access permissions to data and functions. If authentication (verification of identity, registration and logging in), authorization (granting access rights) and session management (keeping track of the identity of a logged in user while they browse a website) can be circumvented or altered, a user could access resources they are not allowed to. Beware especially of how password reminders, remember-me, change password, log out and updating account details are handled, how session tokens are used and always have login forms on dedicated and encrypted (SSL) pages.

6. System architecture and configuration the information system architecture model should address the sensitivity of data identified during the requirements and specification phase of a website project. This may entail having separate web, application and database servers or involve clustering, load balancing or virtualization. Additional security issues can be created through the way the live environment is configured. Sufficient and safe logging, monitoring and alerting facilities need to be built in to allow audit.

7. Phishing, where users are conned into believing some other entity is or belongs to your own organization (email messages and websites are the most common combination), is best tackled through user education but the way the website is designed, its architecture and how it communicates with users can reduce the risk.

8. Denial of service Whilst malicious users might try to swamp the web server with a vast number of requests or actions that degrade its performance (filling up logs, uploading large files, undertaking tasks that require a lot of memory repeatedly) denial of service attacks include locking out valid user accounts or be caused by coding problems (e.g. memory leaks, resources not being released).

9. System information leakage Web servers, errors, staff, partner organizations, search engines and rubbish can all be the source of important information about your website – its technologies, business logic and security methods. An attacker can use such information to their advantage so it is important to avoid system information leakage as far as possible.

10. Error handling Exceptions such as user data validation messages, missing pages and server errors should be handled by the code so that a custom page is displayed that does not provide any system information to the user (see No 9 above). Logging and alerting of unusual conditions should be enabled and these should allow subsequent audit. For example if you have a login form on your website you should think about the language you use to communicate failure when attempting logins. You should use generic messages like “Incorrect username or password” as not to specify when a user got half of the query right. If an attacker tries a brute force attack to get a username and password and the error message gives away when one of the fields are correct then the attacker knows he has one of the fields and can concentrate on the other field.

11.Cross Site Scripting (XSS)

According to Security firm Semantic, XSS accounted for 80% in website vulnerabilities in 2007.  XSS is a method employed by malicious users whereby they inject code into your website to complete a range of actions from stealing your clients log in details, to installing malicious software on your user’s computers.  Websites that have been exploited by this can be blacklisted and marked by search engines as unsafe; making it paramount this issue is checked for. To prevent this it is also necessary to validate all user input and remove any malicious attempts to exploit a vulnerability. When creating a form always ensure you check the data being submitted and encode or strip out any HTML.

12. Email Form Header Injection

This vulnerability is a slightly less known one and sometimes overlooked.  This occurs when a malicious user attempted to inject data into your website’s email contact form to force it to email many users instead of you.  This is exploited to manipulate your website to send large amounts of spam emails.  If this is occurring your email address and server may be blacklisted as a known culprit for sending spam. Again the way to prevent this is to screen user input and remove all malicious attempts at exploiting this.

13.  Keep software up to date

It may seem obvious, but ensuring you keep all software up to date is vital in keeping your site secure. This applies to both the server operating system and any software you may be running on your website such as a CMS or forum. When website security holes are found in software, hackers are quick to attempt to abuse them.

If you are using a managed hosting solution then you don't need to worry so much about applying security updates for the operating system as the hosting company should take care of this.

If you are using third-party software on your website such as a CMS or forum, you should ensure you are quick to apply any security patches. Most vendors have a mailing list or RSS feed detailing any website security issues. WordPress, Umbraco and many other CMSes notify you of available system updates when you log in.

14.  Server side validation/form validation

Validation should always be done both on the browser and server side. The browser can catch simple failures like mandatory fields that are empty and when you enter text into a numbers only field. These can however be bypassed, and you should make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted into the database or could cause undesirable results in your website.

15. Passwords

Everyone knows they should use complex passwords, but that doesn’t mean they always do. It is crucial to use strong passwords to your server and website admin area, but equally also important to insist on good password practices for your users to protect the security of their accounts.

As much as users may not like it, enforcing password requirements such as a minimum of around eight characters, including an uppercase letter and number will help to protect their information in the long run.

Passwords should always be stored as encrypted values, preferably using a one way hashing algorithm such as SHA. 

Using this method means when you are authenticating users you are only ever comparing encrypted values. For extra website security it is a good idea to salt the passwords, using a new salt per password.

In the event of someone hacking in and stealing your passwords, using hashed passwords could help damage limitation, as decryption them is not possible. The best someone can do is a dictionary attack or brute force attack, essentially guessing every combination until it finds a match. When using salted passwords the process of cracking a large number of passwords is even slower as every guess has to be hashed separately for every salt + password which is computationally very expensive.

Thankfully, many CMSes provide user management out of the box with a lot of these website security features built in, although some configuration or extra modules might be required to use salted passwords (pre Drupal 7) or to set the minimum password strength. If you are using .NET then its worth using membership providers as they are very configurable, provide inbuilt website security and include readymade controls for login and password reset.

16. SSL

SSL is a protocol used to provide security over the Internet. It is a good idea to use a security certificate whenever you are passing personal information between the website and web server or database. Attackers could sniff for this information and if the communication medium is not secure could capture it and use this information to gain access to user accounts and personal data.

17. Security issues with Web services

When deploying a Web service, you have to think about how you will secure that service. Yes, even if you decide to open up access to the service to everyone and anyone, you still have to think about security — For example, protecting yourself against people seeking to deny access to your service. Security encompasses the following:

Equipment deployment

Authenticating users

Guarding data so that users only see what they should see

Tracking user activity

Any and all of these items may be a part of your overall security plan. In this chapter, we will take a look at all of these items and show how you can use them to make your Web service more secure.

Equipment deployment

One of the easiest things to do to secure your corporate data is to use hardware in an intelligent way. When deploying a publicly accessible Web service, you will want to expose as little of your internal infrastructure as necessary. There are a number of things you will want to do:

Put your database machines behind a firewall.

Use hardware to protect your equipment. For example, rely on routers instead of software firewalls. Hardware is typically faster at routing and is easier to lock-down. The software firewall may have unknown interactions with which to deal.

Make use of a demilitarized zone (DMZ). In other words, only put the machine serving the Web service on the public Internet.

The basic theme in equipment deployment, as you have just seen, is that you should strive to keep the majority of your machines behind some sort of protective firewall.

Authenticating users

You authenticate a user to learn his or her identity. The identity information might be used to make sure a person should have access to the Web service. You may also use the identity to track the user's activities. When it comes to authenticating your users, you have several options:

Application-level authentication — Users identify themselves via credentials supplied in the SOAP message.

HTTP basic authentication — The username and password are sent as clear text. This is not useful for secure applications, but it can be useful in combination with other identification techniques.

HTTP digest authentication — This tool sends a hashed version of the basic authentication credentials so that only the server can decode them.

Client certificates — Using a certificate provided by a certificate authority, the client can prove its identity during SSL authentication.

Windows authentication — Through HTTP basic/digest authentication or client certificates, IIS can map a user identity to a real Windows user.

All of these options have different uses.

Guarding data

When you make your data, you can use the user authentication mechanisms discussed to guard it. You can use Access Control Lists to guard files and SQL-based security to guard data in your database. As part of your security for the Web service, consider using a combination of user identity and other security mechanisms as a way to protect your data. For example, SQL server allows you to limit who can and cannot access various databases, tables and stored procedures. NTFS limits what files a particular user can access. Active Directory can be used to limit the network resources the user can access. An effective security plan uses a combination of methods to keep things safe. By authenticating the user using Windows Integrated Authentication and denying anonymous access to the Web service, the Web method will impersonate the caller when it executes. Any rights given to that caller will be enforced. This includes access to files, network resources and database objects.

Tracking user activity

Many applications require that you give users access to sensitive resources. When the users are using those resources, you will want to be able to see what was done. What did they look at? What actions did they fire? What data did they change? Most of the time, the users will not abuse their privileges. However, when the users are new and are trying to do something wrong, you want to see what they did. It will help you back out the changes the newbie made. As a forensic tool, tracking the changes will help you identify who did what and when.

All of this involves creating some sort of an auditing strategy. In the best of all worlds, you will know exactly who is calling you. Auditing was discussed as a debugging tool in chapter five, "Troubleshooting Web services/consumers." For security, you can use auditing to determine what the user did and when he or she did it. What information do you track when auditing user activity? This set of data is specific to security:

User identity (if available) — This lets you know who executed the action.

IP address of caller — This allows you to track the call back to a specific machine. This comes in handy, even if the user is coming through some sort of proxy server.

Free text field — You will want some sort of generic field that allows you to put all audit data into one table. Within this field, you can enter information particular to the action the user was performing. Think of putting in information that would be helpful when capturing details about what happened.

Time of action — By knowing when things happened, you will be able to figure out the order of the actions and string together what the user did.

Keep in mind that a lot of this information will be used only when something odd happens. Depending on what the Web service allows users to do, you may want to write programs that analyze the audit data, looking for use patterns that look suspicious. So, what would this logging mechanism look like? Ideally, the auditing mechanism would use some sort of delayed write mechanism, such as inserting the item in to a queue and having a listener actually log the item to a database. I will highlight the one function you would want to adapt to actually use Microsoft Message Queue (MSMQ) instead of writing to a file, as is done in the example.

The code presents a class named Audit that handles extracting the audit data from the Web service and storing the audit to a file. This class is used by a HelloWorld Web Method.

18. Buffer overflows -- Web application components written in languages that do not properly validate input can crash and in some cases, be used to take control of a process. These components can include CGI, libraries, drivers and Web application server components.

19. Insecure configuration management -- Web servers have many configuration options that effect security and are not secure out of the box. Having a strong configuration standard is critical.

20. Use Cookies Securely

Cookies are a useful way to keep user-specific information available. However, because cookies are sent to the browser's computer, they are vulnerable to spoofing or other malicious use. Follow these guidelines:

·         Do not store any critical information in cookies. For example, do not store a user's password in a cookie, even temporarily. As a rule, do not keep anything in a cookie that, if spoofed, can compromise your application. Instead, keep a reference in the cookie to a location on the server where the information is.

·         Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible.

·         Consider encrypting information in cookies.

·         Consider setting the Secure and HttpOnly properties on the cookie to true.

21. Guard against Denial-of-Service Threats

An indirect way that a malicious user can compromise your application is by making it unavailable. The malicious user can keep the application too busy to service other users, or if can simply cause the application to crash. Follow these guidelines:

·         Use error handling (for example, try-catch). Include a finally block in which you release resources in case of failure.

·         Configure IIS to use process throttling, which prevents an application from using up a disproportionate amount of CPU time.

·         Test size limits of user input before using or storing it.

·         Put size safeguards on database queries. For example, before you display query results in an ASP.NET Web page, be sure that there are not an unreasonable number of records.

·         Put a size limit on file uploads, if those are part of your application. You can set a limit in the Web.config file using syntax such as the following, where themaxRequestLength value is in kilobytes:

<configuration>

   <system.web>

        <httpRuntime maxRequestLength="4096" />

   </system.web>

</configuration>

Ways to Strengthen Web App Security

 When you hear talk about Web application security, there is a tendency to immediately think about attackers defacing Web sites, stealing credit card numbers, and bombarding Web sites with denial of service attacks. You might also think about viruses, Trojan horses, and worms. These are the types of problems that receive the most press because they represent some of the most significant threats faced by today's Web applications.

These are only some of the problems. Other significant problems are frequently overlooked. Internal threats posed by rogue administrators, disgruntled employees, and the casual user who mistakenly stumbles across sensitive data pose significant risk. The biggest problem of all may be ignorance.

The solution to Web application security is more than technology. It is an ongoing process involving people and practices.

We Are Secure — We Have a Firewall

This is a common misconception; it depends on the threat. For example, a firewall may not detect malicious input sent to your Web application. Also, consider the scenario where a rogue administrator has direct access to your application.

Do firewalls have their place? Of course they do. Firewalls are great at blocking ports. Some firewall applications examine communications and can provide very advanced protection. Firewalls are an integral part of your security, but they are not a complete solution by themselves.

The same holds true for Secure Sockets Layer (SSL). SSL is great at encrypting traffic over the network. However, it does not validate your application's input or protect you from a poorly configured server.

What Do We Mean By Security?

Security is fundamentally about protecting assets. Assets may be tangible items, such as a Web page or your customer database — or they may be less tangible, such as your company's reputation.

Security is a path, not a destination. As you analyze your infrastructure and applications, you identify potential threats and understand that each threat presents a degree of risk. Security is about risk management and implementing effective countermeasures.

The Foundations of Security

Security relies on the following elements:

• Authentication

Authentication addresses the question: who are you? It is the process of uniquely identifying the clients of your applications and services. These might be end users, other services, processes, or computers. In security parlance, authenticated clients are referred to as principals.

• Authorization

Authorization addresses the question: what can you do? It is the process that governs the resources and operations that the authenticated client is permitted to access. Resources include files, databases, tables, rows, and so on, together with system-level resources such as registry keys and configuration data. Operations include performing transactions such as purchasing a product, transferring money from one account to another, or increasing a customer's credit rating.

• Auditing

Effective auditing and logging is the key to non-repudiation. Non-repudiation guarantees that a user cannot deny performing an operation or initiating a transaction. For example, in an e-commerce system, non-repudiation mechanisms are required to make sure that a consumer cannot deny ordering 100 copies of a particular book.

• Confidentiality

Confidentiality, also referred to as privacy, is the process of making sure that data remains private and confidential, and that it cannot be viewed by unauthorized users or eavesdroppers who monitor the flow of traffic across a network. Encryption is frequently used to enforce confidentiality. Access control lists (ACLs) are another means of enforcing confidentiality.

• Integrity

Integrity is the guarantee that data is protected from accidental or deliberate (malicious) modification. Like privacy, integrity is a key concern, particularly for data passed across networks. Integrity for data in transit is typically provided by using hashing techniques and message authentication codes.

• Availability

From a security perspective, availability means that systems remain available for legitimate users. The goal for many attackers with denial of service attacks is to crash an application or to make sure that it is sufficiently overwhelmed so that other users cannot access the application.

Threats, Vulnerabilities, and Attacks Defined

A threat is any potential occurrence, malicious or otherwise, that could harm an asset. In other words, a threat is any bad thing that can happen to your assets.

A vulnerability is a weakness that makes a threat possible. This may be because of poor design, configuration mistakes, or inappropriate and insecure coding techniques. Weak input validation is an example of an application layer vulnerability, which can result in input attacks.

An attack is an action that exploits a vulnerability or enacts a threat. Examples of attacks include sending malicious input to an application or flooding a network in an attempt to deny service.

To summarize, a threat is a potential event that can adversely affect an asset, whereas a successful attack exploits vulnerabilities in your system.

How Do You Build a Secure Web Application?

It is not possible to design and build a secure Web application until you know your threats. An increasingly important discipline and one that is recommended to form part of your application's design phase is threat modeling. The purpose of threat modeling is to analyze your application's architecture and design and identify potentially vulnerable areas that may allow a user, perhaps mistakenly, or an attacker with malicious intent, to compromise your system's security.

After you know your threats, design with security in mind by applying timeworn and proven security principles. As developers, you must follow secure coding techniques to develop secure, robust, and hack-resilient solutions. The design and development of application layer software must be supported by a secure network, host, and application configuration on the servers where the application software is to be deployed.

Secure Your Network, Host, and Application

"A vulnerability in a network will allow a malicious user to exploit a host or an application. A vulnerability in a host will allow a malicious user to exploit a network or an application. A vulnerability in an application will allow a malicious user to exploit a network or a host."

— Carlos Lyons, Corporate Security, Microsoft

To build secure Web applications, a holistic approach to application security is required and security must be applied at all three layers. This approach is shown in Figure 1.1.

Figure 1.1

A holistic approach to security

Securing Your Network

A secure Web application relies upon a secure network infrastructure. The network infrastructure consists of routers, firewalls, and switches. The role of the secure network is not only to protect itself from TCP/IP-based attacks, but also to implement countermeasures such as secure administrative interfaces and strong passwords. The secure network is also responsible for ensuring the integrity of the traffic that it is forwarding. If you know at the network layer about ports, protocols, or communication that may be harmful, counter those potential threats at that layer.

Network Component Categories

This guide divides network security into separate component categories as shown in Table 1.1.

Table 1.1: Network Component Categories

Component	Description
Router	Routers are your outermost network ring. They channel packets to ports and protocols that your application needs. Common TCP/IP vulnerabilities are blocked at this ring.
Firewall	The firewall blocks those protocols and ports that the application does not use. Additionally, firewalls enforce secure network traffic by providing application-specific filtering to block malicious communications.
Switch	Switches are used to separate network segments. They are frequently overlooked or overtrusted.

Securing Your Host

When you secure a host, whether it is your Web server, application server, or database server, this guide breaks down the various secure configuration settings into separate categories. With this approach, you can focus on a specific category and review security, or apply security settings that relate to that specific category. When you install new software on your servers with this approach, you can evaluate the impact on your security settings. For example, you may address the following questions: Does the software create new accounts? Does the software add any default services? Who are the services running as? Are any new script mappings created?

Host Configuration Categories

Figure 1.2 shows the various categories used in Part IV of this guide, "Securing Your Network, Host, and Application."

Figure 1.2

Host security categories

With the framework that these categories provide, you can systematically evaluate or secure your server's configuration instead of applying security settings on an ad-hoc basis. The rationale for these particular categories is shown in Table 1.2.

Table 1.2: Rationale for Host Configuration Categories

Category	Description
Patches and Updates	Many top security risks exist because of vulnerabilities that are widely published and well known. When new vulnerabilities are discovered, exploit code is frequently posted on Internet bulletin boards within hours of the first successful attack. Patching and updating your server's software is the first step toward securing the server. If you do not patch and update your server, you are providing more potential opportunities for attackers and malicious code.
Services	The service set is determined by the server role and the applications it hosts. By disabling unnecessary and unused services, you quickly and easily reduce the attack surface area.
Protocols	To reduce the attack surface area and the avenues open to attackers, disable any unnecessary or unused network protocols.
Accounts	The number of accounts accessible from a server should be restricted to the necessary set of service and user accounts. Additionally, you should enforce appropriate account policies, such as mandating strong passwords.
Files and Directories	Files and directories should be secured with restricted NTFS permissions that allow access only to the necessary Microsoft Windows service and user accounts.
Shares	All unnecessary file shares, including the default administration shares if they are not required, should be removed. Secure the remaining shares with restricted NTFS permissions.
Ports	Services running on a server listen on specific ports to serve incoming requests. Open ports on a server must be known and audited regularly to make sure that an insecure service is not listening and available for communication. In the worst-case scenario, a listening port is detected that was not opened by an administrator.
Auditing and Logging	Auditing is a vital aid in identifying intruders or attacks in progress. Logging proves particularly useful as forensic information when determining how an intrusion or attack was performed.
Registry	Many security related settings are maintained in the registry. Secure the registry itself by applying restricted Windows ACLs and blocking remote registry administration.

Securing Your Application

If you were to review and analyze the top security issues across many Web applications, you would see a pattern of problems. By organizing these problems into categories, you can systematically tackle them. These problem areas are your application's vulnerability categories.

Application Vulnerability Categories

What better way to measure the security of a system than to evaluate its potential weak points? To measure the security resilience of your application, you can evaluate the application vulnerability categories. When you do this, you can create application security profiles, and then use these profiles to determine the security strength of an application.

These categories are used as a framework throughout this guide. Because the categories represent the areas where security mistakes are most frequently made, they are used to illustrate guidance for application developers and architects. The categories are also used as a framework when evaluating the security of a Web application. With these categories, you can focus consistently on the key design and implementation choices that most affect your application's security. Application vulnerability categories are described in Table 1.3.

Table 1.3: Application Vulnerability Categories

Category	Description
Input Validation	How do you know that the input that your application receives is valid and safe? Input validation refers to how your application filters, scrubs, or rejects input before additional processing.
Authentication	"Who are you?" Authentication is the process where an entity proves the identity of another entity, typically through credentials, such as a user name and password.
Authorization	"What can you do?" Authorization is how your application provides access controls for resources and operations.
Configuration Management	Who does your application run as? Which databases does it connect to? How is your application administered? How are these settings secured? Configuration management refers to how your application handles these operational issues.
Sensitive Data	Sensitive data refers to how your application handles any data that must be protected either in memory, over the wire, or in persistent stores.
Session Management	A session refers to a series of related interactions between a user and your Web application. Session management refers to how your application handles and protects these interactions.
Cryptography	How are you keeping secrets, secret (confidentiality)? How are you tamperproofing your data or libraries (integrity)? How are you providing seeds for random values that must be cryptographically strong? Cryptography refers to how your application enforces confidentiality and integrity.
Parameter Manipulation	Form fields, query string arguments, and cookie values are frequently used as parameters for your application. Parameter manipulation refers to both how your application safeguards tampering of these values and how your application processes input parameters.
Exception Management	When a method call in your application fails, what does your application do? How much do you reveal? Do you return friendly error information to end users? Do you pass valuable exception information back to the caller? Does your application fail gracefully?
Auditing and Logging	Who did what and when? Auditing and logging refer to how your application records security-related events.

Security Principles

Recommendations used throughout this guide are based on security principles that have proven themselves over time. Security, like many aspects of software engineering, lends itself to a principle-based approach, where core principles can be applied regardless of implementation technology or application scenario. The major security principles used throughout this guide are summarized in Table 1.4.

Table 1.4: Summary of Core Security Principles

Principle	Concepts
Compartmentalize	Reduce the surface area of attack. Ask yourself how you will contain a problem. If an attacker takes over your application, what resources can he or she access? Can an attacker access network resources? How are you restricting potential damage? Firewalls, least privileged accounts, and least privileged code are examples of compartmentalizing.
Use least privilege	By running processes using accounts with minimal privileges and access rights, you significantly reduce the capabilities of an attacker if the attacker manages to compromise security and run code.
Apply defense in depth	Use multiple gatekeepers to keep attackers at bay. Defense in depth means you do not rely on a single layer of security, or you consider that one of your layers may be bypassed or compromised.
Do not trust user input	Your application's user input is the attacker's primary weapon when targeting your application. Assume all input is malicious until proven otherwise, and apply a defense in depth strategy to input validation, taking particular precautions to make sure that input is validated whenever a trust boundary in your application is crossed.
Check at the gate	Authenticate and authorize callers early — at the first gate.
Fail securely	If an application fails, do not leave sensitive data accessible. Return friendly errors to end users that do not expose internal system details. Do not include details that may help an attacker exploit vulnerabilities in your application.
Secure the weakest link	Is there a vulnerability at the network layer that an attacker can exploit? What about the host? Is your application secure? Any weak link in the chain is an opportunity for breached security.
Create secure defaults	Is the default account set up with least privilege? Is the default account disabled by default and then explicitly enabled when required? Does the configuration use a password in plaintext? When an error occurs, does sensitive information leak back to the client to be used potentially against the system?
Reduce your attack surface	If you do not use it, remove it or disable it. Reduce the surface area of attack by disabling or removing unused services, protocols, and functionality. Does your server need all those services and ports? Does your application need all those features?

Summary

An ever-increasing number of attacks target your application. They pass straight through your environment's front door using HTTP. The conventional fortress model and the reliance on firewall and host defenses are not sufficient when used in isolation. Securing your application involves applying security at three layers: the network layer, host layer, and the application layer. A secure network and host platform infrastructure is a must. Additionally, your applications must be designed and built using secure design and development guidelines following timeworn security principles.