Question

Possible Duplicate:
How prepared statements can protect from SQL injection attacks?

If I’m using $_GET with PDO do I still need to escape it? My understanding is that this is immune to SQL injection, however I still feel uneasy about not escaping it. So could someone please look at this little block of code and tell me if it is secure?

<?php
$hostname = 'localhost';
$username = 'root';
$password = 'root';
$database = 'database';
try {
    $dbh = new PDO("mysql:host=$hostname;dbname=$database", $username, $password);
    $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $stmt = $dbh->prepare("SELECT * FROM comments WHERE pid = :pid");
    $pid = $_GET['pid'];
    $stmt->bindParam(':pid', $pid, PDO::PARAM_STR);
    $stmt->execute();
    $result = $stmt->fetchAll();
    }
catch(PDOException $e)
    {
    echo $e->getMessage();
    }
    $stmt->execute();
    echo $stmt->rowCount();
$dbh = null;
?>

Again, it’s the $_GET I’m concerned about. Any help is appreciated, thank you.

Answer 1

Yes, the prepared statement feature does what it says. But since you asked, let’s be clear that it’s not the end of the story. I’m looking at the OWASP Top Ten Application Security Risks 2010.

For example:

• Is every remote user authorized to access data associated with every PID? If not, failing to check that the user is authorized is a clear example of OWASP 2010-A4-Insecure Direct Object References.
• You’re probably not serious about hardcoding the password in cleartext, because that is a clear example of OWASP 2010-A7-Insecure Cryptographic Storage.
• You don’t say what you might do with $stmt apart from echoing the rowcount, but of course if you display any content from the database you’ll be careful to escape HTML entities first. Otherwise you would create a clear example of OWASP 2010-A2-Cross-Site Scripting (XSS).
• By the way, it’s generally better to specify columns (or aggregate functions) explicitly rather than to “SELECT *”.