You are here:
  1. Home
  2. Blog
  3. Interwebs
  4. Spotting Insecure Scripts

Spotting Insecure Scripts

 |  Interwebs

With the current surge in “hackings” (or rather: script kiddies exploiting known holes to deface websites that don’t support their view on the war) I’ve been going through a lot of scripts to find common and easy to fix vulnerabilities. With my fingers crossed, and perhaps a naive hope that people don’t release scripts with massive holes anymore, I’ve been sorely disappointed.

I don’t want to give away names and details as of yet, because I’m waiting to hear back from a few script authors, but for those of you who’re worried, go through your scripts and look out for stuff like this:

  • INSERT INTO `table` VALUES ('$_POST[bla]', '$_POST[other-bla]') — this is a sign that data is being inserted into a database straight from the post superglobal array (i.e. straight from a form with no sanitisation)!
  • if (isset($_COOKIE['bla'])) { $loggedin = true; } — this means that the script only checks to see if the cookie exists, and not to see if it’s valid. A malicious user can create a cookie and be logged in without knowing any admin details.
  • include($_GET['x']); — without any checking or validation of $_GET['x'], all sorts of files can be included through the URL, including malicious scripts on other servers, sensitive data from below-root folders, etc.
  • echo $_POST['bla'] — all sorts of code could be placed in the field which is then echo-ed. Expect to have your pages broken, files destroyed, cookies stolen, etc.

If you see any of these things in your scripts, or bits of code you think aren’t safe, get rid of the script. A little inconvenience while you find a secure alternative is better than losing years worth of data because somebody fancied their chances as a “hacker”. Take this advice from someone who has lost their data on multiple occasions (and still probably doesn’t back up enough): me!

If you want to check the security of a chunk of code, feel free to paste it here (or better yet, in an email, as it’s less likely to be broken by my own security measures). If I don’t know what’s wrong with it, I know of several of my visitors with a greater knowledge of PHP security who will. I’ll also be able to help suggest alternatives to scripts you’re using based on my knowledge of them, where necessary.

Jem Turner jem@jemjabella.co.uk +44(0)7521056376

11 comments so far

  1. Julie said:

    Losing data sucks. No matter how pointless fanlistings are, losing several months of members is very frustrating. (5 minutes of this mac got me lost)

  2. Aravis said:

    I’m also curious about WordPress. Does the latest version have any security issues? Found a couple of bugs in the plugins myself, but nothing too big.

  3. King Echo said:

    Honestly, I don’t understand most of this stuff still. I’ve just begun making things myself, prior to that most everything was just done the plain old hard way by hand coding every bit of HTML. I still do not understand how dynamic includes are unsafe. They can pick up pages from other sites and run them? I do understand the post part, though. I used to be part of a blogging community where some people started coming by and inserting code into the comment forms and ruining peoples blogs. I, of course, was never cool enough to attract the attention.

  4. Jem said:

    That’s exactly it Echo – by leaving the dynamic includes open to everything, people can ‘pick up’ (as you put it) pages from other sites. This becomes a problem if a nasty person codes a page specifically to steal passwords or cookies/etc and then tries to include that file via the dynamic includes. (And I trust you fine, it’s my moderation that doesn’t – when you use a different name :P )

Follow on Instagram