We all know that vulnerabilities in web pages are quite common these days. They range from SQL injections, XSS vulnerabilities, CSRF, etc. In this article we’ll provide basic examples of the most common vulnerabilities you’ll find in web pages—including and especially WordPress. We’ll describe them in detail below.
1. DoS (Denial of Service)
The denial of service happens for various reasons, but we won’t describe anything like attackers trying to DoS a specific web site with a botnet of compromised computers, but we’ll rather describe how a DoS vulnerability can happen when writing a code.
Usually we have to make a logical mistake to create a DoS scenario in our web application. Let’s present such a scenario with a little PHP code. The code below is a PHP sample code that contains a logical error that can be exploited to cause a denial of service.
This effectively reads and displays the system file /etc/password that contains all the usernames on the system.
The file inclusion attack is very similar to directory traversal attack. The only difference is that with directory traversal attack, we can only read the file we’re not allowed to read, but with file inclusion we’re including the file into the current web page execution, thus executing the file we’re not allowed to execute.
We must know that there are two types of file inclusion attacks:
LFI (Local File Inclusion)
Here we’re including the local file into current execution. By local file we mean the file that is already present on the server’s system. The LFI attack is possible because the application doesn’t encapsulate the user inputted data.
RFI (Remote File Inclusion)
Here we’re including the remote file into current execution. This can happen if the application has an option to upload the file to the server’s filesystem. In such cases, we can upload the malicious file from our client to the server and execute it. With this attack, we can upload a malicious web shell onto the vulnerable application and obtain total control of the web server (under the context of the application’s user of course).
An example of a vulnerable code can be seen in the source code output below:
<?php if(empty($_GET['file'])) die('You didn\'t enter the name of the file.'); $file = getcwd().'/'.$_GET['file']; if(!file_exists($file)) die('The filename doesn\'t exist.'); include($file); ?>
In the above code we’re first checking whether the parameter file exists and contains a value. After that we’re constructing a whole path to the file we’re trying to read with the use of getcwd function that gets the current directory and appends it the value of the parameter p. At the end we’re including the file from the constructed path into the current execution of the web page.
The command injection vulnerability can be present in an application where the user inputted value can affect the command that gets executed on the server. An example of a vulnerable application written in PHP is as follows:
<html> <body> <?php if(empty($_GET['user'])) die('You didn\'t enter the name of the user.'); $user = $_GET['user']; system("id $user"); ?> </body> </html>
In the above code we’re first checking if the parameter user exists and if it does, we’re reading the value of that parameter into a local variable. After that we’re executing the command “id user” on the system. The vulnerability is present because the application doesn’t check the inputted value for special characters. Because of that we can execute a second command on the system if we pass a value like “root;ls -l /” in parameter user. The application will then execute the following command: “id root;ls -l /“. But because the ‘;’ is a separator between multiple commands, the application will actually execute two commands one after another, returning the result of both of them.
Privilege escalation attack is the attack where we’re using the logical error in the application to obtain privileges to do something we’re not supposed to do. This vulnerability often happens in applications that use multiple user roles like unauthorized user, authorized user, administrator, etc. It’s redundant to say that some user roles have more permissions than others. For example, the administrator should have the right to add other user accounts, while other user roles shouldn’t have that privilege. The vulnerability would then happen if the normal user could create new user accounts nevertheless.
We’ve seen that there are many vulnerabilities that we need to watch out for when programming a web based application. We looked at basic examples of most common vulnerabilities and explained them in detail to better present the vulnerabilities out there. This can be a reference of most common mistakes in web applications that web developers can study and use.