准备好的语句和 $_GET (有安全问题吗?)
可能的重复:
准备好的语句如何防范 SQL 注入攻击?
如果我将 $_GET 与 PDO 一起使用,我还需要转义它吗?我的理解是,这不受 SQL 注入的影响,但我仍然对不逃避它感到不安。那么有人可以看看这个小代码块并告诉我它是否安全吗?
<?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;
?>
再说一次,我关心的是 $_GET。如有任何帮助,我们将不胜感激,谢谢。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的,准备好的语句功能正如它所说的那样。但既然你问了,我们就明确一点,这并不是故事的结局。我正在查看2010 年 OWASP 十大应用程序安全风险。
例如:
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: