This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 9 years ago.
I have been fussing around with my PHP code and SQL statements and while I do know that one could use prepared statements when dealing with this, I still wonder how a SQL injection could be performed here.
$name = mysql_real_escape_string(htmlspecialchars($_POST["Name"]));
$age = (int) mysql_real_escape_string(htmlspecialchars($_POST["Age"]));
$amount = (int) mysql_real_escape_string($_POST["Amount"]);
$sql = "insert into nice_table set
name='{$name}',
age='{$age}',
amount='{$amount}'";
$db->sql_query($sql);
I don't know a lot about all different methods when performing a SQL injection, but all the stuff I've looked up passes just fine through this without any database errors. Would it actually be safe to use this instead of the classic prepared statements?
What would be passed right through, for example? I must be missing something, because it can't be this simple and still hold as tight as prepared statements, right?
mysql_real_escape_string ALONE can't prevent all type of SQL Injection.
Whenever you need escaping, you need it despite of "security", but just because it is required by SQL syntax. And where you don't need it, escaping won't help you even a bit.
The usage of this function is simple: when you have to use a quoted string in the query, you have to escape it's contents. Not because of some imaginary "malicious users", but merely to escape these quotes that were used to delimit a string. This is extremely simple rule, yet extremely mistaken by PHP folks.
This is just syntax related function, not security related.
Depending on this function in security matters, believing that it will "secure your database against malicious users" WILL lead you to injection.
A conclusion that you can make yourself:
No, this function is not enough.
Prepared statements is not a silver bullet too. It covers your back for only half of possible cases. See the important addition I made to the famous question for the details
mysql_ functions are deprecated. Preffer mysqli or pdo classes.
And AFAIK, it is possible to use special characters to avoid mysql_real_escape_string.
I would preffer to use prepared statements and validation. You probably wants only alfanumerics and dot to be possible inputs on name. That would help too :P
No, you are using mysql_real_escape_string() properly, so this will be safe.
For the latter two variables, you could also do
$age = intval($_POST["Age"]);
$amount = intval($_POST["Amount"]);
and that will be just as safe. Intval always returns an integer (0 on error), so it's impossible to contain any not-mysql-safe characters.
Related
This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 6 years ago.
I'm starting to think about protecting my inputs from SQL injection. I've read about PDO and mysqli and will be using those techniques. While I was researching protection against SQL injection, I had a thought about a technique. Whenever I have an input from a user, I could scan the input string and search for occurrences of "'" or "DROP" and if the string contains those characters, then I could just not proceed. Would this technique prevent a lot of SQL injection?
Thanks for your help.
It is best to go with methods which have gone through rigorous testing before hand, and not try to implement your own.
A problem with your desired solution is, what happens when SQL add a new notation for dropping tables? Or what if they use 'truncate' instead? This is not foolproof.
Just use PDO or SQLi.
If used correctly and as intended, both will stop it; it'd be silly to use a measure like stopping the word DROP -- Imagine if someone types 'dropbox,' for example?
You should escape your input, and consider using prepared statements. This will remove nearly all SQL injection weaknesses. Scanning for specific words is a terrible practice, as it generally annoys legit users, and doesn't stop determined hackers.
Try to use only prepared statement. It one of the best technique ever.
http://php.net/manual/pt_BR/pdo.prepared-statements.php
The best way is to validate all user input against strict patterns to ensure no user data is abnormal, along with PDO prepared statements - this way you may also prevent XSS however it is usually beneficial to sanitize all user generated output as well just in case you didn't properly validate something and a user is able to execute malicious code.
Possible Duplicate:
SQL injection that gets around mysql_real_escape_string()
I havent seen any valuabe or not outdated info on this.
So, there is this question: Does mysql_real_escape_string() FULLY protect against SQL injection? Yet it is very outdated(its from '09), so as of php 5.3 and mysql 5.5 in '12, does it protect fully ?
mysql_real_escape_string ALONE can prevent nothing.
Moreover, this function has nothing to do with injections at all.
Whenever you need escaping, you need it despite of "security", but just because it is required by SQL syntax. And where you don't need it, escaping won't help you even a bit.
The usage of this function is simple: when you have to use a quoted string in the query, you have to escape it's contents. Not because of some imaginary "malicious users", but merely to escape these quotes that were used to delimit a string. This is extremely simple rule, yet extremely mistaken by PHP folks.
This is just syntax related function, not security related.
Depending on this function in security matters, believing that it will "secure your database against malicious users" WILL lead you to injection.
A conclusion that you can make yourself:
No, this function is not enough.
Prepared statements is not a silver bullet too. It covers your back for only half of possible cases. See the important addition I made to the famous question for the details
long time since I read a blog post about this so it may no longer hold true BUT...
The posts stated that if you had unicode encoded characters in your string they would be missed by real escape string but would be evaluated by mysql engine - alluding to the idea that you could indeed still be open to a well placed injection.
I can't remember the blog post but this question on here is in the same ball-park.
Yes. By properly escaping the string using the native mysql escape functions, it's not possible to "break out" and execute a query.
However, a better approach would be to use prepared statements. This will do a number of things. By using prepared statements you take advantage of even more optimization from the database and it will properly escape any data passed in. Take a look at: http://php.net/manual/en/mysqli.prepare.php
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Best way to stop SQL Injection in PHP
MySQL injection protection and vulnerability signs using PHP
Hey i asked a question about my code if its vulnerable to sql injection
The code was this :
$searchData = $_POST['searchData'];
$searchResult = mysql_query("SELECT * FROM songs WHERE songname LIKE '$searchData%' ");
echo $searchResult;
And yess everyone answered that it is ... but i wanted some extra help on how to protect this kind of input from sql injection.
I read about mysql_real_escpape_string addslashes etc. But im confues which is the best one ?
Shoud i combine them ... or how should i structure my code to protect the input
Anyone helpin me with the best solution would be very apercciated.
The best approach is not to mess about with escaping at all; use bound parameters. See e.g. the PHP manual on PDO.
An example:
<?php
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (?, ?)");
$stuff = array('one', 1);
$stmt->execute($stuff);
$stuff = array('two', 2);
$stmt->execute($stuff);
?>
I highly recommend a short book called Essential PHP Security by Chris Shiflett (by O'Reilly) because you are asking a question that has many aspects that need to be covered. SQL Injection protection starts from the HTML all the way to the database with several steps in between to make sure your data is protected from injection.
Short answer: mysql_real_escape_string
Longer answer: prepared statements (using PDO or MySQLi)
Longer-er answer: When possible you should use prepared statements with bound parameters (as Oli Charlesworth said), however, the second best option is to use the escaping mechanism specific to a specific RDBMS. In this case, you would use mysql_real_escape_string instead of addslashes. mysql_real_escape_string is aware of a few things that addslashes is not. addslashes is a glorified str_replace of ' with \'. mysql_real_escape_string is a hook into the MySQL client library's mysql_real_escape_string function. It is aware of a few settings on the server (hence the connection parameter to it), and it is safer than addslashes.
Bound parameters are still safer though. Even though mysql_real_escape_string knows a lot about the connection and so on, a lot of factors can contribute to the security of it. For example, character sets and encodings can be difficult to handle. Bound parameters have a different method of operation, and they do not do escaping like normal queries. As such, they are safer as there is less room for error on things like character encoding and what not.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What does mysql_real_escape_string() do that addslashes() doesn't?
If not, I have used mysql_escape_string, and it adds characters to the words like \r\n, and I don't want that..
No, it's not safe. Use mysql_real_escape_string() instead. It shouldn't add anything beyond what it takes to escape the string.
http://php.net/mysql-real-escape-string
This applies to other databases too: use the extension-specific escape function.
No, addslashes is not good enough. mysql_escape_string is not necessarily good enough. Use mysql_real_escape_string.
Whether you like what it adds or not doesn't matter, it only escapes characters to make sure the query syntax is valid. If this gets in the way of what you're doing, you're doing something wrong.
The best way to prevent SQL injection is to use prepared statement with either mysqli or PDO.
You also have the option of using the mysqli functions and Prepared Statements. This largely avoids the problem in the first place because all quotes are considered part of the data.
This question already has an answer here:
Is mysql_real_escape_string() necessary when using prepared statements?
(1 answer)
Closed 3 months ago.
I'm currently using the mysqli php extension.
Traditionally I have used mysqli_real_escape_string to escape user input. However I am looking at changing over the code (hopefully in as few steps as possible) to use prepared statements.
I want to be clear on this - provided I use prepared statements to bind all of my variables, can I be confident that sql injection is impossible? (And dispense completely with mysqli_real_escape_string?)
Thanks
If you correctly bind all your variables you can dramatically reduce the risk of SQL injection. It is still possible to get an SQL injection if you create SQL dynamically for example:
'SELECT * FROM ' . $tablename . ' WHERE id = ?'
But if you avoid things like this it is unlikely you will have problems.
Speaking of security, there is no difference between both methods, if you correctly bind or format your variables.
Binding is just simpler, because it can be used just for any case, while escaping can't (so, you have to cast some variables instead of escaping/quoting).
Also, bear in mind that no binding nor escaping can make identifier safe. So, if you have to use a field name or operator in your query, you have to use a value, hardcoded in your script.
Here's my high-level view on the topic.
When using dynamic SQL strings, you are relying on the escaping function working correctly. Unfortunately, this is not always the case, as can be seen in this (admittedly old) example:
http://dev.mysql.com/doc/refman/5.0/en/news-5-0-22.html
Once your data values have been escaped, the SQL string has to be parsed and compiled by the database server. If the escaping function has not done its job properly, or a clever new SQL injection attack has been discovered, there is a chance that the server will mistake data for SQL statements.
If you use prepared statements with parameters, the statement is first parsed and compiled. The data values are combined with the compiled statement when it is executed. This separates the SQL logic from the data values - the opportunity to confuse the two should never occur.
So, yes, you can dispense with mysqli_real_escape_string, but I would not go so far as to say that using prepared statements with parameters makes SQL injection impossible. It makes it significantly harder, but as with the mysqli_real_escape_string bug, I guess there's always the chance that a yet to be discovered (or newly created) bug will make the seemingly impossible, possible.