PHP中未将用户输入传入数据库查询是否存在SQL注入风险？

首先明确：不是只要使用用户输入就存在SQL注入风险，SQL注入的核心是用户输入被直接拼接进SQL查询语句，导致数据库查询逻辑被非法篡改。针对你提到的两个场景，具体分析如下：

场景1：使用session的user_id拼接SQL查询 #

你写的代码：

$sql="SELECT * FROM leads where user_id='".$_SESSION[user_id]."';;

这个场景存在SQL注入风险。虽然user_id是登录时生成的session变量，但如果该session值存在被用户篡改的可能（比如session劫持、登录逻辑未严格校验导致用户可控该值），直接将其拼接进SQL语句，攻击者就能构造恶意值篡改查询逻辑。

正确的做法是使用参数化查询（预处理语句），不管数据来源是session还是POST/GET，只要是外部传入的动态值，都应该通过参数化方式传入SQL，而非直接拼接。示例：

$stmt = $link->prepare("SELECT * FROM leads WHERE user_id = ?");
$stmt->bind_param("s", $_SESSION['user_id']);
$stmt->execute();
$results = $stmt->get_result();

场景2：POST下拉框值仅用于PHP内部逻辑比较 #

你提到的代码逻辑：先执行SQL查询获取结果，再用POST的下拉框值在PHP里过滤time_stamp，代码示例：

if($results = mysqli_query($link, $sql)){ 
    while($row = mysqli_fetch_array($results )) { 
        if($row["time_stamp"] > $_POST["select_box"]) { 
            // 执行其他操作
        }
    }
}

这个场景不存在SQL注入风险。因为SQL查询已经在获取用户输入前执行完毕，用户输入的下拉框值并没有参与SQL语句的构造，只是在PHP层面做逻辑判断，不会影响数据库的查询逻辑。

需要注意的是：虽然没有SQL注入风险，但如果后续需要将这个下拉框值输出到页面，仍需做XSS防护（比如用htmlspecialchars()转义），不过这属于跨站脚本攻击的防护范畴，和SQL注入无关。

内容的提问来源于stack exchange，提问作者Andy Bbop