Writing Secure Web applications

Writing Secure Web applications

Security and privacy are prime concerns for everybody. Websites and web applications have much vulnerability that can be exploited. Web application development is very different from other environments. Web clients and Internet communications pose many security problems not found in traditional client−server applications. Web developers must know how web servers and web browsers interact, the nature of Internet communications, and the attacks most web applications undergo when they are made available on the Internet. 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. Although traditional firewalls have effectively prevented network-level attacks, most future attacks will be at the application level, where current security mechanisms are woefully inadequate. Application-level security vulnerabilities are inherent in a Web applications code, regardless of the technology in which the application is implemented or the security of the Web server and backend database on which it is built. A recent advisory published by Internet Security Systems claims that 11 widely deployed shopping cart applications are vulnerable to a simple attack that lets hackers purchase goods for much less than their listed price. 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.

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. Security relies on the following elements:

1.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.

2.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.

3.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.

4.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.

5.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.

6.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.

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.

Vulnerability in a network will allow a malicious user to exploit a host or an application. Vulnerability in a host will allow a malicious user to exploit a network or an application. Vulnerability in an application will allow a malicious user to exploit a network or a host. To build secure Web applications, a holistic approach to application security is required. 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. 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?

Securing Web applications:

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.

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. Input, whether it comes from visitors or servers, should handled with care. You may have found the following expert advice in text dealing with security problems: always validate input. The problem with a content management system as Drupal is that the input is not well defined. A lot of senseless advice is available too. One sometimes encounters recommendations to strip quotes from for example name fields (') to prevent SQL injection. Let's hope none of the users of such a system have the name O'Reilly.

Another frequently touted 'solution' is filtering on keywords. To prevent SQL injection one would prohibit SQL keywords as SELECT or DROP in content. Unfortunately, no user would be able to mention 'insert', 'select' and 'update', not uncommon in normal English. To make matters worse, Dutch users wouldn't be able to mention licorice (drop) anymore. Obviously not a very generic (or even sane) approach. So what we really have to do is make sure that, regardless the data, its content can never be interpreted as SQL. To do this, we use the escaping functions provided by the database API. We do this escaping in the database layer and not directly after receiving input as it may not be the only escaping (or filtering) we have to do.

Maintaining state information

Common methods of providing state information are to use query string parameters, hidden form fields, or cookies to store state information on the client side. For example, you might append a userID parameter to a query string, store the userID in a cookie, or include the userID in your pages as a hidden form field. Each of these methods can be subject to attack because clients cannot be trusted and the state information is easily accessible. Crackers often use query string parameters to test a web application for weaknesses. For example, a client requests the following URL:

http://www.hamsteak.com/accountBalance?userID=42

Clients can change the value of the userID parameter to any value in their browser before submitting the request. Clients that generate HTML requests can spoof hidden form fields. To find hidden form fields, users must only view the source of your web application's HMTL pages in their browser. Since clients can compose any request they want, they can add or remove hidden form fields in the requesting document before submitting it. Rogue data can poison cookies because they are usually plain-text files stored on the client. In addition, the client can change the HTTP Cookie header prior to making a request, so the presence of a cookie is not a conclusive sign of trustworthiness. You can use the following techniques to maintain state information while reducing the risk of compromising your application:

• Only use hidden query string parameters, form fields, and cookie data for inconsequential data.

• Use the HttpSession objects to maintain state. JRun generates a large, random session key that is passed to the client as a cookie, appended to the URL, or added as a hidden form field, depending on your session implementation. When using session data, this ID is the only data that passes between the client and server. JRun uses the ID to reference the session data that the server stores.

• Use secure cookies. You can indicate that cookies can be sent only using a secure protocol, such as HTTPS or SSL, in the jrun-web.xml file

Protecting databases

Try not to allow user input to be used directly in a database query. For example, you might prompt users for a keyword, such as a last name, and then use that keyword in your query, as the following sample shows:

String lname = request.getParameter("lastname");

sqlstmt = "SELECT firstname, lastname FROM users WHERE lastname = \"lname\"";

Without validation, users can substitute any value in the query string or in the form field before submitting the page. One technique used by attackers is to try and insert a rogue query into form fields. This is known as a SQL injection attack. For example, a user might add the following to a form field.

jones; select * from users;

Depending on your database, this can execute both queries.

If your implementation requires adding user input directly to a database query, try one or more of the following techniques to prevent rogue queries from being processed:

• Limit the size of the user input. For more information.

• Remove illegal characters. For more information

• Define and enforce database permission settings.

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 tampering proofing 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?

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.