Defense In Depth For Web Applications
Introduction
In today’s complex ecosystem, the importance of application security has emerged as a leading factor to maintain the trustworthy image of a company. One little crack in the system is enough to drop the stock price of a company and it is not just a potential problem for Tech companies but it is a common issue for everyone who has a connection to the Internet. At this point, we can presume that the defense is a major task for all applications. So we can just put one big password to protect our Virtual Server, right? Not quite, in today’s web architectures, there are so much possible vulnerabilities that we need an advanced approach to handle all. Because that one little crack we talked about can be found on any level in the system. That is why one of the best solutions is the technique called defense in depth. As you can see “in depth” means we need to consider every part of the system to create multi-layered security measure. It is a coordinated use of multiple security countermeasures to protect the integrity of the information assets. Practically, this means that an intruder finding a way in our web application will be unable to compromise our entire system, or at least at the cost of a fairly higher amount of effort.
Application
Front-end
XSS
According to OWASP, XSS is still the third most popular vulnerability in web applications. XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
There are several rules to follow for preventing XSS and you can find them in this OWASP XSS Cheat Sheet. The most common solution is to escape every HTML code printed on the page, especially if there is some data coming from user to be shown on the page.
CSRF
Cross-Site Request Forgery is now the 13th most critical risk for web applications according to OWASP. This attack makes an unwanted request to a web application where the user is currently authenticated. So another application on the same browser can forge a request for another valid application.
Best practices to prevent this attack includes using a nonce for each request, tokenizing the identity and using Referrer headers. As always, OWASP has a special updated cheat sheet about CSRF prevention.
Back-end
On the server side, the key idea is to never trust user input. The OWASP top 10 shows very well that the most common vulnerabilities are linked to malicious user input.
SQL injections are still very common even though they are fairly easy to prevent. They occur when a malicious user can input SQL statements which are then executed by the application, allowing data destruction, identify spoofing, sensitive data modifications and so on. The OWASP offers guidelines on the matter and even specific recommendations for widely used languages and frameworks.
One other critical aspect of a web application is authentication. There are several secure and peer-reviewed authentication mechanisms that you can integrate into your application, so you should never have to design and implement your own authentication. Most frameworks come with authentication built in, for instance, Django or Symfony. If you are dealing with APIs, consider JSON Web Tokens (JWT) which manage both authentication and permissions.
Securing the web server
The web server is a crucial part of a web application as it is the entry point of every HTTP requests. There are several ways in which we can harden the web server configuration.
As of 2017, every website should be served over HTTPS by default. This prevents the data from being transferred in cleartext and leaking sensitive information — think about passwords or authentication cookies. Let’s Encrypt enables anybody to obtain free SSL certificates recognized by all major browsers. The TLS configuration of your web server should also be hardened. For instance, disabling SSL 3, TLS 1.0 and 1.1 prevent attacks exploiting vulnerabilities in these outdated protocols if all your clients support TLS 1.2.
Now that your web server serves your application over HTTPS, you need to enforce clients to use HTTPS when contacting your server. The HTTP Strict Transport Security (HSTS) is an HTTP response header sent by the web server specifically for this matter. For instance,
Strict-Transport-Security: max-age=31536000 will instruct the client that it must only use HTTPS to contact the domain for the next year. You can also submit your domain name to the HSTS Preloading List, used by Chrome, Firefox, and Safari, so that this is enforced by default directly in the browser, even before the first request to the web server.
One other very useful HTTP response header is the Content Security Policy (CSP) defining the sources of content that the browser is allowed to load. Web pages usually include a lot of external assets such as javascript scripts, images, CSS files, fonts… By default, the browser loads them all regardless of their origin, thus allowing attackers to inject malicious content that will be executed by the browser. This is where the CSP header kicks in by whitelisting approved sources of content. For instance,
Content-Security-Policy: script-src ‘self’ will prevent the browser from loading javascript scripts from third-party domains. You can define policies for many types of resources, including javascript, images, CSS, frames or fonts. For more details about CSP and how to implement it, Troy Hunt wrote an excellent article on CSP.
Information about useful HTTP response headers and how to deploy them can be found here.
Hardening the host
Now that your application and web server are secure, what about an attacker managing to get in your server using other services such as SSH or FTP? What about an attacker still managing to get in your web application? You also need to harden the host of your web application. In the following, we will see several principles and mechanisms result in a more secure environment for your systems.
The first thing to ensure when managing a system is to keep it up to date. Vulnerabilities in major software are found every day, exposing your system to attackers scanning for vulnerable targets. You can, for instance, subscribe to your GNU/Linux distribution security mailing list to receive important announcements about new vulnerabilities in the software that you are using. Some distributions also provide mechanisms to automatically install security updates.
Keeping your system up to date does not prevent it from being exposed to unknown vulnerabilities. As mentioned in the introduction, one single entry point and an attacker could possibly take over your whole system. In order to limit this risk, you should isolate your services so that attacking one of them does not lead to taking over the others. The bare minimum is to execute your services on their own, non-privileged user — don’t use root for everything! Also, use the security mechanisms offered by your OS, Systemd, for instance, offers several security features taking advantage of the Linux kernel to isolate processes from each other: masking parts of the file-system or making them read-only, isolating network access, taking away capabilities (killing processes, using ptrace, …) and more.
In the recent years, containerization emerged and has almost become the standard way of deploying web applications. Unlike virtual machines, which replicate an entire host — kernel and emulated devices included — containers allow the existence of several isolated user-space instances on the same host. The main benefit is that there is almost no overhead and that containers can be brought up and down in a matter of seconds.
Last but not least, when everything fails you want to be able to investigate what happened. For that, you need logging in order to keep track of errors, suspicious events, and other useful metrics.
Network
On the network level, things are a bit different than the other layers. The network is usually not configured or managed by the end-user but by some System Admin. We can say that network security is about all the data flow and policies between low-level elements like routers, switches, and firewalls. Nevertheless, this is also an important field for defense and there are multiple possible vulnerabilities. Thankfully, this layer is managed by professionals on their subject but even professionals can make mistakes.
Firewall
A firewall is the main defense system in a network. It can be a software or a hardware and it monitors all the data coming in and out on a network. Putting a firewall in a network is not enough because it has to be configured properly to work efficiently. The main purpose of a firewall is to monitor and control access by configured rules.
There are multiple types of firewalls but most recent ones called next-generation firewalls are the most interesting ones. Next-generation firewalls are basically traditional firewalls with all the core functions of a firewall but they have also deep packet inspection and intrusion prevention capabilities. These new features are important because Network environments are changing super fast and the security becomes more content related. So we need to introduce more intelligence on the most crucial part of the Network. By understanding the user’s request, an intelligent firewall can adjust the security needs to a specific situation.
Anti-DDoS
A distributed denial-of-service (DDoS) is one of the popular attacks which can make an online service unavailable by flooding the system with an enormous traffic. The target becomes overwhelmed by the traffic size and shuts down. The term distributed means this attack uses multiple sources from different locations and it generally uses botnets.
Anti-DDoS solutions need to be implemented at service provider level as it is important to have an understanding of the global network. That is why we can find these solutions at hosting providers or at companies specialized in this field like Cloudflare.
The most common solution to prevent a DDoS is to have enough bandwidth which can carry the immense quantity of traffic to a web application.
Conclusion
We reviewed the different layers of security that we can implement in our system in order to oppose the best defense against an attacker. If you want more details on a particular subject or more specific guidance on how to implement the mentioned mechanisms, you can follow the links spread throughout the article.
Remember that the idea is to prevent attackers from compromising the entire system just by finding a single vulnerability in one component. Let’s not fool ourselves, attackers will eventually get in, but let’s make their life harder!
Authors
Borga AYDIN
Pierre KUHNER
References
https://scotthelme.co.uk/hsts-the-missing-link-in-tls/
https://scotthelme.co.uk/content-security-policy-an-introduction/
https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/
