This question already has answers here:
How to escape strings in SQL Server using PHP?
(14 answers)
Closed 7 years ago.
Am wondering what is the equivalent in PHP for SQL Server escaping of strings?
Nice question, I don't know but you could use PDO::quote() with the PDO_DBLIB driver.
EDIT: Seems like this guy got it from StackOverflow:
function mssql_escape($data) {
if(is_numeric($data))
return $data;
$unpacked = unpack('H*hex', $data);
return '0x' . $unpacked['hex'];
}
Another option:
function mssql_escape($str)
{
if(get_magic_quotes_gpc())
{
$str= stripslashes($str);
}
return str_replace("'", "''", $str);
}
The best alternative is to use parameterised queries, then you don't have to escape strings.
If you still want to put the query together yourself, the proper way to escape a string literal for SQL Server (T-SQL) is to replace each apostrophe (') in the string with two apostrophes.
The short answer is: use whatever mechanism your connection libraries provide, it really has nothing to do with the database. If you're using ADO, you have parameterized queries, if you're using something else (I know nothing about PHP) then use whatever that library offers.
Rolling your own is probably a bad idea, because you're very likely to get something wrong, e.g. handling comment delimiters correctly.
Related
I'm quite confused now and would like to know, if you could clear things up for me.
After the lateste Anon/Lulsec attacks, i was questioning my php/mysql security.
So, i thought, how could I protect both, PHP and Mysql.
Question: Could anyone explain me, what's best practice to handle PHP and Mysql when it comes to quotes?
Especially in forms, I would need some kind of htmlspecialchars in order to protect the html, correct?
Can PHP be exploitet at all with a form? Is there any kind of protection needed?
Should I use real_escape_string just before a query? Would it be wrong/bad to use it already within PHP (see sanitize_post function)?
Currently i'm using the following function. The function "sanitizes" all $_POST and $_GET variables. Is this "safe"?
function sanitize_post($array) {
global $db;
if(is_array($array)) {
foreach($array as $key=>$value) {
if(is_array($array[$key])) {
$array[$key] = sanitize_post($array[$key]);
} elseif(is_string($array[$key])) {
$array[$key] = $db->real_escape_string(strtr(stripslashes(trim($array[$key])), array("'" => '', '"' => '')));
}
}
} elseif(is_string($array)) {
$array = $db->real_escape_string(strtr(stripslashes(trim($array)), array("'" => '', '"' => '')));
}
return $array;
}
I'm using PHP 5.3.5 with Mysql 5.1.54.
Thanks.
mysql_real_escape_string deserves your attention.
However direct queries are a quagmire and no longer considered safe practice. You should read up on PDO prepared statements and binding parameters which has a side benefit of quoting, escaping, etc. built-in.
BEST practice is always to use prepared statements. This makes SQL injection impossible. This is done with either PDO or mysqli. Forget about all the mysql_* functions. They are old and obsolete.
Question: Could anyone explain me, what's best practice to handle PHP
and Mysql when it comes to quotes?
That's easy: Use prepared statements, e. g. with PDO::prepare or mysqli_prepare.
There is nothing like "universal sanitization". Let's call it just quoting, because that's what its all about.
When quoting, you always quote text for some particular output, like:
string value for mysql query
like expression for mysql query
html code
json
mysql regular expression
php regular expression
For each case, you need different quoting, because each usage is present within different syntax context. This also implies that the quoting shouldn't be made at the input into PHP, but at the particular output! Which is the reason why features like magic_quotes_gpc are broken (always assure it is switched off!!!).
So, what methods would one use for quoting in these particular cases? (Feel free to correct me, there might be more modern methods, but these are working for me)
mysql_real_escape_string($str)
mysql_real_escape_string(addcslashes($str, "%_"))
htmlspecialchars($str)
json_encode() - only for utf8! I use my function for iso-8859-2
mysql_real_escape_string(addcslashes($str, '^.[]$()|*+?{}')) - you cannot use preg_quote in this case because backslash would be escaped two times!
preg_quote()
Don't waste the effort using mysql_real_escape_string() or anything like that. Just use prepared statements with PDO and SQL injection is impossible.
I usually use the PHP functions stripslashes and strip_tags on the variables as they come in via $_POST (or $_GET, depending on what you use) and mysql_real_escape_string during the query. (I'm not sure if this is "right" but it's worked for me so far.) You can also use PHP's built in validate filters to check things like email addresses, url's, data types, etc. PDO is supposedly decent at preventing SQL injection but I haven't had any experience with it yet.
The basic workflow should be
$data = $_POST['somefield which will go into the database'];
... do data validation ...
if (everything ok) {
$escaped_data = escape_function($data);
$sql = " ... query here with $escaped_data ... ";
do_query($sql);
}
Basically, data that's been escaped for database insertion should ONLY be used for database insertion. There's no point in pre-processing everything and overwriting all data with db-escaped values, when only 2 or 3 of 50(say) values actually go anywhere near the db.
Ditto for htmlspecialchars. Don't send data through htmlspecialchars unless it's headed for an HTML-type display.
Don't store data in the DB formatted for one particular purpose, because if you ever need the data in a different form for some other purpose, you have to undo the escaping. Always store raw/unformatted data in the db. And note: the escaping done with mysql_real_escape_string() and company does not actually get stored in the db. It's there only to make sure the data gets into the database SAFELY. What's actually stored in the db is the raw unescaped/unquoted data. Once it's in the database, it's "safe".
e.g. consider the escaping functions as handcuffs on a prisoner being transferred. While the prisoner is inside either jail, cuffs are not needed.
This question already has answers here:
How can I prevent SQL injection in PHP?
(27 answers)
Closed 6 years ago.
I'm building a MVC application for managing a creative portfolio (Going to put it on git hub). I need something to secure the DB connections, basically I have one class to manage ALL DB transactions.
I need to either create a class or find a class that can protect all SQL queries from XXS or SQL Attacks. What suggestions do you have for securing PHP Database connections?
Using PDO's prepared statements to access databases makes queries immune to injection.
http://us2.php.net/manual/en/pdo.prepare.php
Using htmlspecialchars() makes output immune to xxs.
http://us2.php.net/manual/en/function.htmlspecialchars.php
just try to filter you POST,GET requests with this function
function protect($string)
{
if (ini_get('magic_quotes_gpc') == 'off') // check if magic_quotes_gpc is on and if not add slashes
{
$string = addslashes($string);
}
// move html tages from inputs
$string = htmlentities($string, ENT_QUOTES);
//removing most known vulnerable words
$codes = array("script","java","applet","iframe","meta","object","html", "<", ">", ";", "'","%");
$string = str_replace($codes,"",$string);
//return clean string
return $string;
}
you can easily apply it for the whole input using array_map function
$input = array_map('protect','$_POST');
$input = array_map('protect','$_GET');
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
PHP: the ultimate clean/secure function
I found this code snippet here: http://snipplr.com/view/12853/clean-variables-from-sql-injections/
The author claims:
This little function helps to fight common security issue with SQL injections, it can sanitize any global variable like $POST, $GET, $_SERVER etc and escape unsafe characters.
Is this code safe?
function _clean($str){
return is_array($str) ? array_map('_clean', $str) : str_replace("\\", "\\\\"
, htmlspecialchars((get_magic_quotes_gpc() ? stripslashes($str) : $str)
, ENT_QUOTES));
}
//usage call it somewhere in beginning of your script
_clean($_POST);
_clean($_GET);
_clean($_REQUEST);// and so on..
Please enlighten me whether this is safe, 'cause it looks jury-rigged to me.
Generic code cleaning functions are always a bad idea. They will break your data in one way or the other. Never use them; sanitize data right before it gets used, with the right sanitation method for the intended use.
Duplicate: PHP: the ultimate clean/secure function
Just use mysql_real_escape_string if you need to escape special characters for a mysql database. I'd figure other databases support similar functions too.
This snipped tries some silly replaces and may be pretty safe, but could just as well mess up your data too. Why reinvent the wheel?
Why wouldn't you just use the built-in escaping/parameterizing functionality for your database? I agree with it looking jury-rigged, go with the function built by the people who made the database library.
It's not safe (no addslashes or mysql_real_escape_string there), not optimal in performance too (get_magic_quotes_gpc being called for each variable).
I'm no PHP/SQL expert, and I've juste discovered that i had to apply mysql_real_escape_string to secure my SQL INSERTS.
I made a function using several advice found on the net, here it is:
function secure($string)
{
if(is_numeric($string))
{ $string = intval($string); }
elseif (is_array($string))
{
foreach ($string as $key => $value) {
$string[$key] = secure($value);
}
}
else if ($string === null)
{
$string = 'NULL';
}
elseif (is_bool($string))
{
$string = $string ? 1 : 0;
}
else
{
if (get_magic_quotes_gpc()) { $value = stripslashes($string); }
$string = mysql_real_escape_string($string);
$string = addcslashes($string, '%_');
}
return $string;
}
Thing is, when I have a look at my tables content, it contains backslashes.
And then logically, when I retrieve data I have to apply stripslashes to it to remove these backslashes.
Magic Quotes are off.
QUESTION 1)
Now I think that even though I use mysql_real_escape_string to secure my data before SQL insertion, backslashes should not appear in my content ? Can you confirm this ?
QUESTION 2)
If not normal, why are these backslashes appearing in my phpMyAdmin content and retrievals ? What did I did wrong ?
QUESTION 3)
A guess I have is that mysql_real_escape_string could be applied twice, isn't it ?
If so, what could be a function to prevent mysql_real_escape_string being applied many times to a same string, leading to many \\ to a same escapable character ?
Thanks a lot by advance for your inputs guys !
oh, what a senseless function. I know it's not your fault but ones who wrote it in their stupid articles and answers.
Get rid of it and use only mysql_real_escape_string to escape strings.
you have mixed up everything.
first, no magic quotes stuff should be present in the database escaping function.
if you want to get rid of magic quotes, do it centralized, at the very top of ALL your scripts, no matter if they deal with the database or not.
most of checks in this function are useless. is_bool for example. PHP will convert it the same way, no need to write any code for this.
LIKE related escaping is TOTALLY distinct matter, and has nothing to do with safety.
is numeric check is completely useless, as it will help nothing.
Also note that escaping strings has nothing to do with security.
I's just a syntax rule - all strings should be escaped. No matter of it's origin or any other stuff. Just a strict rule: every time you place a string into query, it should be quoted and escaped. (And of course, if you only escape it but not quote, it will help nothing)
And only when we talk of the other parts of query, it comes to the SQL injection issue. To learn complete guide on this matter, refer to my earlier answer: In PHP when submitting strings to the database should I take care of illegal characters using htmlspecialchars() or use a regular expression?
Your stripslashed $string is stored to the wrong variable $value instead of $string:
if (get_magic_quotes_gpc()) { $value = stripslashes($string); }
should be
if (get_magic_quotes_gpc()) { $string = stripslashes($string); }
Are you sure you aren't calling mysql_real_escape_string more than once, each time you call it with escapable characters you will end up adding more and more slashes. You want to call it only once. Also, why are you also calling addcslashes? mysql_real_escape_string should be enough. If you call it only once, you should never have to call stripslashes on the data after retrieving it from the database.
You can't really tell if mysql_real_escape_string is applied more than once, I'd suggest going back and re-reading your code carefully, try debug printing the values just before they are inserted into the db to see if they are look 'over-slashed'.
Btw, if you are using prepared statements (e.g. via mysqli) you dont need to escape your strings, the DB engine does this for you, this could be the problem too.
Remove addslashes completely from all of your code. This is the leading cause for slashes being inserted into database.
function escape($string) {
if (get_magic_quotes_gpc()) {
$string = stripslashes($string);
}
return mysql_real_escape_string($string);
}
Always check if magic_quotes_gpc is enabled, if it is perform stripslashes and escape the data.
Escaped = "don\'t use addslashes"
When it goes into database the '\' is removed.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Best way to stop SQL Injection in PHP
I am creating a website using PHP that makes use of a MySQL database and handles forms and variables from the URL. The variables are being using to dynamically construct SQL query strings. So i need a robust solution to make sure nobody is trying a SQL injection, etc.. A friend of mine has said that really i should only use stored procedures to access the database but that's not really feasible because the host i'm using doesn't allow these.
Here is the code i'm using (it's part of a class to wrap DB commands):
...
public function Sanitize($Variable)
{
if(is_resource($this->ServerConnection))
{
$Variable = str_replace(";", "", $Variable);
if(get_magic_quotes_gpc())
{
if(ini_get('magic_quotes_sybase'))
{
$Variable = str_replace("''", "'", $Variable);
}
else
{
$Variable = stripslashes($Variable);
}
}
return mysql_real_escape_string($Variable, $this->ServerConnection);
}
else
{
$this->PrintError("The Sanitize function is not available as there is no server connection.");
}
}
...
Is this function robust enough? Should i be doing anything else?
Might be worth reading this post.
What is the best way of ...
There is no best way. It depends on the context.
.. sanitising POST/GET variables from ..
It is a flawed mode of thinking that data are good or bad. Data is just data. It's the context in which it's used that makes it malicious or not. Some words may be bad if you execute them unadorned on a database server. Some words are bad if you display them to minors. It's about context.