Understanding the Differences Between Technical and Logical Web Application Vulnerabilities

Web application vulnerabilities can be split into two distinct categories; logical vulnerabilities and technical vulnerabilities. The main difference between the two categories is their exploitation. Typically to exploit a technical vulnerability, the attacker takes advantage of a coding mistake, such as lack of sanitization that allows him to inject malicious code. To exploit a logical vulnerability, the attacker has to find a flaw in the way the web application makes decisions (the logic part), for example, the web application fails to check a user’s permissions. 

Therefore technical vulnerabilities can be easily detected with an automated web application security scanner but logical vulnerabilities cannot. Let’s look into the ins and outs of both vulnerability categories to find out the whys, whats and whens.

Technical Vulnerabilities

Two popular technical vulnerabilities that we will be looking at in this article are SQL Injection and Cross-site scripting. They are considered as technical vulnerabilities because even though there are thousands of different possibilities how to exploit a cross-site scripting or a SQL Injection vulnerability, the outcome of a successfully exploited vulnerability is always the same.

How is a SQL Injection Vulnerability Detected?

An SQL Injection vulnerability allows the attacker to bypass the security mechanisms of a website and send SQL commands directly to the backend database. To find out if a website is vulnerable to SQL Injection or not the attacker tries to input malicious code in a website form’s input field. If the website responds with an error that includes an SQL error, the website is vulnerable to SQL Injection.

How is an XSS Vulnerability Detected?

A cross-site scripting vulnerability allows the attacker to bypass the security mechanisms of a website and inject malicious code that is executed when the victim accesses the website. To find out if a website is vulnerable to cross-site scripting or not the attacker tries to inject the malicious code via a website form’s input field, for example in a forum or blog post. If the injected code is executed upon a page reload the website is vulnerable to XSS.

Predictable Outcome of Technical Vulnerabilities

Therefore even though SQL Injection and XSS are exploited in different ways, the end result can be predicted, so it is easy to detect such type of vulnerabilities automatically. As a matter of fact, these are the type of security checks an automated web vulnerability scanner uses when scanning your website for vulnerabilities. It tries to inject malicious code in website’s input parameters and depending on the response it determines if there is a vulnerability or not.

The above are just examples of vulnerabilities in their simplest forms. In a real life environment, web applications are much more complex and there are hundreds of variants for each vulnerability class, so it is much easier said than done. Though at least with the above you can get the gist of it.

Logical Vulnerabilities

Like technical vulnerabilities, there are several different types of logical vulnerabilities though not all can be classified under a specific vulnerability classes as per the below examples.

Access Control Logical Vulnerabilities

Access control is a very common logical vulnerability. Using an accountancy web application as an example where typically there are different user roles. For example users with the role of a chief financial officer have access to everything while accounts clerks should only have access to the financial transactions of their departments.

But what if because of a flaw in the design the web application allows the accounts clerks to see the financial records of each other’s’ departments? An automated tool will never be able to detect such a flaw because it does not have the knowledge to determine what a user with an accounts clerk role should be able to access or not.

In theory, you can configure a scanner to detect a number of logical vulnerabilities that are specific to your setup, but in practise it is not worth. It will take you hours to figure it out, and it would still be limited to a number of logical flaws.

Other Type of Logical Vulnerabilities

Unlike access control security issues, there are several other logical vulnerabilities that do not fall under a particular class or category. For example you want to buy a pair of shoes and notice that the web applications stores some values in the URL as per the below:

http://www.example.com/store/order.asp?itemid=4&price=50

What happens if you change the price to ten or one? Does the website still accept the order, which means you got a pair of shoes for $1? If it is so, the website’s logic is vulnerable and by exploiting it attackers can have a negative impact on the business. During a test, the scanner can change the value of the price parameter but it is not able to determine if that is a good or a bad thing.

Identifying Logical Vulnerabilities

In most cases, logical vulnerabilities can only be identified by seasoned professionals who are familiar with the scope of the web application and the industry your business operates in. Therefore, if you use third party consultants make sure you stick to the same ones if you’re happy with their job.

And the good thing is that the more they are exposed to your web application the better they will get at identifying logical vulnerabilities. On the other hand, someone who is new will not be able to determine who should have access to what,  even if they have the technical expertise.

Ensuring a Comprehensive Web Application Penetration Test

Automated tools cannot identify all types of vulnerabilities but neither can we. Automated scanners excel at doing the repetitive and at ensuring that every single attack surface is checked for thousands of different types of vulnerabilities, thus saving you ample of time. We humans have the upper hand, we are more intelligent but are prone to making mistakes. We get tired and forget things. Imagine having to manually test hundreds of parameters on a single web application. How long do you think it will take you? And how will you ensure that after you’ve been at it for hours, and most probably days you will not miss an attack surface?

Take advantage of the situation. Use automated tools. Use fast automated web application security scanners, that allow you to finish the job as quickly possible, so you have enough time to check for logical and other type of hairy vulnerabilities.