Web Security - Part 1 - Google Hacking

Doing security reviews from time to time of web applications you can find real beauties. You see GET variables in eval, system, include and all sorts of things you would not even imagine that could run live for years without anyone noticing it :- )

I dont really have great english nor writing skills but i thought i will try to write a few parts of the security article just to give something back to the community. Its not really rocket science nor my invention or discovery. Its just day and weeks and years spent working with web apps and reading here and there. What i hope is to write something you will enjoy and maybe put some new spin on some issues.

PHP display_errors => You will be Google-Hacked for sure

Displaying errors is one of worst things you can do for your security. The only worse thing could be making your web app open source. Display errors gives crucial information to anyone trying to hack your site. Lets take some example:

    $no = $_REQUEST['no'];
    $data = file_get_contents($no.'.php');
    // processing of template
    echo $data

Its naturally simplified example of how potentially dangerous code might look like. Important bit here is that guessing the file name will be much more difficult if hacker does not have server's feedback. Hacker can see links or forms on the site and try to put some random or incorrect values. Without errors being displayed it would be harder to hack the script and read files. Some security bugs are easy enough to figure out without seeing errors in other cases you need a bit of luck.

Displaying errors turned on will give away folder names, file name patterns, variables, configuration settings, connectivity to external sources and sometimes even passwords.

The worst case imaginable is website that has bugs and security holes and display errors :- )

With sites like that online its even possible to do 'Google Hack', hacking where people type specific strings in google to find broken or vuneralbe servers. One of shameful PHP APIS is PDOException. Open google and type Fatal error: Uncaught PDOException, now go a few pages deep and you will see tons of servers that are crashing on connection to the database. Pages will look like this:

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[08006] [7] could 
not connect to server: Connection refused (0x0000274D/10061) Is the server running on 
host "localhost" and accepting TCP/IP connections on port 5432?' in 
C:\aplicaciones\web\xxx.php:6 Stack trace: #0 C:\aplicaciones\web\xxx.php(6): 
PDO->__construct('pgsql:dbname=XXX', 'XXX', 'XXX') #1 {main} thrown in 
C:\aplicaciones\web\xxx.php on line 6

Now you have two options:
1. Site is still down. You write down credentials and wait for DB to go back up, then use login and pass to try to connect to the DB
2. Site is up but you can still see the cached version of the page with error on it. Use google cache to see the error even if the DB is already UP, use login credentials to connect to the db.

Security holes deep as an ocean

Can it get any worse? So now think of every server you have accessible to public and make sure it does not have display errors enabled on any virtual host.

You could argue that its not PDO's fault that db passwords can be googled out. Well i think its both PHP developers and app developers who should be ashamed. In normal situation you should never log nor display login/credit card details.

Using this 'gunshot' approach is really amazing! almost any error message you can come up with or copy from PHP forums will give you tons of sites that have it in pages' content. Its so effective just because of the millions of servers out there and limited human resources to actually keep then safe.

I still had no time to enable comments on my blog. Please mail me if you like/dislike my PHP security post. Most of all let me know if i made any mistake or forgot about anything important. Feedback is a great source of knowledge so do not hesitate.