Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to secure all my inputs to my database. I have written follow function:
function mysql_real_escape_array($t){
return array_map("mysql_real_escape_string",$t);
}
In a file which get loaded by all my php datas i have written:
$_POST=mysql_real_escape_array($_POST);
I think i dont have any disadvantages trough this dirty code and there is no malicious query possible. Or does somebody thinks, that is have any disadvantages trough this code?
Would be happy to hear some feedback. I know it is maybe not the best solution, but in this way i can never forget to escape something.
Thanks!
The only way to surely protect against injection is to use properly parameterized queries. All parameters to queries have vulnerabilities and must be properly escaped. This is not just to prevent malicious injection, but to prevent accidental injection. For example, you could have:
SELECT value FROM t1
$value = $result; //$value is now "o'connel"
// SQL error caused by apostrophe in string
SELECT col FROM t2 WHERE value = '$value'
You may consider this data safe because it is internal, but it can still cause a problem by not being properly escaped.
About overwriting $_POST, note that you can still get the raw post body as well as $_POST values from $_REQUEST, so there is no way to assure that your data is properly escaped. What's more is that mysql_real_escape_string may not have a valid mysql connection when you need to use it. This can cause problems and vulnerabilities. $_POST values can also be arrays, so your function would need to be recusive too.
It's much easier to forget all those considerations and use parameterized queries with PDO or mysqli. Note that using prepared statements is not enough in and of itself. You have to properly parameterize the queries.
Use Prepared Statements either via PDO or MySQLi. This is the only approach that is really secure and doesn't hurt performance.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to write custom queries using Sequelize, and as far as possible avoid potential issues with SQL Injection. My question is therefore if there exists a secure way of writing custom queries with inserted variables using Sequelize?
Sequelize escapes replacements, which avoids the problem at the heart of SQL injection attacks: unescaped strings. It also supports binding parameters when using SQLite or PostgreSQL, which alleviates the risk further by sending the parameters to the database separately to the query, as documented here:
Bind parameters are like replacements. Except replacements are escaped
and inserted into the query by sequelize before the query is sent to
the database, while bind parameters are sent to the database outside
the SQL query text. A query can have either bind parameters or
replacements.
Only SQLite and PostgreSQL support bind parameters. Other dialects
will insert them into the SQL query in the same way it is done for
replacements. Bind parameters are referred to by either $1, $2, ...
(numeric) or $key (alpha-numeric). This is independent of the dialect.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
If the database used by a server is something other than MySQL, say Mongo DB, then is it possible to execute SQL queries? In such cases how can we perform SQL injection?
I don't expect all the possible commands, but some basic commands if the app is using, say MongoDB.
Yes. This type of attack is possible with any data source which parses queries. In the case of MongoDB, the queries are written in JavaScript instead of SQL but if you build your query like this:
String query = "db.users.find({ age: " + request.getParameter("age") + " });"
then you open the database to similar kinds of attacks.
This is nosql injection, and it is possible.
https://www.owasp.org/index.php/Testing_for_NoSQL_injection
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Okay so basically I'm a little bit stumped. This question is regarding the JDBC driver. Basically we own a server that is hosted on this driver, and it's running MYSQL. We are using coldfusion as our language of choice. We have a GET parameter ?lang= and injecting the character '\' into it prompts the error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near and no other character causes this error. I am sort of worried here. Can anyone tell me how an attacker would approach an sql injection attack into this parameter? So I can understand how I can filter it because in my code I am properly filtering preg_match on \ character and yet I still get this error. How would I be able to inject this parameter? Can someone point me to a guide or something, or if it's even possible. Just so I can rest in piece assuming it's not. But anyhow if this information is necessary the mysql version is 5.1.30 and the exact driver name is MySQL-AB JDBC Driver. Thanks for taking your time to help me out!
\ can be an escape character in mysql.
For example, an attacker could use the \b sequence to delete portions of your query and rewrite with their own injected sql.
The most reliable way to prevent sql injection attacks is to use parametrized queries.
See also:
Mysql character escape sequences
Preventing Sql Injection in Java
Using prepared statements
Also be aware that in many databases (not absolutely sure about the JDBC/Mysql combination) it is also possible to "inject" a wildcard character into a sql LIKE clause, even with a parametrized query. "Injection" in this particular case is not always a problem - in fact, in many cases it may be exactly the desired behavior. However, it can be a problem, if for example, you were doing something horrid like SELECT * FROM Users WHERE UserName LIKE #userInput AND Password LIKE #passwordInput (which would allow anyone to log in simply by inputing the % wildcard character on the screen for both fields).
I have a bunch of perl CGIs that take params and use their values in various DBI mySql queries.
Is there any way that a malicious user can do harm (or steal data) from my system if I don't allow any user submitted values that contain the words select, insert, delete, or update to be used as parameters and as long as I wrap all the varchar user provided values in single quotes?
I realize this question is very similar to others asked, but the others all seem to point to various PHP solutions, and I'm not using PHP, so, please forgive the redundancy, or point me to an associated question that answers this specific question.
The correct way to handle this in Perl use to use placeholders in all your SQL queries. Passing user-supplied data via DBI placeholders will ensure that everything is properly quoted. (That doesn't guarantee that it's secure, of course, but it will prevent SQL injection.)
Use parameterized queries. Then the user input is not part of the command at all, which is the only reliable way to know the command won't be modified.
I have an application which would greatly benefit by using dynamic mysql queries in combination with mysql (mysqli) real escape string. If I ran all data received from the user through mysql real escape would it be just as secure as using mysql prepared statements?
Yes, but a qualified yes.
You need to properly escape 100% of the input. And you need to properly set character sets (If you're using the C API, you need to call the mysql_set_character_set() instead of SET NAMES). If you miss one tiny thing, you're vulnerable. So it's yes, as long as you do everything right...
And that's the reason a lot of people will recommend prepared queries. Not because they are any safer. But because they are more forgiving...
Definitely NO.
While question in the title is ambiguous and can be interpreted as "Are dynamic mysql queries with every it's part properly formatted..." and thus have a positive answer, the question in the body is not:
If I ran all data received from the user through mysql real escape would it be just as secure as using mysql prepared statements?
If you look to this question closer, you will understand that this is just a magic quotes incarnation! The very purpose of this disgraced, deprecated and removed feature is exactly to "run all user input through escape".
Everyone knows nowadays that magic quotes are bad. Why positive answer then?
Okay, it seems that it needs to be explained again, why bulk escaping is bad.
The root of the problem is a quite strong delusion, shared by almost every PHP user:
Everyone have a strange belief that escaping do something on "dangerous characters" (what are they?) making them "safe" (how?). Needless to say that it's but a complete rubbish.
The truth is:
Escaping do not "sanitize" anything.
Escaping has nothing to do with injections.
Escaping has nothing to do with user input.
Escaping is merely a string formatting and nothing else.
When you need it - you need it despite of injection possibility.
When you don't need it - it won't help against injection even a little.
Speaking of difference with prepared statements, there is at least one issue (which already mentioned many times under sql-injection tag):
a code like this
$clean = mysql_real_escape_string($_POST['some_dangerous_variable']);
$query = "SELECT * FROM someTable WHERE somevalue = $clean";
will help you NOT against injection.
Beause escaping is just a string formatting facility, not injection preventer by any means.
Go figure.
However, escaping have something in common with prepared statements:
Them both doesn't guarantee you from injection if
you are using it only against notorious "user input", not as a strict rule for the building ANY query, despite of data source.
in case you need to insert not data but identifier or a keyword.
To be safe in these circumstances, see my answer explaining FULL sql injection protection how-to
Long story short: you can consider yourself safe only if you make 2 essential corrections and one addition to your initial statement:
If I ran all data received from the user through mysql real escape and always enclose it in quotes (and, as ircmaxell mentioned, mysqli_set_charset() is used to make mysqli_real_escape string() actually do it's work (in such a rare occasion of using some odd encoding like GBK)) would it be just as secure as using mysql prepared statements?
Following these rules - yes, it would be as secure as native prepared statements.
I think #ircmaxell got it right on.
As a follow-up, be on the lookout for this kind of thing.
I used to do it all the time:
<?php
//sanitize the dangerous posted variable...
$clean = mysql_real_escape_string($_POST['some_dangerous_variable']);
//...and then forget to use it!
$query = "SELECT * FROM someTable WHERE somevalue = '{$_POST['some_dangerous_variable']}'";
?>
And when I say "used to do it", what I mean is that I eventually gave up and just started using prepared statements!