实战解析：如何修复 Flask 应用中的 SQL 注入与安全漏洞

在网络安全实践中，识别并修复代码中的漏洞是保障应用安全的关键一步。本文将深入剖析一个基于 Python (Flask) 和 sqlite3 数据库的 Web 应用程序。该应用包含登录和帖子发布功能，但在安全设计上存在明显缺陷。我们在审计代码时发现了 7 个 SQL 注入 (SQLi) 漏洞、2 个 CSRF 漏洞和 1 个 XSS 漏洞。本文将重点展示前三个典型的 SQL 注入场景、攻击原理及其修复方案。

SQL 注入问题根源

该应用最初的代码直接通过拼接用户输入来构建 SQL 查询语句。这种做法极具危险性，攻击者只需在输入框中注入恶意的 SQL 代码，或恶意篡改 Cookie，就能完全改变数据库查询的原本逻辑，从而绕过安全验证，控制底层数据库。

SQLi-1：通过密码字段绕过登录验证

存在漏洞的原始代码如下：

res = cur.execute("SELECT id from users WHERE username = '" + request.form["username"] + "' AND password = '" + request.form["password"] + "'")

攻击原理：攻击者在登录页面输入 alice 作为用户名，并在密码框中输入 ' OR '1'='1。应用程序将该输入直接拼接入查询中，导致后端执行的 SQL 变为：

WHERE (username = 'alice' AND password = '') OR ('1'='1')

由于 '1'='1' 恒为真，数据库会直接返回用户 alice 的数据行，攻击者无需知道其真实密码即可成功登录。

安全修复：采用 参数化查询 (Parameterized Queries)，将用户输入作为参数传入，防止输入内容被当作 SQL 代码执行：

res = cur.execute("SELECT id FROM users WHERE username = ? AND password = ?", (request.form["username"], request.form["password"]))

SQLi-2：无凭证登录绕过

该漏洞的触发源于与 SQLi-1 相同的拼接代码漏洞。

攻击原理：攻击者可以在用户名输入框中填写 ' OR 1=1 -- （注意末尾带空格），密码随意填写。拼接后的查询语句变成了：

WHERE username = '' OR 1=1 -- ' AND password = '...'

这里的双减号 -- 代表 SQL 的注释符，它直接注释掉了后面所有的密码验证代码。而 1=1 恒成立，使得攻击者可以无需任何密码，直接以数据库中的第一个用户身份登录系统。

安全修复：同样需要使用相同的参数化查询机制，将用户输入严格限制在数据字面量范围内，彻底杜绝注入隐患。

SQLi-3：特定目标用户绕过

该漏洞同样源自同一段未经过滤的 SQL 拼接代码。

攻击原理：如果攻击者已知某个特定用户的用户名（例如 alice），他们可以在用户名输入框中输入 alice' --，密码随机填写。最终生成的查询语句为：

WHERE username = 'alice' -- ' AND password = '...'

注释符 -- 将密码校验部分完全截断，数据库仅匹配用户名 alice，攻击者便能精准登录到该特定用户的账户中。

安全修复：使用安全占位符的参数化查询方案是唯一的标准解法，它迫使数据库引擎将整个用户输入严格视为字面量，而非可执行的命令结构。