I feel silly for asking such a rookie question, and I tried searching but all I could find are sources that show how to do the escaping, which is not what I'm asking.
I am using PDO to add stuff to a database. As a result stuff gets escaped. The problem is, when I display that stuff back to the user it gets displayed exactly as it is in the db. In other words an escaped single quote displays as a left slash plus a single quote.
I could just run some sort of find/replace on all escaped character sequences but I am sure there most be a 'proper' way to do this. A way that remains secure (or improves security)
Then you're doing it wrong. SQL escaping is only done to properly insert into the database and not break SQL syntax, the values are stored in their unescaped form. Values only need to be escaped for their transition into the database, the values are never supposed to be altered permanently. Especially with PDO you shouldn't need any escaping at all.
Most likely you have magic quotes turned on, which causes double escapism. Please read this carefully: http://php.net/magic_quotes
use stripslashes
echo stripslashes($var);
http://php.net/manual/en/function.stripslashes.php
Related
I'm trying to update an old program that uses regular MySql queries, runs all the inputs through addslashes() prior to inserting them, and runs the retrieved data through stripslashes() before returning it. I'm trying to update the program to run with Mysqli and use prepared statements, but I'm not sure how to make the transition with the existing data in the database.
My first thought was to write a function to test if slashes have been added, but the general consensus in the answers to similar questions I found was that this isn't doable.
I'm trying to avoid doing a mass update to the database, because it's an open source program and this seems likely to potentially cause problems for existing users when they try to upgrade.
If I continue to use addslashes() prior to inserting using MySqli and prepared statements would this work? What would be the reasons for not doing it this way and instead going the full database upgrade route?
Edit:
Based on a comment that appears to be deleted now, I went and looked at the database directly. All I could find was an ' that had been converted to ' and no slashes. When I pulled out the data it came out fine without running stripslashes(). So do the added slashes just tell mysql to escape the data when it's inserted? Will all the data come out find if I remove the stripslashes()? If so what's the point of stripslashes()?
You have several questions:
If I continue to use addslashes() prior to inserting using mysqli_ and prepared statements would this work?
No, it would not: the added backslashes would then be stored in your database, which is not what you want. In prepared statements the provided arguments are taken literally as you pass them, as in that mechanism there is no more need to escape quotes.
What would be the reasons for not doing it this way and instead going the full database upgrade route?
See above.
So do the added slashes just tell MySql to escape the data when it's inserted?
The added slashes are interpreted when you embed a string literal in your SQL, as that necessarily is wrapped in quotes. For example:
$text = "My friend's wedding";
$sql = "INSERT INTO mytable VALUES ('$text')";
$result = mysqli_query($con, $sql);
The mysqli_query will fail, as the SQL statement that is passed to it looks like this:
INSERT INTO mytable VALUES ('My friend's wedding')
This is not valid SQL, as the middle quote ends the string literal, and so the s that follows is not considered part of the string any more. As the SQL engine does not understand the s (nor wedding and the dangling quote after it), it produces a syntax error. You can even see something is wrong in the way the syntax is highlighted in the above line.
So that is where addslashes() is (somewhat) useful:
$text = "My friend's wedding";
$text = addslashes($text);
$sql = "INSERT INTO mytable VALUES ('$text')";
$result = mysqli_query($con, $sql);
This will work because now the SQL statement sent to MySql looks like this:
INSERT INTO mytable VALUES ('My friend\'s wedding')
The backslash tells MySql that the quote that follows it has to be taken as a literal one, and not as the end of the string. MySql will not store the backslash itself, because it is only there to escape the quote (see list of escape sequences in the documentation).
So in your table you will get this content inserted:
My friend's wedding
Then:
Will all the data come out fine if I remove the stripslashes()?
Yes. In fact, it should never have been in your code in the first place, as it will negatively effect what you get when there truly are (intended!) backslashes in your data. You are maybe lucky that a backslash is a rare character in normal text. Apparently you have not found any backslash in your database data, so it probably did not badly affect you until now. It is an error to think that the addslashes() call during the saving of data had to be countered with a stripslashes() call while reading the data, because, again, MySql had already removed them while writing the data into the database.
If so what's the point of stripslashes()?
There is no point in the context of what you are doing. It only is useful if you have received somehow a string in which there are characters that have a backslash before them, and have the meaning to escape the next character when the string is used in some context. But since you only briefly have such strings (after calling addslashes()) and MySql interprets these escapes by removing the backslashes in the written data, you never again see that string with the additional backslashes.
Situations where you would need stripslashes() are very rare and very specific. For your scenario you don't need it.
When I use mysqli->real_escape_string and add a string value to the db such as "who's", it adds the string without modifying the quote in any way. When I check the db, the value within it is "who's".
When I do not use mysqli->real_escape_string and add a string with a single quote like "who's", it just doesn't get added to the database. It is nowhere to be found.
This isn't normal, is it?
Yes, it is. It's a little difficult to answer this question in any more detailed a way than that.
real_escape_string() only escapes the data so it can be safely used in a query, it doesn't modify it in any way. When you don't escape it, the query has a syntax error in it so it fails - and the data is not inserted.
However the safest way to escape your data is to use prepared statements.
It is normal, and correct. the real_escape_string allows your string to be added to the database (including the quote). Without it, the apostrophe is interfering with the SQL, thus likely throwing an error, and that's why it's "nowhere to be found".
What real_escape_string does is, it escapes necessary characters only while adding these in the database. So it's like escaping the same type of quote in a string in PHP, for example:
$str = 'We escape single quotes like in O\'Connor';
And the single quote (apostrophe) there is to prevent the code from breaking, but the string value does not actually contain it. Likewise…
INSERT INTO table (`name`) VALUES ('O\'Connor')
in this example the backslash will not be inserted in the row. This is for security reasons, of course. Check Hackipedia's page to see some possible cases.
Hoping this was what you were asking.
I have some pages that are stored in databases. For security purposes, all the pages is escaped before saved into the DB, but then when i print the page, the HTML-tags are still escaped. Like this
Link
Obviously, that doesn't work very well, so how do i unescape the pages?
I've tried with html_entity_decode without any success.
While data should be escaped before inserting it into the database, it shouldn't still be escaped when you take it out. The root cause of your problem is that it is being escaped twice between collection and examining it after it comes out of the database.
You should track down why it is being escaped twice and fix that.
That may leave the existing data broken though (it depends on if the data is being escaped twice on the way in or if it is being escaped on the way out of the database with magic_quotes_runtime). If so, you will need to clean it up. That form of escaping has nothing to do with HTML and can be reversed with stripslashes.
The clean up will look something like:
SELECT * from database_table
Create a prepared UPDATE statement to update a row
foreach row stripslashes on the data that was double escaped, pass the data to the prepared statement
Use stripslashes(): http://uk3.php.net/manual/en/function.stripslashes.php
Use stripslashes($str) for retrieve the content and remove slashes added during insert content into database.
thanks
mysql database input strings should always be escaped using mysql_real_escape_string() and when they come out, they should be unescaped using stripslashes().
for numbers like id's, those should be converted to integers using int() and then range checked: for instance, AUTO_INCREMENT columns like id's by default start with 1. so for a validation check on anything you get from $_GET[] or $_POST[], check that your int()'ed number is >= 1.
filter all your integers through int().
filter all your real numbers through doubleval(), unless you are working with monetary values and you have your own decimal number class - floating point can mangle money.
Firstly magic quotes & runtime are disabled correctly in php.ini, and confirmed by phpinfo().
PHP version: 5.3.4
MySQL version: 5.1.52
I'm only using mysql_real_escape_string on the data, after htmlspecialchars and a trim, that's all the data cleaning on the variable.
Yet, when I submit a single quote, the slash remains in the database.
When running mysql_query I'm using "' . $var . '", although in the past this hasn't changed anything (could be due to the double quotes?).
Any ideas? and please don't tell me about PDO/prepared statements, I'm aware of them and I have my reasons for doing it this way.
Thanks!
Code example (this is the only thing done to the data):
mysql_real_escape_string( htmlspecialchars( trim( $data ) ) );
I'm only use mysql_real_escape_string on the data, after htmlspecialchars and a trim, that's all the data cleaning on the variable.
No. Only use mysql_real_escape_string for storing data in the database. Don't mangle your data when you store it.
The function htmlspecialchars is used to encode a string to HTML (< becomes < etc.) and it should only be used for this purpose.
Perhaps the massively misguided, unhelpful and damaging option
magic_quotes_gpc
Has been enabled?
You can check that in the output of phpinfo(), but there's not a lot you can do if the server admin has enabled it globally without the ability to overrride.
I recommend checking if it's on (on every page of the app of course), and if so, causing the application to die quickly and painfully to ensure that you avoid data corruption (which chiefly manifests itself as the proliferation of backslashes you described).
Then go around to the server admin's house with a blunt weapon of your choice.
Hopefully you can do all this before your database becomes overrun with hoards of evil self-multiplying backslashes.
your storing procedure is correct. (altough htmlspecialchars and/or trim is probably not needed - but i dunno about your application)
from the information you are providing there is no reason to be seen for your problem.
the next debugging approach would then be remembering whatever else you may changed or has been changed on your system (maby you are using some 3rd party installation image?).
if that fails ie is left to wild guessing possible causes, for which i will offer a first one:
mysql could be running in NO_BACKSLASH_ESCAPES -mode, which would cause backlashes to be treated as regular characters.
furthermore it looks like you are wrapping your strings in double quotes, which would then insert a single quote - which usually gets escaped - straight into your database, preceded by a backslash.
it may very likely be also possible that - as you are wrapping your strings with double quotes inside your sql statements, which is not how it should be like and i am baffled you dont get a syntax violation error, you end up with some query like "john\'s house" which is caused by the single quote escaping from mysql_real_escape, which would be correct if you had your query correctly wrapped by single quotes.
which leads me to the question. do you get a syntax error (or an injected query) when trying to insert double quotes?
as for your comment. you could very well prepare statements with pdo and, then get the query string form it, and execute them using mysql functions. however i realise that this is no solution to your problem.
please also try putting your whole query in only one variable and print that out directly before executing it. then have a look at it and follow any wrong manipulation back operation by operation that is done to produce the string.
If you use double quotes within the SQL commands after escaping the data:
SELECT "1\'2"
then it will store and return the value as 1\'2 with the backslash still intact.
The proper syntax for SQL strings is using single quotes. That's what mysql_real_escape_string is escaping for. Else it would have to escape double quotes, whose usage however it is completely unaware of.
Use double quotes in PHP. Use single quotes for SQL. Rewrite your code like that:
$x = escapy($x);
$y = escapy($y);
sql_query("INSERT INTO tbl (x,y) VALUES ('$x', '$y')");
I just found out because someone had a ' in their last name and it caused the script to not update anything after that. What's the best way to make their last name safe of any potental damaging characters?
You should probably be using prepared statements if you're embedding the SQL to insert records into the DB in your logic. Among other things they will properly escape data values for you (as long as you use them consistently.)
You should use
print htmlentities("O'Brian",ENT_QUOTES);
before inserting into database, it will convert string to
O'Brian
so it is safe to store to database. Keep in mind that this function also escapes double quotes.
More info on escaping string.