Question says it all hopefully, if I check a variable returns true for is_numeric(), is it ok to put directly into the MySQL query, or do I need to apply standard escaping? I'm thinking null character, overflow exploits and stuff.
An ambiguous example would be:
if(is_numeric($_GET['user_id'])) {
mysql_query("SELECT * FROM `users` WHERE id = ".$_GET['user_id']);
}
The datatype in MySQL is INT().
The safest way in my opinion is to convert the user_id to an integer, if it's invalid it will return 0.
$user_id = (int) $_GET['user_id'];
if ($user_id > 0) {
mysql_query("SELECT * FROM `users` WHERE `id` = " . $user_id);
}
Considering that "10e3" is_numeric, no.
If you want numbers (as in, only digits), you'll have to check for ctype_digit (which would still break SQL for numbers like 0123) or cast the number to an int or float. If it's acceptable for the number to be something other than all digits, you'll need to apply the SQL safe escaping and quoting.
From http://php.net/manual/en/function.is-numeric.php:
Be careful when using is_numeric() to escape SQL strings. is_numeric('0123') returns true but 0123 without quotes cannot be inserted into SQL. PHP interprets 0123 without quotes as a literal octal number; but SQL just throws a syntax error.
Because the programm must be ready for variant for no-existing id this single row should be enough:
mysql_query(sprintf("SELECT * FROM `users` WHERE `id` = %d LIMIT 1",$_GET['user_id']));
Whatever what will not be a decimal number we pass inside the sprintf will be turned to decimal. The zero (~ bad input) has the same state as no existing id.
Saving condition and declaring extra variable.
Related
I have managed after a struggle to understand what is happening with the prepare placeholders. My only thought is that my table does not have a consistent element in it that I can use as a reference with the place holder.
There is a test column that I have used, but i do not intend on having it in my production plugin. The column is set to 0 for each entry, and I set the $test to 0. Thus my query has now started working. But this doesn't really make sense as a security feature unless it is dynamically calling something in reference to the results on the database. The examples I have seen around all rely on a set constant in their query, but I haven't got this unless I just add a constant entry in the database, but this seems silly.
$test = 0;
$result =
$wpdb->get_results( $wpdb->prepare
( "SELECT * FROM $my_noted_table_name WHERE id_can_view = %d ", $test));
Is there a better way of doing this?
Thanks in advance..
Let me explain what is happening.
The prepare is sanitizing the variable's value, inserting it where you specified the placeholder, and then formatting the SQL query. Then the returned SQL query string is processed by the $wpdb->get_results().
Step 1:
For this line of code:
$wpdb->prepare( "SELECT * FROM $my_noted_table_name WHERE id_can_view = %d", $test );
here's what is happening:
Sanitizes the variable's value $test
Replaces out the placeholder with the sanitized variable's value.
The database table name is extracted from your $my_noted_table_name variable.
Formats the SQL query
For the placeholder, %d means the value will be an integer. If it's a string, then use %s instead. Think about it in terms of using the PHP construct sprintf or printf.
d - the argument is treated as an integer, and presented as a (signed) decimal number.
s - the argument is treated as and presented as a string.
So, let's say your variable $test has a value of 100 assigned to it and the database table's name is countries. Then SQL query string then is:
"SELECT * FROM `countries` WHERE `id_can_view` = 100;"
See how $wpdb->prepare transformed your inputted string into a properly formatted SQL query?
You want to ALWAYS use $wpdb->prepare() to handle this process as it will protect your database.
I have a MYSQL database that has a table with a column (field1) of type TINYTEXT. The column contains values such as 010101 and 01010" etc… which are actually filenames.
When I query this table using PHP it seems to be deciding that this field is numeric and it thus strips off the leading zero. When I try to use this value as a filename of course it doesn't work.
I am extracting the data like this:
$sSQL = "SELECT * FROM images;";
$rsImageList = RunQuery($sSQL);
$iLoop = 0;
while (($iLoop <= 80) && ($aRow = mysql_fetch_array($rsImageList))) {
extract($aRow);
echo $field1;
$iLoop++;
}
How can I typecast the variable as a string type?
Mea culpa! I had managed to get duplicate data in my table, some entries with the leading zero missing already (thanks to Excel which I used to import the data) and some without. I was looking at the correct data but extracting the incorrect data. Moral of the story - test with only a couple of lines of data not 60!
Sorry for wasting everyone's time.
you can force by casting it to a string:
$var = "" . $aRow["column"];
You can use CAST() function to change it into string
$sSQL = "SELECT CAST(field1 AS CHAR) FROM images;";
Give it a try, I dont think its MySQL fault as you have defined it as TINYTEXT maybe its because extract() method.
i am using mysqlclient,
in one of my query, as shown below
sprintf (query, "select user from pcloud_session where id = '%s'", sid);
here some time this sid is with % sign in it like the example
2Cq%yo4i-ZrizGGQGQ71eJQ0
but when there is this % this query always fail, i think i have to escape this %, but how ?
i tried with \ and %% , but both of this not working, please help me here
UPDATE:
When using session.hash_bits_per_character = 6, in php session ,the default charset contains a character (comma) that will always be urlencoded(here it is %2C). This results in cookie values having this %2C in it, but session db having a comma instead of it. any idea about fixing this problem ?.. sorry for the confusion
Thanks
There's no need to escape a literal '%' in MySQL query text.
When you say the query "always fail", is it the call to the mysql_query function that is returning an error? Does it return a SQL Exception code, or is it just not returning the resultset (row) you expect?
For debugging, I suggest you echo out the contents of the query string, after the call to sprintf. We'd expect the contents of the string to be:
select user from pcloud_session where id = '2Cq%yo4i-ZrizGGQGQ71eJQ0'
And I don't see anything wrong with that SQL construct (assuming the id column exists in pcloud_session and is of character datatype. Even if id was defined as an integer type, that statement wouldn't normally throw an exception, the string literal would just be interpreted as integer value of 2.)
There should be no problem including a '%' literal into the target format of an sprintf. And there should be no problem including a '%' literal within MySQL query text.
(I'm assuming, of course, that sid is populated by a call to mysql_real_escape_string function.)
Again, I suggest you echo out the contents of query, following the call to sprintf. I also suggest you ensure that no other code is mucking with the contents of that string, and that is the actual string being passed as an argument to mysql_query function. (If you are using the mysql_real_query function, then make sure you are passing the correct length.)
UPDATE
Oxi said: "It does not return a SQL Exception code, it just does not return the result[set] I expect. I did print the query, it prints with % in it."
#Oxi
Here's a whole bunch of questions that might help you track down the problem.
Have you run a test of that query text from the mysql command line client, and does that return the row(s) you expect?
Is that id column defined as VARCHAR (or CHAR) with a length of (at least) 24 characters? Is the collation on the column set as case insensitive, or is it case sensitive?
show create table pcloud_session ;
(I don't see any characters in there that would cause a problem with characterset translation, although that could be a source of a problem, if your application is not matching the database charactarset encoding.)
Have you tested queries using a LIKE predicate against that id column?
SELECT id, user FROM pcloud_session WHERE id LIKE '2Cq\%yo4i-%' ESCAPE '\\'
ORDER BY id LIMIT 10 ;
SELECT id, user FROM pcloud_session WHERE id LIKE '2Cq%'
ORDER BY id LIMIT 10 ;
Are you getting no rows returned when you expect one row? Are you getting too many rows returned, or are you getting a different row than the one you expect?
That is an oddball value for an id column. At first, it looks almost as if the value is represented in a base-64 encoding, but it's not any standard encoding, since it includes the '%' and the '-' characters.
If you're going to do this in C without an interface library, you must use mysql_real_escape_string to do proper SQL escaping.
There shouldn't be anything intrinsically wrong with using '%inside of a string, though, as the only context in which it has meaning is either directly inprintftype functions or as an argument toLIKE` inside of MySQL.
This proves to be really annoying, but it's absolutely necessary. It's going to make your code a lot more complicated which is why using low-level MySQL in C is usually a bad idea. The C++ wrapper will give you a lot more support.
You really shouldn't escape the string yourself. The safest option is to let the MySQL API handle it for you.
For a string of maximum length n, start by allocating a string of length 2*n+1:
int sidLength = strlen(sid);
// worst-case, we need to escape every character, plus a byte for the ASCIIZ
int maxSafeSidLength = sidLength * 2 + 1;
char *safeSid = malloc(maxSafeSidLength);
// copy "sid" to "safeSid", escaping as appropriate
mysql_real_escape_string(mysql, safeSid, sid, sidLength);
// build the query
// ...
free(safeSid);
There's a longer example at the mysql_real_escape_string page on dev.mysql.com, in which they build the entire query string, but the above approach should work for supplying safeSid to sprintf.
I have the following data:
stockcode (CHAR) | description (VARCHAR)
----------------------------------------------
1234 | some product
01234 | some other product
I run the following code:
$sql = "SELECT * FROM stock WHERE stockcode = " . $db->quoteSmart($stockcode)
$res = $db->query($sql);
If I pass the stock code "01234" in, I get the second row as expected. If I pass in "1234" I get both rows, when I expect to only get the first.
By echoing out the sql statements, it seems to be because only the 01234 stockcode gets quotes around it, the 1234 one doesn't (presumably quoteSmart thinks as it is an integer it doesn't need quoting?).
Mysql is then comparing the int 1234 to the CHAR column, and deciding they both match (presumably it is doing the comparison as ints?)
There are a lot of places in the code which build queries like this, and 99% of the time, the stockcode variable will be alphanumeric, it's only occasionaly entirely numeric, and very rarely contains a leading zero, this is just a fluke occurrence I stumbled across today.
Can anyone recomend an easy solution?
Try explicitly casting your variables to strings:
$db->quoteSmart((string)$stockcode);
// instead of:
// $db->quoteSmart($stockcode);
Edit:
If this does not work, I imagine that quoteSmart() isn't really that smart (or it's trying to be too smart for it's own good), so you'll very likely need to stop using it and stick to bound parameters (which I suggest over this method anyway).
Add quotes so the char in the database don't get converted to numbers for the comparison
$sql = "SELECT * FROM stock
WHERE stockcode = '" . $db->quoteSmart($stockcode). "'"
2nd Version:
$stockcode_str = $db->quoteSmart($stockcode);
if (is_numeric($stockcode_str))
$stockcode_str = "'$stockcode_str'";
$sql = "SELECT * FROM stock
WHERE stockcode = $stockcode_str";
I just discovered this, I use MySQL as my database.
When i do something like:
$query = $this->db->where('id', '6rubbish')->get('posts', 1);
it generates and executes this SQL:
SELECT *
FROM (`posts`)
WHERE `id` = '6rubbish'
LIMIT 1
The surprising thing is that it actually fetches the post with the ID 6.
I find this very vulnerable in same cases because i'm trying to exactly match the ID, not to do a LIKE query.
Any ideas?
Yes.
Read Type Conversion in Expression Evaluation
Use intval() PHP function to extract the integer part of the variable
Or use is_int to exclude any variable that is not a pure integer
But the origin of the problem is that your query generator library doesn't understand the variable types, PHP being a dynamic typed language doesn't help too.
I don't know what library you're using, maybe there is an option to tell that you're passing an int? It should protect you from SQL injection, I hope, try with:
$query = $this->db->where('id', "don't")->get('posts', 1);
and see if the generated SQL has the single quoted escaped (doubled or preceded by backslash).
That is because SELECT 6 = '6rubbish' will give you true, and your id is number type.
Your id field is, no doubt, a numeric data type.
When MySQL evaluates expressions, it converts operands to compatible types (see docs).
'6rubbish' (a string) gets converted to 6 (a number) and, hence, you get a match.