It’s no secret that businesses are increasingly using web applications in this day and age. Web applications make it convenient to streamline corporate operations, enhance efficiency, and thus save expenses for tasks that would otherwise be done manually.
Web apps are prone to risks and cyberattacks despite their growing popularity. This article will provide insight into the significant attacks that a web application is vulnerable to. Then you’ll discover how you can incorporate a reverse proxy to minimize the threats.
But before diving into security aspects, let’s take a look at the architecture of a typical web application.
In most circumstances, web applications consist of web servers and web pages. Web servers accept requests from clients(your web browsers), which a web server process and returns the response to the client.
While the server-side is coded using dynamic programming languages such as PHP, Python, ASP.NET, etc., the client-side is coded using HTML, CSS, and JavaScript.The communication between the client and server takes place through HTTP protocol.
All communication appears to be straightforward in the diagram above, with requests traveling back and forth between the client and the server. However, this is not always the case.
Unfortunately, web applications using the above design are subject to cyberattacks by outsiders between the client and the server.
Let’s take a look at some of the most exciting cyber attack statistics before we dive into the nature of these attacks.
Other industries that face risks include government institutions (11%), IT, E-commerce, and the mass media.
We can arrive at a conclusion from these statistics that some stringent measures are required to protect web applications from vulnerabilities. Some of the security flaws occur due to the issues in coding, whereas other reasons could be due to inadequate infrastructure used by the web application. This is where the Web Application Firewall (WAF) comes into the picture which can minimize vulnerabilities by filtering packets, blocking HTTP traffic, and unauthorized logging.
We will explore it further below. Before that, a brief overview of significant security threats.
SQLi -SQL injection is a web security vulnerability that lets the attacker manipulate SQL queries that an application makes to the database. By doing so, they gain access to potentially valuable information that anyone can not reach easily.
A simple, most familiar example would be to take advantage of unsanitized user input to the hacker’s advantage. Let’s assume that there is a text box that requests user ID. Then based on the User ID, the query retrieves all the information belonging to that user.
So suppose in the text box if the user had entered the below:
User Id: 228 or 1=1
Then the resulting query would be the below:
SELECT * FROM Users WHERE UserId = 228 OR 1=1;Then it would retrieve all the data in the user’s table, including passwords if the table contains password data.
XSS occurs when a user injects a malicious script mainly in javascript through unsanitized input fields. Usually, an attacker sends this malicious script to a user who will not be suspected. The end user’s browser is unaware that this script is harmful and will execute the script.
As a result, this malicious script can access all the data associated with cookies, session tokens, or any other sensitive information. Furthermore, these scripts can rewrite the HTML of a webpage.
Suppose a user would have to log in to a web application using the login credentials. In that case, the website’s proprietary algorithm generates a unique session ID for the entire communication between the user and the webserver for that session.
If the web developers have not encrypted secure data that travels back and forth between the user and the webserver, there are high chances for an intruder to steal it and act as the user. This scenario mainly occurs when you log into the internet using public WiFi in coffee shops.
WAF is a layer 7 defense in the OSI model which can be placed at the entry point to the destination server, as shown in the below diagram. It protects the server’s internal network from attacks and hides the network topology of the server.
In order for WAF to work, you should make additional configurations in the server. Like the firewalls, WAF filters incoming and outgoing HTTP traffic that appears dangerous to the server’s internal network if they don’t satisfy the rules that you set on the WAF.
WAF is also a type of reverse proxy that we will discuss in the next section.
A job of a proxy server is to hide your IP address and replace it with that of the proxy server. Well, a reverse proxy also does the same and enhances the web server’s security by hiding it as well as the internal network topology of the server.
The client only knows the proxy server’s address, and hence the actual server is hidden from the client.
Ideally, you can use a reverse proxy as a Web Application Firewall (WAF) which we discussed above. You can implement WAF on web applications on devices with reverse proxy configured. As a result, the scope of WAF in enhancing security becomes wider. The attacker is also unable to see the actual location of the webserver.
All reverse proxies perform all the following fundamental operations:
Since our objective is to overcome the cyberattacks mentioned previously, the reverse proxy needs to perform additional functionalities besides the steps mentioned above.
When a client sends a request to the server, the reverse proxy will sanitize the input by comparing it with its signature database. The programmers develop these signatures with highly advanced regular expressions. The Reverse proxy’s decision to allow the request with the user input will be solely based on the blocklist filter and whitelist filter approach.
The blacklist filter stores the known harmful requests. It then compares each request to the entries in the list. If it discovers a match, it rejects the request. Different variations of the same assault must be recorded separately in the list. You would be able to prevent only the known assaults using blacklists.The black list’s comprehensiveness helps to its efficacy.
A whitelist filter captures the entire collection of valid requests for a specific site. As a result, the white list prevents attacks by only allowing known requests to reach the server. The process of constructing a white list, on the other hand, is time-consuming and requires knowledge of the whole range of legitimate requests that a user can potentially send to a server.
Furthermore, it can be overwhelming to create all the valid requests to hundreds of thousands of database vendors out there in case of SQL injection
Before sending the response from the server back to the client, the reverse proxy validates it. A blacklist is used to accomplish this usually. The blacklist filter may hide known responses from clients who don’t need to view them. Error messages are an example of this type of data; the reverse proxy can replace the error with a generic error message containing no sensitive data.
The reverse proxy can also log the request for subsequent examination. The best approach is to configure logging for only the requests that reverse proxy blocked initially. You should carefully examine the logs throughout the first stages of installation. This is essential to verify that the reverse proxy does not block any genuine requests.
In this article, we hope you understand the vulnerabilities in a web application and how you can use a reverse proxy to resolve these threats. Indeed, the reverse proxy will not evict all the possible vulnerabilities associated with web applications.
However, it would be a great strategy to mitigate most of the threats you encounter in a web application. So finally, we hope you will apply the concepts learned in this article should you experience security concerns in your web application.