DETECTING injection by comparing POST vars to an array?

[deadonarrival]

I'm intending to do some sanitising of user input, and also logging of certain contents of text boxes.

 

Essentially I want to take the $_POST array, walk through the variables and see if certain keywords, such as JAVASCRIPT: <script> UPDATE INSERT SELECT DROP or any of a dozen other SQL/XSS related keywords.

 

Could anyone suggest a decent way of seeing if each word is in the variable, without using a dozen preg_match or similar functions for each variable?

 

Or rather, how would you go about it?

 

(Also, if anyone has any suggestions for words to check for, that'd be great)

[papaface]

Can you provide code as to how your POST vars are currently processed.

[deadonarrival]

they aren't, i'm retrofitting this sanitization/logging over someone elses script.

 

I'll pseudo what I think my method will be though

 

badwords = array(-some bad words such as update, select, javascript, session)

foreach(post variable as key->value)
{
key = sanitise(value)
if(the variable contains any of the bad words)
{
  insert the username, ip, script, field and value into the log table
}
}

 

I really just need to work out how to check if the variable contains any of the forbidden words in the array

[papaface]

Something like:

<?php
$badwords = array("f***","b******");
$string = "hello f*** you b******";
$parts = explode(" ",$string);

foreach($parts as $k => $v)
{
if(in_array($v,$badwords))
{
  echo "bad word detected: " . $v . "<br />";
}
}
?>

But there are much more complex examples out there.

[deadonarrival]

I thought of exploding it, but the problem is that there's nothing to say they'll leave the convenient spaces in...

 

Javascript, for example, can work with virtually no white spaces, and I've not tested it but I'd imagine SQL alllows UPDATE`table`SET`key`='val`WHERE`key`='val' Is the best thing to do a preg_match?

[papaface]

I'm not entirely sure what you're wanting to do.

Are you trying to prevent SQL injections?

If so, then you dont need to filter out words, all you have to do it have a good level of checking.

Why would someone use javascript?

All you have to do is use mysql_real_escape_string($str)

[deadonarrival]

No, I know how to prevent SQL injection, what I want to do is log attempts at it.

 

I'm helping a fella out with a website which was poorly coded to start with, and has been the victim of some sql injection. I'm in the process of finishing santitizing all user input, but he'd really like to find out who is doing it.

 

Simply, I want to check each submitted variable and see if it contains any of the keywords likely to be used during injection attacks - then log the information if it does. Then an admin can trawl through and see if any were actual directed attacks.

 

All I need is something to check if a given value contains one or more of an array of words.

 

Walk through the POST array, and see if any contain one of the bad things. If they do, store the username, IP etc to a log table in mysql. But it has to do it without worrying about the exact layout. I'm just looking for, for example, the word "UPDATE" anywhere within a string.

[DarkWater]

So you're saying that no one can say "UPDATE" or "Javascript"?  That's kind of ridiculous to a point.  You need to be secure without being intrusive.

[deadonarrival]

No, they can say it...

 

All I'm doing is making sure that they can't actually inject sql, and logging any instances where people do use one of those terms. If valid, the variable will be used as normal - but admins will hopefully be able to catch the people doing it, and find out where exactly they're targetting.

 

A quick glance down the list of logs will quickly show up any SQL statements. The fields aren't personal information such as personal messages, so there's no invasion of privacy. It's usually monetary values or short strings.

[discomatt]

Use mysql_real_escape_string and store the data as usual. Log user ids beside the data they enter in the table

 

Run a cron job twice a day searching through your database for query-like strings, or xss attacks. Email the results, and verify manually. You now know who dun it.