I have always read that Magic Quotes do not stop SQL Injections at all but I am not able to understand why not! As an example, let's say we have the following query:
SELECT * FROM tablename
WHERE email='$x';
Now, if the user input makes $x=' OR 1=1 --, the query would be:
SELECT * FROM tablename
WHERE email='\' OR 1=1 --';
The backslash will be added by Magic Quotes with no damage done whatsoever!
Is there a way that I am not seeing where the user can bypass the Magic Quote insertions here?
The trick is usually to pass a binary value so that the backslash would become a part of valid multibyte character. Here is a blog post about it.
Related
I'm currently using PDO connection for perform some mysql queries and since I use the command $conn->prepare("HERE THE QUERY") I want to know how to format characters like quotes and double quotes.
When I have cases like this one:
$conn->prepare("SELECT * FROM ('SELECT DISTINCT (user_id) FROM table1')");
This is fine because in the nested SELECT there isn't a particular character that can cause problems. But how can we handle special cases like that?
Here a strange example (forget the mysql.. this is quite irrelevant, focus on the quotes situation) with quotes and double quote inside the nested SELECT:
$conn->prepare("SELECT * FROM ('SELECT user_id, CONCAT('[\"",GROUP_CONCAT(DISTINCT(cat) ORDER BY user_id DESC SEPARATOR "\",\""),"\"]') cat_grouped FROM table_1') select1");
What should be the right quotation mark syntax according to this example query? If i use ' instead of " when I prepare the query the problem is quite fixed, but I want to understand if there is a smart way to maintain the double quotes.
firstly I recommend using single quotes - they're faster :D
The main issue is using the same quotes with each other. Doing this causes pre-mature closing, and I'm sure you'd like to save that pre-mature embarrassment.
See in simple terms:
"string has star"ted"
As you can see, the first double quote the file gets to is the one after star. This closes the string after star, rendering the ted" in a fatal error.
What you want to do is escape the quotes that conflicts with the opening quote. Single quotes inside double quotes are fine, and vice versa.
Escape single quotes inside single quotes and double quotes inside double quotes - the rest should be ok to leave. Also I recommend using backticks for your mysql tables and fields to avoid some errors down the road if they deiced to add some new keyword that just so happens to match your table/field name
e.g.
if using single quotes:
$conn->prepare('SELECT * FROM table WHERE string_field = \'value\'');
if using double quotes:
$conn->prepare("SELECT * FROM table WHERE string_field = \"value\"");
if mixing:
$conn->prepare('SELECT * FROM table WHERE string_field = "value"');
\ is the escape character used for situations like this :)
The alternative is concatting strings:
$conn->prepare('SELECT * FROM table WHERE field = '. $foo);
so breaking it up, you declare string same was as usual with preferred quotes, then to add stuff to it, you use . to concat
Having followed some tips on escaping apostrophes I am getting an unexpected combination of escape characters in the resulting sql statement. The following rails 4 active record statement is run against 5.5.42-MariaDB:
User.where(["surname LIKE ?", "%#{params[:search]}%"])
Where
params[:search] = "O'Keefe"
A .to_sql generates
SELECT * FROM users WHERE surname LIKE '%O\\'Keefe%'
MySQL/MariaBD expects an apostrophe to be escaped as two single apostrophes '' , or with a single backslash \' so this results in a syntax error. I am looking for help to understand why two backslashes \\' are appearing, and for a solution that will maintain protection against SQL injection.
UPDATE
After further investigation following suggestions below, it appears as though the console .to_sql output SELECT * FROM users WHERE surname LIKE '%O\\'Keefe%' is not what is passed onto MySQL. It failed for me 'cos I simply copied the statement into a mysql console to test execution. There is some black magic on route to the database that converts the double backslash \\' into a valid mysql escape sequence.
So problem 1/2 solved
User.where(["surname LIKE ?", "%#{params[:search]}%"])
is valid syntax that correctly auto-escapes the user input string. But can anyone shed any light on the reason for the generation of the double backslash and how it is modified on its way to database execution?
Try this:
User.where(["surname LIKE ?", "%#{params[:search].gsub("'", "''")}%"])
http://dev.mysql.com/doc/refman/5.0/en/string-literals.html#character-escape-sequences
In a statement like this;
$sql = "SELECT distinct `term`,count(*) as count
FROM {$temp_table_name}
group by `term` order by count DESC";
What does using the back tick character (`) around the field name 'term' buy me?
Is the usage of back ticks for performance reasons? Or is it for some sort of a SQL injection protection?
Note: After I submit the question, I realized that the backtick character does not show around the field name 'term' - right here on stackoverflow.
I don't know of a way of making it appear here in the question body.
If term is mysql key word, you need to quote it by `, otherwise, it is not necessary.
Ps: distinct is not necessary in your case, because you group by it.
The back-tick is the 'official' identifier quote character.
http://dev.mysql.com/doc/refman/5.0/en/identifiers.html
It allows a wider array of characters in an identifier, as described on the linked documentation.
Backticks just allow the use of spaces or other alternate characters in field names.
I think it's already been pretty well explained here.
When We use a keyword as a table name,field-name in MySQL use backticks, or double-quotes when ANSI_QUOTES is enabled.Other wise it is not necessary.It is not releated to SQL injection protection
To prevent SQL injection, is it necessary to use mysql_real_escape_string(), when magic_quotes_gpc is on?
For some rare encodings, such as GBk - yes.
But you should revert it not for this reason. Magic quotes should be turned off anyway (and will be in the next PHP version). So, mysql_real_escape_string() is the only escape function is left. Note that it is not sql injection prevention function. Many many people don't understand this point: it's just a part of syntax. It must be used not to "protect" anything, but to assemble syntactically correct SQL query. And must be used every time you build your query, no matter where data come from. Sure it will protect you from SQL injections too, as a side effect.
Of course, mysql_real_escape_string() works only within quoted strings. So, if you do
$num=mysql_real_escape_string($num);
$sql="SELECT INTO table SET data=$num"; /BAD!!!
It will protect nothing.
If you going to use numbers unquoted, it must be cast to the proper type obligatory, like this:
$num=intval($num);
$sql="SELECT INTO table SET data=$num"; /GOOD
Keep in mind that mo make mysql_real_escape_string() works as intended, proper client encoding should be set, and it is possible only with mysql_set_charset() function, SET NAMES query will not set that.
If you want to get rid of all these complexities, you can use prepared statements, though you will need to switch your mysql driver to mysqli or PDO.
Please note that no proper syntax nor prepared statements would not help you with query parts other than literals. You can't escape Identifiers or operators. If you happen to use these parts dynamically, they must be hardcoded in your script, like this (for the ORDER BY clause):
$orders=array("name","price","qty");
$key=array_search($_GET['sort'],$orders));
$orderby=$orders[$key];
$query="SELECT * FROM `table` ORDER BY $orderby";
or this (WHERE clause)
$w=array();
if (!empty($_GET['rooms'])) $w[]="rooms='".mysql_real_escape_string($_GET['rooms'])."'";
if (!empty($_GET['space'])) $w[]="space='".mysql_real_escape_string($_GET['space'])."'";
if (!empty($_GET['max_price'])) $w[]="price < '".mysql_real_escape_string($_GET['max_price'])."'";
if (count($w)) $where="WHERE ".implode(' AND ',$w); else $where='';
$query="select * from table $where";
Looking at the documentation; http://php.net/manual/en/function.mysql-real-escape-string.php
Note: If magic_quotes_gpc is enabled, first apply stripslashes() to the data. Using this function on data which has already been escaped will escape the data twice.
You can check if magic_quotes_gpc is on, see example; http://php.net/manual/en/function.get-magic-quotes-gpc.php
yes its good practice to run all values that are going into your sql statement through the filter mysql_real_escape_string() its not just quotes that the filter is fixing.
it prevents injection attacks, see the example on the php manual for the method.
http://php.net/manual/en/function.mysql-real-escape-string.php
No and yes. If magic_quotes is turned on and mysql_real_escape_string is applied, then some escapes will be doubled, which results things like "It\'s an example." I saw on some forums. For best practices, you should disable magic_quotes and use mysql_real_escape_string all the time, or even better, use a DB abstraction library.
In postgresql, it's possible to use "Dollar-Quoted String Constants" to avoid escaping single quotes in constant strings:
Without Dollar-Quoted String Constants:
'Jeff''s table'
With Dollar-Quoted String Constants:
$$Jeff's table$$
Is there a MySQL equivalent?
On edit: I'm not looking for a way to sanitize inputs, I'm looking for a way to make queries that generate sql easier to read.
No, because it doesn't really work. An attacker just addes a pair of dollar signs to their injection attempt instead.
The correct way to handle this is a system that uses real query parameters, such that the parameter values are never substituted directly into a query string. This is also generally better for performance because the db can do a better job caching the execution plan you don't end up building string dynamically, which tends to be slow in modern languages.
Not having excess concatenation statements greatly improves the readability of the code, as well. Instead of this:
sql = "SELECT * FROM MyTable WHERE Column1=$$" + somevarialbe + "$$ AND Column2=$$" + OtherVariable";
it's just this:
sql = "SELECT * FROM MyTable wHERE Column1=#Value1 AND Column2=#Value2";
Hmm... Okay, I can see some limited utility for this feature now.
Imagine a ticket tracking system with a stored procedure to get open tickets. You might actually hard-code the literal 'open' into the where clause of the query. Not that this would be a good design — ticket status should be in a table with it's own key, so that you'd hardcode the key rather than the text. But it plants the seed for something valid and more-complicated.
You can enclose your string in double quotes instead, e.g.
"Jeff's table"
Note: If this doesn't work, it means that you've got ANSI_QUOTES SQL mode turned on. The MySQL docs say:
If the ANSI_QUOTES SQL mode is enabled, string literals can be quoted only within single quotation marks because a string quoted within double quotation marks is interpreted as an identifier.