Consider these attributes of secure web application architecture to improve your web application security against common attacks and meet business needs.
Web application architecture typically covers the basic rendering and return of information to a client, usually on a web browser. Behind the scenes, a web application will draw upon many distinct layers. These may include servers used for presentation, business, and data. There are different architectures consisting of different layering strategies depending upon the need.
Creating a web application architecture that is best suited to your requirements is essential. However, creating web application security is also important. This ensures that all business needs and performance goals of the web application are achieved without any security incident when deployed within the production environment.
This is the first question that a system architecture team should ask when creating the architecture for web application security. General web application architecture may contain serious security flaws. Web application security is an attempt to remediate these.
This article will help identify ways to create a secure web application architecture. We’ll consider the benefits of multi-tier architecture versus the use of single- or two-tier web application architectures. Then we’ll dive into the individual attributes necessary to secure them.
Figure 1 illustrates a simple web application architecture. The application’s web server and database server share the same host machine. This architecture is very simple and useful for early stages of project development. However, it is not good enough for production applications as it introduces a single point of failure.
Figure 1: A sample single-tier web application architecture
As Figure 2 illustrates, you can separate the database server from the web server. However, both servers remain single points of failure within the architecture. If one server crashes, the application can stop.
Figure 2: A sample two-tier web application architecture
Introduces a single point of failure. Single points of failure are parts of an application that, upon failure, stop the entire application from operating as intended.
Multi-tier architecture separates different components of the application into multiple tiers/layers according to their functions. Each tier generally runs on a different system. This provides compartmentalization and avoids a single point of failure.
Multi-tier applications (e.g., Figure 3) enhance application security in comparison to single-tier (e.g., Figure 1) or two-tier applications (e.g., Figure 2).
Figure 3: A sample multi-tier web application architecture
Eliminates a single point of failure. Multi-tier architecture, as shown in Figure 3, eliminates the single point of failure locations within the application.
Provides enhanced security. The implementation of several tiers helps to enhance a secure web application architecture. The absence of a single point of failure limits the attacker’s chances of taking control of the entire application.
Once you decide upon your web application security architecture, there remain several attributes that still need to be considered. The following section discusses inter-tier authentication, server-side validation, secure communication, data at rest, and logging.
Multi-tier architecture results in different tiers/components of an application interacting with each other to achieve seamless functionality. Before initiating communication or data transfer with other tiers, application tiers should authenticate with each other. This ensures that an attacker cannot impersonate the identity of other communicating tiers/components. Secure inter-tier authentication can be achieved using following mechanisms:
Username and password-based inter-tier authentication should be avoided as the security of usernames and passwords used for inter-tier authentication becomes critical.
Data validation can occur on the client side (web browser) and the server side (web server). Client-side validation provides a seamless experience to end users as all user-provided input is validated quickly at the browser-level. Client-side validation does not require a data round trip to the server. Thus, it reduces the server load and helps improve its performance.
However, implementation of only client-side validation is not enough to protect against malicious users. In many cases, client-side validation can easily be bypassed by an attacker. This is possible since an attacker can create their own requests. Or, modify existing requests to send to the server independently from the web browser client. For example, an attacker may utilize a web proxy to intercept HTTP traffic between a web browser and the server. By intercepting the traffic an attacker can alter parameters after client-side validation is performed.
To protect the application from user-provided malicious data, implement server-side validation along with client-side validation. The implementation of server-side validation prevents attackers from accessing the application through alternate means (e.g., proxy) to bypass client-side validation.
Server-side validation should also perform strict input validation in the form of a white list.
Applications should use HTTPS to encrypt traffic over the network. HTTPS provides an end-to-end secure connection between the client application (browser) and the server. Communication via HTTPS helps protect data in transit. TLS and SSL are the two common protocols used to protect the confidentiality and integrity of the communication over HTTPS. At a high level, a server uses valid SSL certificates provided by a Certificate Authority to identify itself to a browser. The browser and server then generate a shared secret which is used to encrypt all network communications.
If HTTPS is not enabled on the application server, the traffic between the browser and server flows over a non-encrypted connection. This helps an attacker retrieve sensitive information.
Even if the application server supports HTTPS, there are common considerations for all HTTPS implementations:
Protect any data stored at rest within a back-end database server. After all, an attacker’s goal is to steal sensitive data. This data could exist in many formats, such as: financial information, personally identifiable information (PII), and personal health records. This makes the protection of data stored at rest critically important.
There are common considerations when protecting data at rest. These include:
Logging is an essential part of web application security. Log files help identify security incidents and provide information about application problems and unusual conditions that the application may face. If the application or user account comes under attack, information logged by application within log files will be pivotal in understanding the attack and, in some cases, tracing it back to the attacker. Thus, a logging system is a huge benefit for developers and system administrators. Design and maintain it carefully with the following considerations:
It is important to remember that there are many universally acceptable “insecure” architectures. On the other hand, it is difficult to find a universally acceptable “secure” architecture. Web application security varies from application to application based on its business and performance needs. The attributes discussed should help the system architect design a stable and secure web application architecture to protect against common attacks.