Geek Answers Handbook

What SQL injection methods are not "destroyed" mysql_real_escape_string ();?

Is there a list of SQL injection methods that cannot be protected only with mysql_real_escape_string(); using utf8 encoding?

For an integer, I use intval(); Is it safe enough?

For those who think that I want to get a "textbook" to hack someone: "No, I will not." I just want to know how to make my applications more secure, and I want to know if they are 99% protected from hackers.

+4
source share
3 answers

If a valid database connection is mysql_real_escape_string() , mysql_real_escape_string() assumed to be safe for string data under any circumstances (with the rare exception described in this answer ).

However, nothing from the line fails:

 $id = mysql_real_escape_string($_GET["id"]); mysql_query("SELECT * FROM table WHERE id = $id");

still vulnerable because you don’t have to break out of line to add an extra command.

+3
source

There are not many sql injection methods. They are always due to the fact that the entrance is not sanitized and does not work properly. So, while mysql_real_escape_string() makes any string safe for inclusion in the database query, you should follow the following avoidance methods to protect your data and users from SQL injection.

  • Never connect to the database as a superuser or as the owner of the database. Use always-configured users with very limited privileges.
  • Check if the given input has the expected data type.
  • If the application expects numerical input, try checking the data with is_numeric() or just change its type using settype()
  • Specify each non-numeric value provided by the user that is passed to the database using the database row escape sequence function. Thus, mysql_real_escape_string() will make all rows safe for inclusion in the SQL query into the mysql database.
  • You can also learn how to use stored procedures and prepared statements, which are usually very safe but have different consequences.

See also: PHP page for SQL injection

+1
source

There are many things that cannot be protected by standard methods (e.g. string escaping, int casting), also depending on the version of software you are using. For example, utf-8 is a problem in itself, since as a small example (among many) you need to make sure that the request is valid utf-8 (or convert it to utf-8). Cm. .

As the fury of undead sites, I think that MySQL injection protection cannot be compressed into a single SO response, so I include these links as common starting points.

http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

Also: Search mysql injection utf8

0
source

More articles:


All Articles