Research company Imperva turned up this week with two known exploits, the researchers were able to execute any PHP code that they wanted — which means that they could also execute any command they wished, thanks to PHP’s backtick operators.

The really interesting part of the report was the use of these exploits from 2011 and 2010 in automated attack software. Below is an image from the report that shows an attack from one host over time that is targeting the manipulation of superglobals. It turns out that the host was an Italian bank that had likely been compromised, and the attacks continued after this graph was made.

I like this graph because it shows the burst nature of the attack, and it displays how just because a server may not be currently under attack, that does not mean the problem has gone away.

However, the root cause of the issues explored in the report are code blocks such as that below, which used to exist in the highly popular PhpMyAdmin tool.

if (strstr($_SERVER[‘QUERY_STRING’],’session_to_unset’) != false) { parse_str($_SERVER[‘QUERY_STRING’]); session_write_close(); session_id($session_to_unset); session_start(); $_SESSION = array(); session_write_close(); }

That a project of the age and popularity of PhpMyAdmin could have these basic errors just shows how insidious the disease of trusting user input is. It’s not done out of maliciousness, or even incompetence; it happens from not thinking about one of the basic tenets of security.

Never trust user input. Ever.

Your application could sit there for years working properly with a hole as big as a small European country, just waiting to be exploited. All it takes is one curious hacker — or, these days, one botnet — to latch onto your IP, and your precious code has just provided an on-ramp to a world of arbitrary code execution and persistent threats.

Many may be tempted to lay the blame for these exploits at the feet of PHP, but you could write similarly exploitable code in your scripting language of choice; it’s just that PHP is the most popular language on the web, and therefore it attracts most of the attacks.

There are ways to close such holes: Escaping the input and using input whitelists are but two ways to close such gaps.

The truths reinforced in the report remain universal regardless of which language you use: Never trust user input, and double down on never trusting parameters found in a URL.