Security 101 - Unsanitised User Input

At Far Edge we've been working with a client who had a compromised website (not because of our software). He'd been blacklisted for sending spam among other things. After our sys-admin guys had tidied up the server itself, I was asked to take a look through the web application source code for security problems.

3 presented themselves.

  1. Insecure 3rd Party Components
  2. Unsanitised User Input
  3. Webserver not Running with Minimal Permissions

#2 - Unsanitised User Input

SQL injection (for MySQL and MSSQL) and XSS are dangerous and real.

You cannot trust user input. Anything that comes from a web browser via a URL query string, cookie, post variable, browser agent string, even IP address can be faked, manipulated and include stuff to do nasty things. (As a side note, you also need to escape any data displayed to a web browser to protect against XSS.)

This site had any number of SQL injection attacks waiting to happen. It was using php addslashes() and strip_tags(), but not for every input. Parameterised queries are the way to go here because they stop SQL injection for all inputs, without the developer thinking about anything. (And parameters are easier than concatenating your strings together anyway.)

Enough theory, the problem which I noticed within 15 minutes of inspecting the source code was this:

$action = $_GET['a'];

include() and include_once() are equivalent to exec() in php.

Browsing to this url rendered a badly broken page:

So I created a php file "malicious.php" with phpinfo() in it, and placed it in some strategic locations. The following urls executed the code:

Should I mention you can upload images to this site? And did you know they're stored in the "images" folder?

That's enough to run php you want on the site.

Security 101 - 3rd Party Components
Security 101 - Use Minimum Permissions

Related Posts


No comments made yet. Be the first to submit a comment
Mobile Version | Desktop Version