Web Application Security Threats

Contents

I. Introduction

II. Relevance and rational of study

III. Research question

IV. Project aims and objectives

Aims:

Objectives:

V. Literature review

VI. Limitation of reviewed literature

VII. Methodology

References

I. Introduction

People nowadays use the internet for everything: shopping, socializing, and working from home. A computer and a browser are all that is needed. Surfing the web has become an increasingly important part of our lives, especially during this global pandemic. Although this has aided us in coping with the situation, there are numerous threats that each of us faces while browsing the internet. The average user does not know or does not think about the possible harm that could be done online, and while users can themselves help web developers protect their data by using strong and uncommon password difficult to guess or brute force, by not sharing their personal data with other people, and basic safety measure that everyone should be aware of, there are issues that end-users cannot address and prevent, such as leaking of data, not using encryption and storing sensitive information in plain text, and so on.

This is the responsibility of web developers and other parties involved in developing and hosting the web applications. Web applications have always been vulnerable to attacks, and even though security measures are increasing, and bugs are constantly being fixed to prevent some type of attacks, malicious users also work on creating new ones or perfecting what already is out there to evade current defense mechanisms put in place, to keep up with defenders. To begin to understand why web applications are vulnerable and how attackers attempt to exploit these flaws we first need to understand what a web application is. A web application, unlike traditional software that runs locally on our machine, runs online on a server, and is accessed via a web browser such as Google Chrome or Internet Explorer.

Web applications are classified into two types: static and dynamic. The first sort does not need any database access and renders the content to users without modifying any aspects of it such as HTML, JavaScript, or Cascading Style Sheets (CSS). Those are the three key components of a front-end web application, used by developers to put together what end users see while viewing web pages. It is the same for all end users. As a result, a static web application is built with pre-compiled data and no back end processing.

The first type does not need to access any database and renders the content to the users without having any aspect of it such as HTML, JavaScript, or CSS modified. It is the same for every end-user. Therefore, a static web application is made with pre-compiled data, and there is no processing in the back end. On the other hand, dynamic web applications communicate with databases, and back end and the pages are dynamically changed thanks to the back end logic that displays different content to different users, generating the page shown to the end-user in real-time. (ULLAH, 2020)

As a result, it is commonly assumed that static web applications are absolutely protected, which is not the case. Although static web applications still pose a security risk, dynamic web applications, which interact with databases and accept user’ inputs, pose the greatest risk.

According to numerous lists released by different organizations such as The Open Web Application Security Project (OWASP), attacks involving user inputs, improper validation or filtering, and sanitization have been at the top of the lists in recent years. SQL Injection and Cross-Site Scripting (XSS) are two examples of such attacks. (Mitropoulos, et.al., 2019 1).

SQL stands for Structured Query Language, and it is a database query language. To do so, we use SQL statements to perform tasks like extracting data from databases and uploading data to them. (Coe, n.d.). For example, if we worked at an electronic store and had access to the database, we might and would change the price of a monitor from £2000 to £1500, which would not be an issue if we were the administrator. When an intruder succeeds in doing the same, however, serious problems can occur. When an unauthorized user manages to communicate with such database, we talk about SQL Injection. There are different types of it, and we will see them later in the paper.

XSS on the other hand, happens when an attacker tries to insert malicious scripts into legitimate websites. When an attacker can send malicious code to other users via a web application, it becomes possible. This weakness occurs when a web application does not validate users input in the output that it generates. The victim's browser has no way of knowing that the attacker's script is dangerous and will run it anyway. As a result, the code is executed when the victim enters a trusted web page or web application. The script would be able to access cookies and other information because of this. (KirstenS, n.d.)

The Open Web Application Security Project is a nonprofit organization that aims at improving software security. They produce and share tools such Juice shop, and articles/guides to allow everyone to understand, and improve their web applications security. (OWASP, 2021c)

They are best known for their OWASP Top Ten, an internationally recognized standard awareness document used by developers to keep their applications safe, which collects the most popular and important risks seen in the previous year. Injection is ranked first in the top ten security threats, followed by broken authentication, sensitive data leakage, XML external entities (XXE), broken access control, security misconfiguration, XSS, insecure deserialization, using components with established vulnerabilities, and finally, inadequate logging and monitoring. (OWASP, 2021a)

For the first time ever, the financial sector was surpassed by the government and technology sectors. The latter suffered from an increase of 70% of attacks compared to the previous years. Data from NTT’s 2020 Global Threat Intelligence Report (GTIR) shows how attacks were divided in 2019. 55% of them were attacks towards both web applications and application-specific attacks. This was an increase of 32% from 2018.

NTT’s CEO commented saying that basically every business uses web applications as the first point of contact with customers, and with a part of them not even following standard procedures such as updating systems, encrypting data, or patching bugs, criminals, not surprisingly, take advantage of it.

Content management systems such as WordPress and Joomla were the target of about 20% of the attacks. On top of that, with about 28% of attacks, the report shows how platforms like Apache Struts are attacked. It is also reported how cyber-criminals use old vulnerabilities not yet patched for their purposes. One of the most common web servers, Apache, was found to have 258 new vulnerabilities in the last couple of years, which caused it to be the third most attack web server. (Leyden, 2020)

In this paper I am going to look at the most common attacks, using different frameworks, web applications, such as Damn Vulnerable Web Application (DVWA), and Juice shop provided by OWASP, both tools to train security professionals, and help web developers understand how to properly secure their web applications, going through the top ten list to see how dangerous these vulnerabilities are, and how they work, to eventually recommend how to overcome the issues caused by them.

II. Relevance and rational of study

With web applications being more than ever a fundamental part of our lives, secure them from hackers’ attacks should be one of the first priorities. This is not a new fight, and it has been going on for decades. However, as already mentioned, malicious users still use to date, weaknesses known for years such as SQL Injection and Cross-site scripting.

In addition to this, technology gets constantly better, and web applications too, increasing their complexity, and how hard it is to secure them. Businesses are starting to realize that investing money in securing them is vital as it would cause huge damage, and most likely more losses than the money spent to secure them. Damage could vary from reputational damage, causing loss of trust and therefore customers, to speaking about businesses dealing with European customers, high fines from the General Data Protector Regulator (GDR), which purpose is to make sure that organizations respect people’s personal data, which covers any information that can lead to identifying an individual.

Classic examples are name, last name, email, and so on. Therefore, users are given more control over how their data are used online, how they are collected and protected. Organizations are also forced to comply with the use of protection such as encryption to store the data, and they are required to justify the reason to collect them in the first place. (Wolford, no date.).

Application programming interfaces (APIs), add another layer of difficulty for web applications to be secured. From the European Union Agency for Cybersecurity (ENISA) Threat Landscape 2020 - Web application attacks we can see a 52% increase in the number of web application attacks from 2018 to 2019 as shown in the image below. Looking into web application vulnerabilities, they reported that vulnerabilities due to misconfigurations were as high as 84%, followed by XSS and broken authentication interestingly. (ENISA, 2020)

(ENISA, 2020)

Web applications security has been monitored and improved over the years, but there is still, and most likely always be, more work to do about it. While the issue is being always more recognized, attackers constantly find a way about it to avoid security measures. I believe that this is an important project considering it is about an everyday problem we all deal with, and it could add to the security of web applications in addition to what is already out there, especially since technology does indeed evolve every day and what was enough last year could not be still as efficient today.

III. Research question

This project will focus on researching web security threats, exploring them, and try to find new strategies to protect them. By using web applications already existing and used by web developers and penetration testers, with a large variety of attacks, and different levels of security, it will be possible to analyze the most occurring ones and try to find a better way to prevent them.

Main question

How easy is it to exploit web application vulnerabilities, and is there anything that can be implemented to improve the security?

IV. Project aims and objectives

Aims

1. Explore web application vulnerabilities
2. Conducting experiments to explore those vulnerabilities
3. Recommend the best defense strategy to secure the applications.

Objectives

1. Set up an experimental environment with virtual machines to emulate attackers and web application server
2. Exam different types of vulnerabilities, and how hard they are to exploit

V. Literature review

Web application protection is a critical challenge that necessitates ongoing research in order to increase the effectiveness of the defenses. In this literature review, I will look at articles that look at the topic and see what they suggest and how it might be improved.

The first paper looks at attacks like SQL Injection and XSS that take advantage of untrusted input validation errors. According to the new Symantec Internet Security Threat Study, every day websites were struck by more than 229,000 attacks, according to this journal published in 2017.

The report also revealed that more than 76 percent of the websites targeted have unpatched vulnerabilities, which, thanks to new tools built to exploit these old vulnerabilities, make this form of attack quite simple to lend. These attacks take advantage of the complex nature of web applications by making them execute code that isn't supposed to be executed. By doing so, the attacker is able to communicate with the database at the back end of the web application and possibly extrapolate personal data such as usernames, passwords, credit card numbers, and so on.

On the other hand, XSS attacks use web applications to send malicious scripts to the website visitor, and as a result, they could steal cookies, redirect the victim to dangerous websites, and more. In this literature, they used a web vulnerability scanner, VulScan, to test web applications against XSS and Injections, using penetration testing and different evasion techniques.

Looking at the countermeasures for these two attacks, these fall under three main categories: secure implementation, penetration testing, and defense mechanism deployment.

Referring to the OWASP Top 10 list, they noticed that most of the vulnerabilities listed could be either eradicated or reduced by using various techniques such as input validation and sanitization, using strong cryptography, using the principle of least privilege, and using only safe APIs. To prevent SQL Injection, popular solutions such as parameterized queries, which allows the authorized user(s) to interact with the database only by providing parameters to insert into a pre-compiled statement, requiring the developer to first define the entire SQL code, and then pass the parameters to the query input validation and sanitization are used. (OWASP, 2021b), input validation and sanitization are used.

Instead, putting in place the least privilege principle and using data encryption may have a significant effect on reducing the harm caused by successful SQL Injection attacks. Input validation or sanitization, output encoding or escaping, and the use of a material protection policy are all techniques for avoiding XSS attacks. While output encoding can partially prevent user-supplied data from being executed, web developers should also use input validation or sanitization, as well as output encoding or escaping, to prevent XSS content from being stored and mirrored.

Another countermeasure is to place security mechanisms outside the web application servers, such as web application firewalls. Those examine all inbound traffic, use rules or expressions to detect attacks, and then block those attacks. Firewalls are more convenient because they eliminate the need for web developers, the majority of whom are not security experts, to do extensive code reviews or rewrite all vulnerable code. The rule-set coverage determines the intensity of security protection, as it does for all rule-based defense mechanisms. Penetration testing is another method for protecting web applications discussed in this paper.

It can be achieved in either of two ways: by cybersecurity specialists such as penetration testers or white-hat hackers, or by using some software.

Using experts can be time consuming and costly, which is why it is primarily reserved for applications that need a higher level of protection. The latter approach is quicker and less expensive, but it provides less accuracy. In this paper, they developed their own web vulnerability scanner, VulScan, which I will not be covering, prioritizing instead other tools. They mentioned how despite the countermeasures in place, it is unrealistic to think that there could be completely secure web applications out there. It is almost impossible to write perfect code that does not leave an open door for criminals, using as an example parameterized queries, which even though they do help in preventing SQL Injections, are still flawed. In the same way, both penetration testing and using defensive tools like firewalls, require manual configuration to update rules and filters, which can be improperly coded. (Huang, 2017)

In a most recent paper published in 2019, the researchers look into various attacks triggered by a lack of user input validation, finding that many of them share some characteristics, as shown by the fact that some security mechanisms can defend against various types of these attacks. They investigate defense mechanisms already researched in other published papers, dividing them into six distinct groups:

1. Accuracy: defense systems are only as effective as their detection ability, which necessitates a low rate of false positives and negatives.
2. Availability refers to whether or not the security system is open to the public.
3. Performance overhead: Overhead placed by mechanisms at their deployment points.
4. Ease of use: if the mechanism is deployable and can be quickly implemented by security experts.
5. Security: the ability of the defense mechanism to overcome attempts to bypass it by attackers. (Mitropoulos, et.al., 2019 2).

A significant flaw in risky web application attacks is the lack of input validation. As a result, attackers will use this vulnerability to insert malicious code into applications. Exploits of this nature can take a variety of forms depending on the application's execution context and the position of the programming error that results in the attack Injection attacks can be classified into two types.

The first is made up of binary code, while the second is made up of higher-level language code. Memory corruption vulnerability exploitation has progressed to the point that countermeasures to such attacks have been established.

In this paper, however, they only focused on protections that defend web applications from attacks based on higher-level language code. Higher-level language code includes both Domain Specific Language, which consists of all these programming languages only used for a specific application domain such as HTML for web pages, and Dynamic Language such as python, JavaScript, and so on. DSL-based injection attacks play a major part in the injection problem, as DSLs like SQL and XML are used extensively in the development of both web and mobile applications.

Many apps, for example, have user interfaces in which a user enters data to communicate with the software, which then interacts with the database in the back end. This data can be used in a SQL query that is run on the database targeted by the cybercriminal. A classic SQL Injection example comes with the command “SELECT password FROM users WHERE id=’Fabio’. By adding a simple OR ‘1’ = ‘1’, a malicious user could get the entire table from the database, getting access to every username, and password in that table.

Unfortunately, the constant increase of SQL injection attacks, even though it has been known for more than a decade, shows that programmers are not really so cautious. Malicious users can, in the same way, use DSLs like JSON using similar techniques. A malicious user has the ability to access sensitive data, modifying it, or deleting it. The authors also mention how HTML can be used in the wrong way when the web application does not handle as it is supposed to user inputs. This DSL if poorly configured could allow attackers to enter valid HTML so that they can inject their own content into the web page. This is mainly associated with XSS.

These injections can also be used for a Cross-Site Request Forgery (CSRF) attack, which usually does not always involve code injection. They explain how an attacker would go about launching an injection attack which is in one of two ways. One method is to use a victim's browser to start the attack, injecting the malicious code into the web application through the browser.

For example, an attacker might inject a malicious script into a URL and then use social engineering to get a user to open it, such as by using a phishing attack. The second way would see the attacker be able to insert malicious code straight into the server with an HTTP request. This is what happens when a web application receives and handles user feedback without proper user input validation. By doing so the attacker could be able to get the user’s session by stealing their cookies, communicate with the database, redirect users, and so on. (Mitropoulos, et.al., 2019 3).

Looking at possible defenses from these attacks, we go back to the six groups they split the defensive mechanisms into, defining each of them. Accuracy plays a vital role, seeing as defensive mechanisms must recognize incoming attacks. However, there must be a balance between sensitivity which defines the probability an attack would be recognized: the higher the sensitivity, the more the defense will be triggered.

This leads to the second point, specificity, which takes into consideration the probability that a normal communication between legit user and app will not trigger the defense.

Lastly, they consider the positive predictive value, and the negative predictive value, which respectively look at the probability that an attack is not a false positive and that it is not a false negative. They then talk about availability, highlighting how important it is for everyone to have the source code available for researchers to make it easy for them to contribute and improve the defense mechanisms.

Next, they discuss performance overhead, saying that this type of detection due to their use, can impose an expense since they usually add some extra computation to existing applications. Depending on the solution, the expense can be generated in various locations: it may involve the server, the client, or both. The utility of a mechanism is therefore determined by the computing cost it requires and where it implements it since various overheads can be appropriate on the server-side versus the client-side.

The fifth point is about security, explaining that the “war” between attackers and defenders is never-ending. An attacker will keep finding a way to surpass defenders’ mechanisms, and defenders will improve the countermeasures to keep up with attackers, until they start over.

Finally, they divide the point of detections into 4:

• The user’s browser;
• Going from the server to the user’s browser;
• Before it gets to the database, at the database abstraction layer;
• Once the attacker’s code gets to the server’s database.

Many defense mechanisms are discussed in this article. They categorized them into three groups: etiological, symptomatic, and hybrid.

For the purposes of this literature review, I will just go into etiological, which aims to prevent attacks by identifying their roots and sources. The approaches in this category are: Parse-Tree Validation, Instruction Set Randomization, and Policy Enforcement.

Parse-Tree Validation aims to compare the as the name suggests, the tree representation of the structure of the code about to be performed, with the one originally intended. If the trees are different, it is likely that the web application is being attacked. Parse-tree validation, as implemented in SQLcheck (a mechanism that checks the query without the user input, with the one post user input to prevent SQL Injection), is an important method for detecting DSL code injection attacks. This is not the case, though, for mechanisms that use elements from this method to detect JavaScript-driven XSS attacks by examining the syntax trees of scripts.

The second method explored is Instruction Set Randomization (ISR), which was originally meant to combat injection of binary code, and consists in modifying the representation of code based on a transformation, and according to it also randomize the execution environment. By doing so, without knowing the algorithm, attackers are not able to inject malicious code by taking advantage of invalid user input validation. It is used in the same way by SQLrand, a program that let programmers creating SQL statements using randomized instructions. These queries are then recreated at runtime using the same key used during the first step to randomize the statement, and since the attackers do not have access to this key, they are therefore not able to inject the code.

The last method I will cover from this paper is Policy Enforcement. Developers use this tool to protect from both XSS and CSRF threats. Developers that use frameworks that support policy enforcement must specify security policies on the server. They have different ways to implement those policies. It can be done server-side, on the user’s browser, with JavaScript, and so on. (Mitropoulos, et.al., 2019 4)

They came to the conclusion that research accuracy needed to be enhanced. In reality, they discovered that several protections are not thoroughly checked, and that, despite the fact that various methods have been implemented to defend web apps against Injection attacks, these have been around for over 15 years and are unlikely to go away anytime soon. Their conclusion is that available resources to defend against these types of attacks should be worth more than the cost of using them, not only in terms of capital, but in terms of overall quality, such as efficiency, ease of use, and so on. (Mitropoulos, et.al., 2019 5)

VI. Limitations of reviewed literature

The papers look at the most popular and exploited web application attacks, including SQL Injection, XSS, and CSRF. They also came to the conclusion that, despite the fact that some of these flaws have been around for more than a decade, they are still a serious threat to people's safety and privacy, identifying a lack of accuracy when testing new tools, recognizing that there will probably never be perfect code without flaws, and that developers still do not understand how important it is to properly secure their work. Despite the fact that these papers look at the most frequent attacks, they neglect to look at those in the OWASP Top 10. This list is also revised every year with the most recent attacks. As a result, I'll use a variety of open-source frameworks, such as DVWA and Juice Store, to dig deeper into these current challenges and try and come up with ways to defend against them.

VII. Methodology

In this part, I will discuss the approach that was selected for this project. In this chapter, I will describe how I approached the challenges of achieving the project's goals, as well as the environments, frameworks, and tools I used to perform the experiments that produced the following findings. This chapter, I think, will be useful for prospective researchers interested in conducting similar experiments. I will be particularly detailed in my explanations of how I went about doing these tests.

Research Methodology

Given the purpose of the paper, this project was completed using the experimental approach, often used to discover new solutions for a specific problem. Since the goal is to determine the cause and effect of specific attacks on web applications, it is important to use a controlled environment for both consistency and legal reasons. At the same time, being able to control variables in the environment to see if they affect the outcomes is critical.

Research Approach

The research approach in this paper is qualitative method. As mentioned before, this paper will look thoroughly into some of the top 10 web application attacks listed by OWASP in different environments, and with different levels of security, observing, and explaining the results for future researcher to build up on them. Exploratory analysis is the focus of qualitative research. It is used to figure out what's driving people's decisions, thoughts, and motives. It offers information about the issue or aids in the development of ideas or theories for quantitative analysis. Qualitative research is also used to discover patterns in thinking and beliefs, as well as to delve deeper into a challenge. Unstructured and semi-structured approaches are used in qualitative data processing. Focus groups (group discussions), participant interviews, and participation/observations are all standard approaches. The sample size is usually limited, and respondents are chosen to meet a predetermined quota.

References

Coe, J. (2021) SQL Basics - Hands-On Beginner SQL Tutorial Analyzing Bike-Sharing.. Available at: https://www.dataquest.io/blog/sql-basics/ (Accessed: 22 April 2021).

ENISA (2020) ENISA Threat Landscape: Web application attacks. Available at: https://www.enisa.europa.eu/publications/web-application-attacks (Accessed: 19 April 2021)

Huang, H. et. al. (2017) Web Application Security: Threats, Countermeasures, and Pitfalls. Available at: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7945157&isnumber=7945156 (Accessed: 22 April 2021).

KirstenS (no date) Cross Site Scripting (XSS). Available at: https://owasp.org/www-community/attacks/xss/ (Accessed: 22 April 2021).

Leyden, J. (2020) Web application attacks rise to account for almost half of all data breaches. Available at: https://portswigger.net/daily-swig/web-application-attacks-rise-to-account-for-almost-half-of-all-data-breaches (Accessed: 14 April 2021).

Mitropoulos, D. et.al. (2019) Defending Against Web Application Attacks: Approaches, Challenges and Implications. Available at: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7865911 (Accessed: 22 April 2021).

OWASP (2021a) Top Ten Web Application Security Risks. Available at: https://owasp.org/www-project-top-ten (Accessed: 15 April 2021).

OWASP (2021b) SQL Injection Prevention Cheat Sheet. Available at: https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html (Accessed: 20 April 2021).

OWASP (2021c) Who is the OWASP® Foundation? Available at: https://owasp.org/ (Accessed: 14 April 2021).

Ullah, R. (2020) Static vs dynamic websites. Available at: https://www.fasthosts.co.uk/blog/static-vs-dynamic-websites/ (Accessed: 22 April 2021).

Wolford, B. (2021) What is GDPR, the EU’s new data protection law? Available at: https://gdpr.eu/what-is-gdpr (Accessed: 20 April 2021).