Web Application Security and Vulnerabilities

Let’s dive into web applications, their security and common vulnerabilities.

Writers: Palak Shravagi, Suyash Chavan

A good programmer is someone who always looks both ways before crossing a one-way street.

- Doug Linder

A web application is an application that runs on browsers. It consists of front-end components that are the website interface, or what the user sees that runs on the client-side browser, and other back-end components like web application source code that runs on the server-side (back end server/databases). Web applications are platform-independent and all users accessing a web application use the same version and the same web application, which can be continuously updated and modified without pushing updates to each user.

Web Application Layout

A website layout is a pattern or framework that defines a website’s structure. It has the role of structuring the information present on a site both for the website’s owner and for users, No two web applications are identical Web applications are designed and programmed differently, and back-end infrastructure can be set up in many different ways. So to summarize we can say that web application layout has three main categories.

Web Application Infrastructure

Application infrastructure consists of all the components such as the database that are needed to deliver an application and its functions and services to the customer. Web applications can use many different infrastructure setups. These are also called models. The most common ones can be grouped into the following four types:

1. Client-Server

The client-server model, or client-server architecture, is a distributed application framework dividing tasks between servers and clients, server hosts the web application in a client-server model and distributes it to any clients trying to access it. In this model, there are two components first which are front-end components that execute on the client-side by a web browser and another is back-end components that run and execute by the hosting server.

The client-server relationship communicates in a request-response messaging pattern When a client visits the web application’s URL (e.g. https://www.google.com). Once the user clicks on the button it is actually making the HTTP request to the server which interprets the request and starts processing the client’s request to complete it. Once the server gets the required result it sends the results back to the client’s web browser.

2. One Server

In One server model the entire web application and its components, including the database, are hosted on a single server. It is the easiest and most straightforward to implement, one server model If any web application hosted on this server is compromised in this architecture, then all web applications’ data will be compromised or if any of the hosted web applications are vulnerable, the entire web server becomes vulnerable. Hence, it is also the riskiest design.

3. Many Servers — One Database

Many servers-One database model separates the database onto its own database server and allows the web application’s hosting server to access the database server to store and retrieve data. This model allows several web applications to access a single database to have access to the same data without syncing the data between them. The web applications that use this model can be replicates of one main application or they can be separate web applications that share common data. This model’s main advantage is ‘segmentation’, where each of the main components of a web application is located and hosted separately. In case one web server is compromised, other web servers are not directly affected and, if the database is compromised through a SQL injection vulnerability, the web application itself is not directly affected. So this model is safe as compared to one server model.

4. Many Servers — Many Databases

This model is based upon the Many Servers, One Database model. In Many Server-Many Database within the database server, each web application’s data is hosted in a separate database. The web application can only access private data and only common data that is shared across web applications. It is also possible to host each web application’s database on its separate database server.

Web Application Components

The components that make up a web application represent all the components that the web application interacts with. These are divided into the following three areas: UI/UX, Client, and Server components.

+-- Client
|
+-- Server
| |
| +-- Web Server
| |
| +-- Web Application Logic
| |
| +-- Database
|
+-- Services (Microservices)
| |
| +-- 3rd Party Integrations
| |
| +-- Web Application Integrations
|
+-- Functions (Serverless)

Web Application Architecture

Web application architecture is a mechanism that determines how application components communicate with each other. Web applications of different sizes and complexity levels all follow the same architectural principle, but details may differ. The components of a web application are divided into three different layers.

Presentation Layer - The presentation layer is accessible to users via a browser and consists of user interface components and UI process components that support interaction with the system. It’s developed using three core technologies: HTML, CSS, and JavaScript. While HTML is the code that determines what your website will contain, CSS controls how it will look. JavaScript and its frameworks make your website interactive — responsive to a user’s actions.

Business Layer - This layer also called or Domain Logic or Application Layer accepts user requests from the browser, processes them, and determines the routes through which the data will be accessed. The workflows by which the data and requests travel through the back end are encoded in a business layer. For example, if your application is a hotel booking website, business logic will be responsible for the sequence of events a traveler will go through when booking a room.

Persistence Layer - It is also called the storage or data access layer, the persistence layer is a centralized location that receives all data calls and provides access to the persistent storage of an application. The persistence layer is closely connected to the business layer, so the logic knows which database to talk to and the data retrieving process is more optimized. The data storage infrastructure includes a server and a Database Management System, software to communicate with the database itself, applications, and user interfaces to obtain data and parse it.

Microservices - Microservices are independent components of the web application, which in most cases are programmed for one task only. For example, for an online store, we can decompose core tasks into some microservices like registration, search, payment, etc. These components communicate with the client and with each other. The communication between these microservices is Stateless which means that the request and response are independent. This is because the stored data is stored separately from the respective microservices. The microservices depend on each other and another essential and efficient microservice component is that they can be written in different programming languages and still can interact. Microservices make development faster and which ultimately encourages innovation.

Serverless - Serverless computing is a method of providing backend services on an as-used basis. This type of architecture gives a company the flexibility to build and deploy applications and services without having to manage infrastructure; all server management is done by the cloud provider, which gets rid of the need to provision, scale, and maintains servers needed to run applications and databases So, it enables to build more agile applications so the developer can innovate and respond to change faster.

Architecture Security

The general architecture of web applications and each web application’s specific design is important when performing a penetration test on any web application. In many cases, an individual web application’s vulnerability may not necessarily be caused by a programming error but by a design error in its architecture. For example, an individual web application may have all of its core functionality secure implemented. However, due to a lack of proper access control measures in its design, i.e., use of Role-Based Access Control(RBAC), users may be able to access some admin features that are not intended to be directly accessible to them or even access other user’s private information without having the privileges to do so. To fix this type of issue, a significant design change would need to be implemented, which would likely be both costly and time-consuming.

Front End vs. Back End

The terms front end and back end web development, or the term Full Stack web development, refers to both front and back end web development. These terms are becoming synonymous with web application development, as they comprise the majority of the web development cycle. However, these terms are very different from each other, as each refers to one side of the web application, and each function and communicate in different areas.

Front End

The front end of a web application contains the user’s components directly through their web browser (client-side). These components make up the source code of the web page we view when visiting a web application and usually include HTML, CSS, and JavaScript, which are then interpreted in real-time by our browsers. This includes everything that the user sees and interacts with, like the page’s main elements such as the title and text HTML, the design and animation of all elements CSS, and what function each part of a page performs in JavaScript. In web applications, front-end components should adapt to any screen size and work within any browser on any device. This contrasts with back-end components, which are usually written for a specific platform or operating system.

Back End

The back end of a web application drives all of the core web application functionalities, all of which are executed at the back end server, which processes everything required for the web application to run correctly. It is the part we may never see or directly interact with, but a website is just a collection of static web pages without a back end. There are four main back end components for web applications:

  1. Back end Servers: The hardware and operating system that hosts all other components and are usually run on operating systems like Linux, Windows, or using Containers.
  2. Web Servers: Web servers handle HTTP requests and connections. Some examples are Apache, NGINX, and IIS.
  3. Databases: Databases (DBs) store and retrieve the web application data. Some examples of relational databases are MySQL, MSSQL, Oracle, PostgreSQL, while examples of non-relational databases include NoSQL and MongoDB.
  4. Development Frameworks: Development Frameworks are used to develop the core Web Application. Some well-known frameworks include PHP, C#, Java, Python, and NodeJS JavaScript.

Front End Vulnerabilities

Front-end components are interacted with on the client-side. So, if they are attacked, they do not pose a direct threat to the core back end of the web application and usually will not lead to permanent damage. However, as these components are executed on the client-side, they put the end-user in danger of being attacked and exploited if they do have any vulnerabilities. If a front-end vulnerability is leveraged to attack admin users, it could result in unauthorized access, access to sensitive data, service disruption, and more. Although the majority of web application penetration testing is focused on back end components and their functionality, it is important also to test front end components for potential vulnerabilities, as these types of vulnerabilities are can sometimes be utilized to gain access to sensitive functionality which may lead to compromising the entire server.

Sensitive Data Exposure

Sensitive Data Exposure refers to the availability of sensitive data in clear text to the end-user. This is usually found in the source code of the web page or page source on the front end of web applications. This is the HTML source code of the application, not to be confused with the back-end code that is typically only accessible on the server itself. We can view any website’s page source in our browser by right-clicking anywhere on the page and selecting View Page Source from the pop-up menu. Sometimes a developer may disable right-clicking on a web application, but this does not prevent us from viewing the page source as we can merely type ctrl + u or view the page source through a web proxy such as Burp Suite. Let’s take a look at the google.com page source. Right-click and choose View Page Source, and a new tab will open in our browser with the URL view-source:https://www.google.com/. Here we can see the HTML, JavaScript, and external links.

Sometimes we may find login credentials, hashes, or other sensitive data hidden in the comments of a web page’s source code or within external JavaScript code being imported.

Prevention

  • Avoid extra code or comments that are not necessary for the web application to function properly.
  • Developers should also review client-side code to ensure that no unnecessary comments or hidden links are left behind.
  • Classify data types within the source code and apply controls on what can or cannot be exposed on the client-side.

HTML Injection

HTML injection is a type of injection vulnerability that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user’s session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.

This vulnerability occurs when user input is not correctly sanitized and the output is not encoded. An injection allows the attacker to send a malicious HTML page to a victim. The targeted browser will not be able to distinguish (trust) legitimate parts from malicious parts of the page and consequently will parse and execute the whole page in the victim’s context.

A simple example of HTML injection is to change the visible content of the page. For example, an attacker may use a stored HTML injection to inject a visual advertisement of a product that they want to sell. A similar case would be when the attacker injects malicious HTML that aims to harm the reputation of the page, for example, for political or personal reasons.

In both these cases, the injected content aims to look like a legit part of the HTML page. And in both these cases, a stored HTML injection vulnerability would be required by the attacker.

Cross-Site Scripting (XSS)

Cross-site scripting (also known as XSS) is a web security vulnerability that allows an attacker to compromise the interactions that users have with a vulnerable application. It allows an attacker to circumvent the same-origin policy, which is designed to segregate different websites from each other. Cross-site scripting vulnerabilities normally allow an attacker to masquerade as a victim user, to carry out any actions that the user is able to perform and to access any of the user’s data. If the victim user has privileged access within the application, then the attacker might be able to gain full control over all of the application’s functionality and data.

There are three main types of XSS attacks. These are:

  • Reflected XSS, where the malicious script comes from the current HTTP request.
  • Stored XSS, where the malicious script comes from the website’s database.
  • DOM-based XSS, where the vulnerability exists in client-side code rather than server-side code.

Common Web Vulnerabilities

If we were performing a penetration test on an internally developed web application or did not find any public exploits for a public web application, we may manually identify several vulnerabilities. We may also uncover vulnerabilities caused by misconfigurations, even in publicly available web applications, since these types of vulnerabilities are not caused by the public version of the web application but by a misconfiguration made by the developers.

Broken Authentication/Access Control

Broken authentication and Broken Access Control are among the most common and most dangerous vulnerabilities for web applications.

Broken Authentication refers to vulnerabilities that allow attackers to bypass authentication functions. For example, this may allow an attacker to log in without having a valid set of credentials or allow a normal user to become an administrator without having the privileges to do so.

Broken Access Control refers to vulnerabilities that allow attackers to access pages and features they should not have access to. For example, a normal user gaining access to the admin panel.

Malicious File Upload

Another common way to gain control over web applications is through uploading malicious scripts. If the web application has a file upload feature and does not properly validate the uploaded files, we may upload a malicious script (i.e., a PHP script), which will allow us to execute commands on the remote server.

Even though this is a basic vulnerability, many developers are not aware of these threats, so they do not properly check and validate uploaded files. Furthermore, some developers do perform checks and attempt to validate uploaded files, but these checks can often be bypassed, which would still allow us to upload malicious scripts.

Command Injection

Many web applications execute local Operating System commands to perform certain processes. For example, a web application may install a plugin of its choosing by executing an OS command that downloads that plugin, using the plugin name provided. If not properly filtered and sanitized, attackers may be able to inject another command to be executed alongside the originally intended command (i.e., as the plugin name), which allows them to directly execute commands on the back end server and gain control over it. This type of vulnerability is called command injection.

This vulnerability is widespread, as developers may not properly sanitize user input or use weak tests to do so, allowing attackers to bypass any checks or filtering put in place and execute their commands.

SQL Injection (SQLi)

Another very common vulnerability in web applications is a SQL Injection vulnerability. Similar to a Command Injection vulnerability, this vulnerability may occur when the web application executes a SQL query, including a value taken from user-supplied input.

If the user input is not properly filtered and validated (as is the case with Command Injections), we may execute another SQL query alongside this query, which may eventually allow us to take control over the database and its hosting server.

References:
https://portswigger.net/web-security
https://academy.hackthebox.eu/module/details/75

You can connect with us on LinkedIn, Twitter, Facebook, or by visiting our website.

We are Open Source Club from Walchand College of Engineering, Sangli