【问题标题】:Is this SQL statement safe against injection despite not being prepared?尽管没有准备好,这个 SQL 语句对注入安全吗?
【发布时间】:2016-04-20 10:53:44
【问题描述】:

我知道你应该准备用户影响的所有 SQL 语句,这个问题更多的是看看你是否也可以有一个用户可以更改但你以不同方式处理错误的 SQL 查询。

可注入 SQL 的代码:

if(isset($_GET['delete']) && (int)$_GET['delete'] && is_numeric($_GET['delete'])){
    $query = $handler->query('SELECT * FROM portfolio WHERE id =' . $_GET['delete']);
}
else{
    echo'Error';
}

由于if 语句围绕它,SQL 查询会不会被注入,或者是否还有某种注入方式?

这纯粹是为了研究,显然不在任何真实的网站上。

这就是代码在准备时的样子,只是为了表明我不是询问如何准备:

if(isset($_GET['delete']) && (int)$_GET['delete'] && is_numeric($_GET['delete'])){
    $query = $handler->prepare('SELECT * FROM portfolio WHERE id = :id');
    $query->execute([
        ':id' => $_GET['delete']
    ]);
}
else{
    echo'Error';
}

【问题讨论】:

  • 如果使用参数化查询,您可以跳过该条件。在你的get变量中发送一个字符串只会导致没有匹配的行

标签: php mysql pdo


【解决方案1】:

是的,这个特殊的代码 sn-p 是安全的。

我想知道你能从这个答案中得出什么有用的结论。

另外,回答你的一些陈述。

你应该准备用户影响的所有 SQL 语句,

这是与 SQL 注入问题有关的最严重的错觉之一。事实上,只有当所有 100% 的查询都被参数化时,你才被认为是安全的,并且你永远不会因为“我正在处理的数据是否是用户可以影响的数据”这个问题而困扰自己.

但你处理错误的方式不同。

这种处理永远不应该相互连接。如果您想验证输入参数 - 这是一个好主意。但是你的SQL处理代码决不应该依赖于这种验证的结果。这只是不同的事情。在一个组织良好的代码中,您的输入参数验证永远不会与 SQL 处理代码位于同一个文件中。后者完全不知道验证的事实。或对此类验证所做的任何更改(例如,它一开始只允许数字,然后更改为接受任意字符串)。 SQL 处理代码应该能够在提供的任何数据上安全运行。

【讨论】:

    猜你喜欢
    • 2014-01-28
    • 1970-01-01
    • 2015-11-08
    • 2013-03-17
    • 1970-01-01
    • 2014-10-14
    • 2013-11-19
    • 2010-11-21
    相关资源
    最近更新 更多