A couple of weeks ago, I noticed an article about how to secure web applications which caught my eye, to be honest, the article was aimed at how to secure web applications the old-fashioned way and not considering the new approaches to deliver web applications. Therefore, I wanted to share some of my reflections since been working on a lot of different approaches now when it comes to web applications (and handling ransomware exploits where attackers have been leveraging web shells using vulnerabilities) and the intention is not to focus on the code itself since I’m not a developer but still there are a lot of other tasks that can be done outside to provide better security to a web application.
Web Applications can come in different shapes and sizes, but most common now is using
- Web Applications running on standalone webservers
- Web Applications running cloud-native components (Kubernetes)
- Web Applications running on PaaS services from Public Cloud vendors
How to secure each of these applications will differ from platform to platform, but I will go through some of them.
First of we can look at communication flow from an endpoint/client to an app or service. This is the main flow of communication where you enter an URL and using a combination of DNS and Routing your browser will find the way to the service you want to access.
This has been the standard for a while now. However, with more of the worldwide network traffic moving to new protocols such as HTTP/3 this traffic flow changes.
HTTP/3 uses QUIC as a transport layer protocol (which again used UDP) but is built to be more reliable transfer using UDP. The end goal of HTTP/3 is to provide a safer and faster traffic flow for web traffic. However, that is not without its own downsides since it opens for a lot of new types of DDoS attacks –> What Is a QUIC Flood DDoS Attack? | QUIC and UDP Floods | Cloudflare UK
NOTE: A clever way to see traffic statistics is by looking at Cloudflare radar –> Cloudflare Radar
At the same time, much of the attacks against web applications are DDoS-based attacks or if you are running a known web framework that has a known vulnerability you will also most likely get someone that will try to exploit that is as well.
So let us look at the different ways to protect web applications. It should also be noted that it is a difference between web applications that are end-user facing (like line-of-business applications) or end-customer facing such as eCommerce.
NOTE: The focus throughout this blog post series I will be looking at WordPress applications running in the following deployments. I will not cover the actual steps of setting up WordPress on the different deployment options.
1: Azure App Service
2: Azure Kubernetes
3: Linux VM with LAMP
Some of the configurations are generic and are important considerations not limited to the deployment model, however, there are different configuration and security best practices depending on what kind of delivery framework you are using to deliver the web application.
HTTP/QUIC Protocol Configuration –
You should always look at supporting the latest iteration of the HTTP web protocols since it is built to provide better security and scaling issues that have been with the HTTP protocol, ensuring a faster web browsing experience. Most browsers today are already supporting this –> Can I use… Support tables for HTML5, CSS3, etc. A problem that occurs is that firewall vendors which today provide IDS/IPS inspection does not support inspecting this traffic and therefore rely on failing back to older versions to be able to inspect the traffic. As an example of how Palo Alto describes it –> Define Traffic to Decrypt (paloaltonetworks.com) however if you are not required to provide network-based inspection of the traffic I recommend that you investigate how to enable QUIC for your webservers. Even slow adopters like Microsoft support QUIC in Server 2019. Microsoft is also working on its own implementation of QUIC here –> microsoft/msquic: Cross-platform, C implementation of the IETF QUIC protocol. (github.com)
A couple of other features you should have enabled on your website.
- Strict-Transport-Security (HSTS) – lets a website tell browsers that it should only be accessed using HTTPS, instead of using HTTP. If someone tries to provide a phising domain in combination with DNS forgery this will help to protect against those types of attacks.
- Hide any server information as part of the HTTP header – Usefull to hide sensitive information and therefore disclose information about what kind of server is running or network service.
- HTTP DoS Protection – Typically a feature on WAF products where the feature serves Javascript challenges to responders which are used to stop bot traffic. Since regular end-users will be able to run the javascript that is presented while the bots will not be able to respond to the JS challenge.
SSL/TLS Configuration
A common tool to use to determine what kind of encryption types, algorithms, and SSL ciphers are used on your website can be checked easily using ssllabs.com
Where you will be scored on what kind of SSL/TLS protocols that your site supports and what kind of ciphers are supported. A good practice is looking into what kind of ciphers are being used and what kind of protocols are supported. While the encryption level ensures that communication between a client and the server is encrypted, still doesn’t mean that your server or web application is secure. But this should be reviewed since Microsoft also with others are now removing support for the older protocol versions –> Transport Layer Security 1.0 and 1.1 disablement – Microsoft Lifecycle | Microsoft Docs
Also, that browsers will soon not allow communication with sites supporting older protocols or even display an error message.
Pre-authentication
With many common CMS platforms, you have different types of admin pages or a site editor that is used to manage the site. Many of these CMS platforms have a built-in identity service or limited authentication mechanisms which makes them vulnerable to brute force attacks. There are fortunately a lot of different options available to hide admin pages or management parts of the web applications behind authentication mechanisms. Or even hide the site entirely behind an authentication mechanism.
I’ve written previously about using Cloudflare access to protect the WP-Admin pages of WordPress –> Using Cloudflare Access to protect WordPress Admin sites | Marius Sandbu (msandbu.org) which allows me to protect certain parts of the website or the entire website. Another good option is using Azure AD Application Proxy which can be used to publish internal web services using Azure AD. However, many of the common ADC vendors also provide authentication mechanisms that can be used to protect web applications behind an identity provider.
Network Configuration
When hosting a website or web application that is publicly available, you are always at risk for getting attacked either by type of vulnerability attack or using DDoS attacks (which will become more common with the new QUIC and HTTP/3 protocols becoming the norm. Many attacks where attackers are trying to leverage known vulnerabilities often come from unknown origins (hiding behind ToR nodes) or from “known” countries from which you want to ban traffic. Or even DoS attacks, where attackers are hammering your website or API’s with certain API calls.
There are a couple of services that are important to utilize.
- IP Reputation filter – In many cases you might have a hosting service or a firewall services (or an ADC) that supports IP Reputation features which allows you to block traffic coming from a “known” IP address which is known for malicious traffic. This feature often also blocks traffic coming from ToR nodes.
- Geo Block – This feature works on blocking traffic from specific origination countries. When you are hosting web applications you often have a good indication of where the traffic is originating from. Have analytics in place such as Google Analytics gives you an indication of where traffic is coming from, and data here should be used to block other countries which are not visiting the site regularly and block traffic from there.
- Rate limiting (API Rate Limiting) – When you have public-facing APIs as part of a service or a frontend you should also investigate using some form of API rate limiting to ensure that no one can do a DDoS attack against the API call or someone misusing it for other purposes.
- DDoS Protection mechanisms – As mentioned earlier having DDoS protection mechanisms will be crucial for the future with the adoption of QUIC/HTTP3 protocols. There are many DDoS protection services provided from CDN vendors, using TCP anycast. This means that DDoS protection is applied at the edge and not where the actual service is hosted. This is something that for instance Cloudflare provides as part of their service. This means that instead of having a centralized DDoS protection service, which will impact the service for all users if you are under attack. Having a decentralized DDoS protection service means you can stop the attackers at the edge.
- Logging and Monitoring – One of the difficult things to monitor is Web Shell malware, which is difficult to detect as it is easily modified by attackers and often employs encryption, encoding, and obfuscation. When a potential web shell is detected, administrators should validate the file’s origin and authenticity. There are often two main detection techniques: 1: “Known-good” comparison 2: Web Traffic Anomaly Detection both require monitoring capabilities to the underlying file system and secondly traffic logs to see abnormal traffic patterns. The NSA has a great GitHub repository highlighting different ways to monitoring against web-shells –> nsacyber/Mitigating-Web-Shells: Guidance for mitigation web shells. #nsacyber (github.com) I will also come back to this in a later part of securing the different services. Also, logging and monitoring need to provide context about the overall traffic to your website. This document provides some great guidance in terms of website monitoring –> Web_Server_Log_Review_[CIO_IT_Security_08-41_Rev_4]_03_25_2020docx.pdf (gsa.gov)
In this first blog post, we took a closer look at how we can protect web-based services either UI-based or API-based. It is important to consider what impact your firewall or web application firewall can do to protect your web applications both now and in the future. With the move to cloud-based delivery model, also means that security mechanisms change depending on what kind of delivery model you choose. In the next blog post, I will go through more in detail how to secure the 3 different delivery models with Azure App Service, LAMP Server, and lastly Azure Kubernetes Services.