5 replies to this topic

[mutago]

I hope this code sanitation will protect my form inputs against Sql Injection and Phishing

$book = mysql_real_escape_string($_POST["book"]);

$name = mysql_real_escape_string($_POST["name"]);

$order_a = rand(10000,50000);

$message='';

$stmt = $mysqli->stmt_init();

if($stmt->prepare("insert into record(book,name,order_a) VALUES (?, ?, ?)")) {

$stmt->bind_param('ssssis',$book,$name,$order_a);

 $stmt->execute();

 

    // Close statement object

    $stmt->close();

[BlackRabbit]

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

[wim DC]

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

Isn't all the SQL injection taken care of with prepared statements in php?

[gregwarner]

Isn't all the SQL injection taken care of with prepared statements in php?

I believe this is true. The OP shouldn't have to worry about any SQL injection attacks with the code he's written above.

From: http://php.net/manua...-statements.php

Bound variables will be escaped automatically by the server. The server inserts their escaped values at the appropriate places into the statement template before execution. A hint must be provided to the server for the type of bound variable, to create an appropriate conversion. See the mysqli_stmt_bind_param() function for more information.

So the OP doesn't need to call mysql_real_escape_string() at all. By doing so, you possibly end up with doubly-escaped characters. The calls to mysql_real_escape_string() should be left out entirely when using prepared statements.

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

Javascript validators and obfuscation will not protect against a packet reshape enroute. He still may want to add a little more validation serverside to make sure that the actual contents of the variables make sense in the context of his application, but since the above code is server side, no packet reshaping will ever successfully inject SQL, which is what the OP was concerned with.

[mutago]

thanks

[Upstream]

Isn't all the SQL injection taken care of with prepared statements in php?

I believe this is true. The OP shouldn't have to worry about any SQL injection attacks with the code he's written above.

From: http://php.net/manua...-statements.php

Bound variables will be escaped automatically by the server. The server inserts their escaped values at the appropriate places into the statement template before execution. A hint must be provided to the server for the type of bound variable, to create an appropriate conversion. See the mysqli_stmt_bind_param() function for more information.

So the OP doesn't need to call mysql_real_escape_string() at all. By doing so, you possibly end up with doubly-escaped characters. The calls to mysql_real_escape_string() should be left out entirely when using prepared statements.

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

Javascript validators and obfuscation will not protect against a packet reshape enroute. He still may want to add a little more validation serverside to make sure that the actual contents of the variables make sense in the context of his application, but since the above code is server side, no packet reshaping will ever successfully inject SQL, which is what the OP was concerned with.

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

Isn't all the SQL injection taken care of with prepared statements in php?

Yes that is true. I still

Isn't all the SQL injection taken care of with prepared statements in php?

I believe this is true. The OP shouldn't have to worry about any SQL injection attacks with the code he's written above.

From: http://php.net/manua...-statements.php

Bound variables will be escaped automatically by the server. The server inserts their escaped values at the appropriate places into the statement template before execution. A hint must be provided to the server for the type of bound variable, to create an appropriate conversion. See the mysqli_stmt_bind_param() function for more information.

So the OP doesn't need to call mysql_real_escape_string() at all. By doing so, you possibly end up with doubly-escaped characters. The calls to mysql_real_escape_string() should be left out entirely when using prepared statements.

Mutago,
If that code is server side then you are still receiving malversed string parameters as in book and name, cause those paremeters are generated in the html page and the added sql comes from an url intersection and reshape in the middle of its route to your server,
So what you can do is either jump the site to SSL or to add the protection in the page with javascript, obscuring the submit, changing the posted var names and maybe applying some codifcation or CRC to it.

Javascript validators and obfuscation will not protect against a packet reshape enroute. He still may want to add a little more validation serverside to make sure that the actual contents of the variables make sense in the context of his application, but since the above code is server side, no packet reshaping will ever successfully inject SQL, which is what the OP was concerned with.

I agree 100%. Also you could add a bit of code like this to check for invalid or suspicious input to create a security hook of some sort.

if (preg_match("/[;'\{\}\+\=\[\]\'\;\-\?\<\>\:\;\"\"\*\&\%\$\#\(\)]/", $_POST['book'], $matches)) {
	 $error = "illegal input ";
	 exit;
}