+- Sinisterly (https://sinister.ly)
+-- Forum: Hacking (https://sinister.ly/Forum-Hacking)
+--- Forum: Website & Server Hacking (https://sinister.ly/Forum-Website-Server-Hacking)
+--- Thread: Web vulnerabilities - part 1 - DOS + preventing advice (/Thread-Web-vulnerabilities-part-1-DOS-preventing-advice)
Web vulnerabilities - part 1 - DOS + preventing advice - unixbreak - 11-18-2012
1. DoS (Denial of Service) for today
The denial of service happens for various reasons, but I won’t describe anything like attackers trying to DoS a specific web site with a botnet of compromised computers, but I’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.
PHP Code:
<?php
if(empty($_GET['file']))
die('You didn\'t enter the file parameter.');
$file = $_GET['file'];
if(!file_exists($file))
die('The chosen file does not exist.');
include($file);
?>In the above code, we’re first checking whether the file parameter exists. If yes, we’re reading the value stored in the file parameter, otherwise we’re closing the application with an error message that says that we didn’t enter the file parameter. Thus, we have to provide the file parameter in order to continue execution of the application. After that, we’re reading the value stored in the file parameter and checking whether the file exists. If it doesn’t, we’re again closing the application with an error message about a non-existent file. But if a file does exist, we’re including it into the current application execution. From the above code it’s not instantly evident that the code contains a vulnerability that can result in a denial of service.
Let’s say that we saved the above code as index.php and we’re supplying a value of “testing.php” in a fileparameter. In such a scenario everything works fine as long as the testing.php file exists and does some work. But what happens if we provide index.php as a value for the file parameter. In such a case, the index.php file is including itself into the current execution, and this happens infinitely, resulting in a denial of service. By default, the operating system allocates just so much memory to each application, and if that application wants more memory, it is usually forcibly closed by the operating system. This is exactly what happens in this case. When the index.php allocates as much memory as permitted, the operating system forcibly closes it.
A popular mistake is to write code that results in URLs like this:
Quote:www.example.com/article.php?file=aboutus.php
www.example.com/article.php?file=products.php
www.example.com/article.php?file=legal.php
The code for article.php will read in the $_GET['file'] variable, then include() the necessary file into the script. This might make sense at first, but consider what happens if a clever use modified the URL to this:
Quote:www.example.com/article.php?file=article.php
What will happen is that article.php will load, then include()article.php, which will load, then include()article.php, which will load, then... and so on. This will continue going on and on until your server hits the maximum execution time for a script and terminates. However, during this time your web server will be performing large amounts of unnecessary work, and will be slower for other clients connecting to it.
Now consider what would happen if that same malicious user loaded that URL three times quickly - or thirty. From that, consider what would happen if that user loaded the URL three thousand times - nothing difficult, considering that can be handled even with a slow connection. At three thousand almost-simultaneous connections, even a normal web server would have trouble coping. However, if each of those three thousand resulted in a CPU-consuming infinite include() loop, the server would simply stop responding to new requests and may well even crash.
If you are think three thousand pages is too much for just one client to handle, think again - HTTP has a special access method called "HEAD" that sends a request to the server, makes the server process the page fully, then returns only the header information of the page - this is usually only around 100 bytes. Three thousand times 100 bytes is three hundred thousand bytes, or 300 kilobytes - well within the reach of even lowly modem users.
The moral of the story is that you should always keep in mind the possibility that malicious users may use your own code against you. The most obvious solution to the problem detailed here is not include files based upon a variable, but if that is not possible then at least consider using
PHP Code:
include_once()