Jump to content


Check out our Community Blogs

Register and join over 40,000 other developers!


Recent Status Updates

View All Updates

Photo
- - - - -

Sql Injection and Phishing

bind_param

  • Please log in to reply
5 replies to this topic

#1 mutago

mutago

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 478 posts

Posted 23 September 2012 - 04:19 PM

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();


  • 0

#2 BlackRabbit

BlackRabbit

    CodeCall Legend

  • Expert Member
  • PipPipPipPipPipPipPipPip
  • 3871 posts
  • Location:Argentina
  • Programming Language:C, C++, C#, PHP, JavaScript, Transact-SQL, Bash, Others
  • Learning:Java, Others

Posted 23 September 2012 - 07:26 PM

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.
  • 0

#3 wim DC

wim DC

    Roar

  • Expert Member
  • PipPipPipPipPipPipPipPip
  • 2681 posts
  • Programming Language:Java, JavaScript, PL/SQL
  • Learning:Python

Posted 23 September 2012 - 10:49 PM

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?
  • 0

#4 gregwarner

gregwarner

    Obi Wan of Programming

  • Expert Member
  • PipPipPipPipPipPipPip
  • 1586 posts
  • Location:Arkansas
  • Programming Language:C, Java, C++, C#, PHP, Transact-SQL

Posted 24 September 2012 - 05:41 AM

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.
  • 0

ti-99-sig.png
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
– Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid


#5 mutago

mutago

    CC Devotee

  • Senior Member
  • PipPipPipPipPipPip
  • 478 posts

Posted 24 September 2012 - 01:46 PM

thanks
  • 0

#6 Upstream

Upstream

    CC Resident

  • Advanced Member
  • PipPipPipPip
  • 98 posts
  • Location:Netherlands
  • Programming Language:C, C++, PHP, (Visual) Basic, JavaScript, Perl, Bash, Others
  • Learning:Others

Posted 27 September 2012 - 06:07 AM


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;
}

  • 0
"The question of whether a computer can think is no more interesting than the question of whether a submarine can swim." (Edsger Dijkstra)





Also tagged with one or more of these keywords: bind_param

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download