Major Spam Problem

[leon_nerd]

I have a PHP based application running.

 

I have a messageboard in it. Earlier there was no security feature and I was getting lot of spams. Then I implemented the image verification to submit new threads and replies. But the spams still kept in coming. Then I changed the password of my database. But I still face the same problem. 

 

Now, I have few questions:

 

1.) How come even after implementing the Image text verification, spams are able to post themselves?  :-\

 

2.) Why the problem exists when I have changed the password of my database?  :-\

 

3.) Is this SQL Injection? Should I use sprintf while writing and executing queries?  ???

 

Please suggest me. Any urgent help will be highly appreciated.

 

Thanks,

Anurag

[kenrbnsn]

Without code it's hard to answer your questions.

 

Ken

[hitman6003]

1.) How come even after implementing the Image text verification, spams are able to post themselves?

 

Even the best CAPTCHA (arguable Google's) can be broken by OCR (optical character recognition), where a computer is able to recognize the characters in the image.

 

2.) Why the problem exists when I have changed the password of my database?

 

The spammers are not directly inserting into your database, rather they are most likely using the comments system to post them (I'm assuming you have a blog or something similar).

 

3.) Is this SQL Injection?

 

Probably not.  Generally speaking SQL injection is malicious...the attacker wants to cause damage, not post spam. 

 

Should I use sprintf while writing and executing queries?

 

Yes.  And use mysql_real_escape_string on all user input (e.g. anything in the $_POST array) that is used in a query).

 

You may want to use a service like Akismet to attempt to prevent spam from being posted to your website.  It is free (to my knowledge).

[Wolphie]

Take a look at this

 

http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs

[bluejay002]

well i havent used sprintf() for specifying queries... i did use mysql_real_escape_string().

 

just a newbie question (less than a year in experience), is it necessary to use sprintf() for queries? why or why not?

 

anyway, i dont usually use mysql_*()... instead i use mylsqi_*().

[Wolphie]

Not only does it make long queries shorter, most people (including myself) prefer not to inject variables directly into the query so therefore we use sprintf().

[kenrbnsn]

Not only does it make long queries shorter, most people (including myself) prefer not to inject variables directly into the query so therefore we use sprintf().

How does it make long queries shorter? The resultant length of the query string, whether done with concatenation, variable substitution, or sprintf should be the same.

 

The second part of your statement doesn't make much more sense than the first part. Please give examples of what you mean.

 

Ken

[leon_nerd]

Thanks a lot guys for your valuable replies. Let me try things out based on the suggestions given here and update you how it went .

[xyn]

on an SQL injection thing, mysql_real_escape_string() doesnt stop people inserting javascript... and executing it...

 

so i made a function to prevent sql injections by about 99.9%

<?
function secure_var($str,$lcase=false){
$str=(($lcase)?strtolower($str):$str); //lower string?
$str=strip_tags($str); //remove < and >; ie no html/javascript; bbcode is a good tool.
$str=stripslashes($str);//remove all slashes
$str=trim($str); //remove extra white spaces
$str=mysql_real_escape_string($str); //nobody can sql inject queries, and escape your query
return $str; //and thats now complete.
}
/* usage */
$user =$_POST['username']; (Admin ' --)
$user_b =secure_var($_POST['username']); (Admin ' --)
$user_c =secure_var($_POST['username'],true); (Admin ' --)

$sql ="select * from users_db_tbl where tbl_username ='$user' and tbl_password ='$password'";
//select * from users_db_tbl where tbl_username ='Admin' --' and tbl_password ='$password' #commented password...

$sql_b ="select * from users_db_tbl where tbl_username ='$user_b' and tbl_password ='$password_b'";
//select * from users_db_tbl where tbl_username ='Admin\' \\\-\\\-' and tbl_password ='$password' #something like this

and $user_c changes Admin -> admin...

 

Also back to your thread...

 

Capcha will work, as long as you use lines and stuff, to change the text, where as and OCR will still be unable to recognise the text, and humans can.

 

search google, or there is a capcha code at this address (I havent used it myself):

http://www.captcha.net/

[hitman6003]

on an SQL injection thing, mysql_real_escape_string() doesnt stop people inserting javascript

 

That's because inserting javascript is not SQL injection...the closest term I know is "cross site scripting".

 

Anyway, the reason for using sprintf is because it forces the data types to be what you want them to be.  In other words, if you have a query:

 

$int = 4;
$string = 'abc';

$query = "INSERT INTO tablename (intcolumn, charcolumn) VALUES (" . $int . ", '" . $string , "')";

 

You want to make sure that the values being inserted are treated as the correct data type...you want $int to be an integer and $string to be a string.  In the above example, if $int were actually a string, e.g. $int = 'four', then it would cause an SQL error when the query was executed.  You can get around this two ways:

 

Typecasting:

$int = 'abc';
$string = 4;

$query = "INSERT INTO tablename (intcolumn, charcolumn) VALUES (" . (int) $int . ", '" . (string) $string . "')";

 

Or using the printf functions:

$int = 'abc';
$string = 4;

$query = sprintf("INSERT INTO tablename (intcolumn, charcolumn) VALUES (%d, '%s')", $int, $string);

 

With either of the above solutions, the query would still be incorrect...the inserted data would not be what was intended("abc" converted to an integer doesn't produce 4), but an SQL error would not be generated, which helps prevent an attacker from gaining additional information about your database schema.

[bluejay002]

well, thats pretty informative... thanks.

 

anyway, one good thing to do, learnt from my less than a year experience (eheh ), turn off error display on the server to avoid any errors from being displayed and prepare a custom error page. eheh