0

I have the following:

$did=$_GET['deptID'];

variable passed from 1st page and on 2nd page, the link is like and to get data MySQL query is: 

$q= mysql_query("select DepName from dep where DepID='$did'")or die(mysql_error());

Now my question is how can I use the mysql_escape_string() function in this query?

alecxe
  • 462,703
  • 120
  • 1,088
  • 1,195
user3355035
  • 29
  • 7
  • 5
    **WARNING**: If you're just learning PHP, please, do not use the [`mysql_query`](http://php.net/manual/en/function.mysql-query.php) interface. It’s so awful and dangerous that it was removed in PHP 7. A replacement like [PDO is not hard to learn](http://net.tutsplus.com/tutorials/php/why-you-should-be-using-phps-pdo-for-database-access/) and a guide like [PHP The Right Way](http://www.phptherightway.com/) explains best practices. Your user data is **not** [properly escaped](http://bobby-tables.com/php.html) and there are [SQL injection bugs](http://bobby-tables.com/) and can be exploited. – tadman Dec 11 '17 at 16:15
  • 2
    Short answer: Don't. Use PDO and placeholder values. – tadman Dec 11 '17 at 16:15
  • for Backward compatiblety must use it. so please any help in this regard – user3355035 Dec 11 '17 at 16:18
  • Compatibility with what? Even PHP4 supports `mysqli` and any version of PHP5 from the last fifteen years supports PDO. – tadman Dec 11 '17 at 16:39
  • @tadman, I assume the OP means backward compatibility with the app's own code base. In other words, if the app has 100,000 lines of legacy code using ext/mysql, it's flippant to tell them, "switch to PDO" as though it can be done with no work. – Bill Karwin Dec 13 '17 at 03:40
  • @user3355035, `$did = mysql_real_escape_string($_GET['deptID']);` – Bill Karwin Dec 13 '17 at 03:40
  • @user3355035, alternative: `$did = (int) $_GET['deptID'];` if the id is meant to be an integer. Casting to an integer makes it safe with respect to SQL injection, because an integer can only contain digits (or `-`). – Bill Karwin Dec 13 '17 at 03:43
  • @BillKarwin I hope any company with a `mysql_query` driven code-base has a *lot* of liability insurance. "Switch to PDO" might sound flippant, but it's the responsible thing to do. I'm all for pragmatic concerns about a lot of things, refactoring can always happen later, etc., but security is not one to compromise on. – tadman Dec 13 '17 at 16:45
  • @tadman, It is possible—though awkward—to write secure code with ext/mysql. Assuming ext/mysql is inherently insecure is incorrect. I gave two suggestions above for what to do in the OP's case. And pragmatically, fixing one line of code instead of rewriting thousands of lines in an unfamiliar API is more likely to happen, and thus more likely to be secure. – Bill Karwin Dec 13 '17 at 16:52
  • @BillKarwin The reason I'd argue it's "inherently insecure" is because you're always one tiny mistake away from catastrophic failure, a single unescaped value is often game-over for your application with `mysql_query`. If you're disciplined about using placeholder values then it will take several mistakes to expose you to the same risk. Additionally, it's [not even actually secure](http://www.gosecure.it/blog/art/483/sec/mysql_escape_string-the-charset-vulnerability/) in some configurations. – tadman Dec 13 '17 at 16:56
  • @tadman, I'm not arguing against using PDO. I know it's better, and I encourage every PHP developer to use it. I'm just saying many software projects have constraints, and they have to get today's task done before they can rewrite their whole app in PDO. – Bill Karwin Dec 13 '17 at 17:02
  • @BillKarwin I know what you're saying, but I'd prefer to get to the bottom of what these unspecified "backward compatibility" concerns are before jumping to conclusions. Most of the time it's a misunderstanding of what PDO is supported on, or that PDO doesn't work with MySQL because it doesn't have "mysql" in the name. On those occasions where it's "my code base is really old and out of date and I can't fix it" then I'll understand. – tadman Dec 13 '17 at 17:06

0 Answers0