Common Web Application Vulnerabilities -Part 1

With the advent of COVID-19, many businesses have had to hurriedly take their businesses online. According to the IE Domain Registry, registrations of .ie domains have jumped by 56% in Q2. With so many businesses embracing this new way of working, it is important to recognise the risks associated with operating your business online.

Throughout October, given it is European Cyber Security Month (ECSM) we will be providing guidance and advice on what your organisation can do to improve your cyber security posture. In this blog post, we will describe two common web application vulnerabilities we often see and we will discuss how to resolve them.

Both of these vulnerabilities arise from failure to implement a single principle: input validation. Input validation is the act of examining any and all application inputs to ensure that they are what you are expecting. This can be something as simple as ensuring that an input field that’s expecting a number receives only a number.

 

SQL Injection (SQLi)

The first vulnerability we’ll be discussing today is an injection vulnerability. More specifically, SQL injection. SQL, or the Structured Query Language, is a language used to retrieve data from databases. For example, if you wanted to retrieve the details of a user whose ID is 1. The Java code to execute this query would appear as follows:

The code takes a user ID from a URL parameter and retrieves the user details for that user ID. Using the example above if we were to enter some unexpected input, for example, a user ID value of1’ OR 1 = 1, when the application attempts to execute the query, it will appear as follows:

Select * from users where userid = 1’ OR 1 = 1

As the SQL server does not understand the difference between the original query and the user input, it will interpret OR 1 = 1input as part of the query. The database will now be combed for records where the user ID is equal to 1orif 1 is equal to 1. As this comparison is always true, the query will retrieve the data of all users in the database.

This is but one application of a SQL injection attack. SQLi can occur in many places and attackers can use SQLi attacks to bypass logins, or in profile pages, which can result in the disclosure of user information. SQLi can even be used to attack the system in which the database resides resulting in command execution on the server.

 

Remediation

Thankfully, the remediation of SQL injection vulnerabilities is quite simple. Most programming languages support parameterised queries. Parameterised queries allow applications to differentiate between the query and the input data by providing a placeholder in the query for inputs. The vulnerable code described above could be remedied with parameterised queries in the following manner:

The question mark acts as a placeholder for the input data, and we set it using the setInt method. The query will not execute unless it receives the value its expecting in this example an integer, or a number. Any attempts at SQL Injection will cause the query to fail and no data will be returned.

For more information regarding prepared statements:

• .net
• PHP
• NodeJS

 

Cross-Site Scripting

Cross-Site Scripting, commonly referred to as XSS, shifts the target of attack from the application itself to the users of the application. Cross-Site Scripting is the injection of JavaScript into a user’s browser. Most web applications make use of JavaScript, a programming language that is executed in the user's browser, as opposed to on a server. JavaScript is what allows us to create modern, interactive websites.

Let’s take a look at a sample Java/JSP code snippet that could be used in a profile page.

The code fetches the username value from a URL parameter and echoes it into the page. While this may seem harmless, it opens up the application to what is known as reflected cross-site scripting.

The URL would appear as:

application.com/profile?username=secora

However, the username parameter can be altered to include JavaScript content.

application.com/profile?username=secora”>

If this URL is accessed by a user, they will see a popup with the text “Malicious content goes here”.

As this XSS enters through the URL and needs to be entered each time to make the attack possible, it is categorized as reflected cross-site scripting, it reflects back to the user upon the user executing the URL. XSS that is kept in a database and can be entered once and accessed multiple times is referred to as stored cross-site scripting.

This is a simple example that we use to show that XSS is possible. The real impact of XSS can be much worse. Attackers will often use vulnerabilities like these to steal user session details, allowing them access to user accounts. Often XSS is combined with phishing attacks, by presenting users with fake login screens and capturing the credentials.

 

Remediation

The first line of defence in preventing cross-site scripting is to employ HTML entity encoding before returning data to users. For an XSS attack to take place, an attacker needs certain characters to enter into a script - <, >, (, ), etc. HTML entity encoding takes these characters and transforms them into their entity counterparts - < becomes <. > becomes >. These can also be numerical - ( becomes (, for example.

To carry this out in code, you can use Spring’s htmlEscape method from the htmlUtils package.

Alternatively, Apache’s commons contains an escapeHtml method that functions almost identically.

 

How can we help?

Identifying these vulnerabilities without an expert’s eyes can be difficult. At Secora Consulting, we offer a range of services that can identify these vulnerabilities and more. Our web application penetration testing service will constitute a simulated attack on your web application, with the aim of replicating the actions of a malicious actor and identifying vulnerabilities. Looking for a more comprehensive review of your IT estate? Consider an infrastructure penetration test, where we examine your entire infrastructure and determine the most likely causes of attack.

Further Reading:

• Common Web Application Vulnerabilities - Part 2
• Anatomy of a ransomware attack
• Protecting your organisation from social engineering attacks