如何保护网站免受 SQL 注入攻击

防止 SQL 注入的网站安全：如何保护网络资源免受数据库攻击

SQL 注入是指恶意 SQL 代码进入数据库查询并开始执行他人的逻辑。通常，攻击者不会输入“正常”的文本，而是一个改变查询含义的片段——例如，帮助绕过身份验证、从表中提取记录或删除它们。

这里的危险非常实际。登录名、密码、地址、订单、内部设置、会话令牌，甚至网站的管理员功能都可能暴露。一个粗心的查询可能会打开对您从未打算向任何人展示的数据的访问，这就是为什么 SQL 注入保护必须从一开始就内置到代码中。

SQL 注入也很棘手，因为它可能会长时间隐藏，网站看起来正常，表单可能正常工作，购物车可能接受订单，而数据库的后门已经存在。有时问题只有在泄漏或表中出现奇怪记录后才会被发现。

SQL 注入攻击在实践中是如何工作的

最简单的场景是一个登录表单。用户输入用户名和密码，应用程序构建一个没有参数的数据库查询。如果查询字符串是手动组装的，攻击者可以输入的不是密码，而是一段破坏检查或更改搜索条件的 SQL。

通过 URL 参数，攻击看起来几乎是例行公事。例如，一个目录页面接受 ?id=15，服务器查询产品表。如果你传递的不是数字——数据库接受的作为 SQL 一部分的表达式——你可以获得额外的行或查看其他人的记录。这就是为什么在考虑如何防止 SQL 注入时，链接和过滤器永远不应该被视为“默认安全”。

Cookies 也可以用于这样的攻击。如果网站读取 cookie 值并将其插入到 SQL 查询中而没有验证，攻击者可以在浏览器中更改 cookie 并提供一个危险的字符串。API 请求的工作方式类似：JSON 或表单参数发送到服务器，服务器粗心地组装查询。三个入口点，一个问题。

在实践中，攻击很少看起来戏剧化，更多时候只是一个奇怪的字符，一个多余的引号，一个“应该”不以那种方式处理的参数。然而，后果可能是严重的，因为数据库通常信任它所接收到的内容。

网站可能脆弱的主要迹象

第一个明显的信号是屏幕上的数据库错误。如果在搜索或过滤字段中输入文本时，SQL 语法消息、表名或连接驱动程序详细信息突然出现，那就是一个坏兆头。像“语法错误”、“未知列”或“数据库异常”这样的错误不应被忽视。

第二个迹象是奇怪的表单行为。登录表单过于轻易地接受错误数据，过滤器返回的结果超过应有的数量，搜索开始找到与正常文本完全不相似的查询记录，这种行为通常表明参数在没有严格处理的情况下到达了SQL。

第三个信号是未经授权的数据访问。例如，用户可以看到其他人的订单、个人资料或不应出现在界面中的内部字段。有时它悄然出现：报告中出现额外的行，或者在管理面板中显示出没有人做出的更改。

还有一些不太明显的迹象。网站在某些请求上开始变慢，日志中出现重复错误，当参数稍微改变时，同一页面的响应也不同，这还不能证明是攻击，但这是检查代码和数据库的理由。

保护网站免受 SQL 注入攻击：基本措施

第一也是最重要的措施是参数化查询。当一个值与SQL文本分开传递时，数据库将其视为数据，而不是命令的一部分。这是一个简单的原则，但它切断了大多数常见攻击。

预处理语句以相同的精神工作。首先，应用程序定义查询结构，然后通过参数填充值。这种方法在同一操作经常重复的地方特别有用：登录、搜索、过滤、个人资料更新、订单创建。在实践中，参数化查询与预处理语句的选择不如一致使用安全模式重要。

如果使用得当，ORM也会有所帮助。ORM本身并不能保护你免受错误的影响，如果开发者在没有参数的方法中插入原始SQL，但在普通场景中，ORM减少了手动组装查询的风险，使代码更可预测。这里，纪律比库的名称更重要。

验证应在输入阶段进行，而不是之后。如果一个字段应该包含数字，就让它包含数字；如果是电子邮件，就检查格式；如果是日期，就限制模式。转义并不能替代参数化，但有时它可以补充，特别是在输出和遗留代码中。只要不要试图通过“替换引号”来修复SQL注入——那是一种坏习惯，而不是保护。

在代码层面测试单个入口点也是有用的。SQL是在哪里构建的？用户输入来自哪里？字符串是在哪里手动连接的？三个问题，便能清楚地知道首先需要重写什么。

减少 SQL 注入风险的额外安全措施

数据库的最小权限原则应默认启用。应用程序账户不应拥有所有权限：它不需要访问系统表、不必要的模式或危险操作，如果网站只读取目录，它就不应有删除记录的权限。

分离访问也有帮助。您可以为管理面板、公共网站和后台作业使用不同的帐户和不同的权限集。这样，即使一个模块存在缺陷，攻击者也无法访问整个数据库。这在具有多个角色和多个入口点的项目中尤为明显；我们在关于的文章中讨论了类似的网站架构任务。企业网站结构.

详细错误最好对用户隐藏。像“SQL语法错误在...附近”这样的消息对开发者很方便，但在生产环境中却有害，用户应该看到一个中性的占位符，而详细信息应该记录到日志中。

日志记录有助于在攻击尝试成为事件之前进行检测。寻找一系列失败的请求、同一路径上的重复错误、奇怪的参数值以及对敏感页面的重复访问。日志本身并不能提供保护，但它们确实留下了痕迹。

限制数据库帐户的能力是另一层实用的保护，如果应用程序不需要DELETE或DROP TABLE，则不应允许这些操作。当帐户无法更改数据库结构时，攻击的一部分就失去了意义。

如何检查网站是否存在 SQL 注入漏洞

测试最好不是在实时网站上开始，而是在一个暂存环境中。在那里，您可以重现场景而不冒销售风险、破坏管理面板或损坏表。测试需要代码的副本、配置的副本和对日志的访问。

手动测试围绕可疑点进行：登录、搜索、过滤、排序、产品页面、API方法，并一次更改一个参数，观察应用程序的响应。如果数据库错误仅对一个值出现，那已经是一个信号。如果行为因一个引号而改变，则该问题需要更深入的分析。

自动扫描器很有用，但它们不是魔法，它们能找到常见的案例，但可能会漏掉复杂的链条，或者相反，产生误报。因此，扫描器是第一步，而不是最终的裁决。之后，你需要一个理解应用逻辑的人。

在生产环境中，谨慎是至关重要的。激进的测试可能会使数据库过载，杂乱日志，甚至损坏数据，如果某个危险的入口点已经存在于某处，对于一个实时网站，最好坚持温和的检查，将风险场景留给预发布和备份。

如果网站很大，将审计分为两个阶段是有意义的：首先是关键表单和API，然后是不太明显的区域。这种方法节省时间，并降低意外干扰实时过程的机会。这里没有必要急于求成。

如果已经发生了 SQL 注入该怎么办

第一步是隔离事件。如果怀疑有主动攻击，暂时限制对脆弱模块的访问，将其切换到保护模式，或禁用有问题的功能，短暂的暂停总比大规模泄漏要好。

接下来，改变密码和访问密钥。这包括数据库密码、应用程序密钥、集成令牌、API密钥和管理员凭据，如果它们可能处于风险中。一个被泄露的秘密往往会牵连其他秘密。

然后你需要进行日志分析。查看事件发生前发出了哪些请求，哪些IP重复，哪些参数发生了变化，哪些表被读取或修改，如果有备份，比较数据更改的时间与可疑活动的时刻。这会给你一个清晰的时间线。

之后，如果数据库完整性受到影响，请从干净的备份中恢复数据。在漏洞未修复且后果未处理之前，不要急于将网站恢复正常。否则，攻击将通过同样的点再次发生。

最后一步是关闭漏洞并再次测试网站，修复应遵循与原始错误相同的路径：代码、测试、预发布，然后是生产。没有重新测试，你只能寄希望于此——而希望在这种情况下是一个脆弱的工具。

保护网站免受 SQL 注入的实用检查清单

• 在用户输入到达 SQL 的每个地方使用参数化查询。
• 通过类型验证输入：数字、电子邮件、日期、允许值列表。
• 不要通过连接字符串手动构建 SQL。
• 检查你的 ORM：安全方法可以，未经参数的原始 SQL 不可以。
• 将数据库账户的权限限制到最低必要权限。
• 在界面中隐藏详细的数据库错误给用户。
• 启用错误、可疑参数和失败请求的日志记录。
• 在部署前测试易受攻击的区域。
• 手动检查表单、URL 参数、Cookie 和 API 端点。
• 将备份和恢复计划与生产服务器分开。

如果网站已经处理大量流量，请检查启动后支持的设置。对于数据库驱动的项目，这不是一项形式：更新、修复和日志监控需要定期进行，而不是每六个月一次。从这个意义上说，关于 启动后网站支持是有用的。

定期审计也很重要。一次性修复一个 SQL 注入漏洞并不足够，如果一个月后项目有了新的表单、新的 API 方法，或者一个仍然手动组装查询的旧脚本。保护网站免受 SQL 注入的影响，不仅依赖于一次补丁，而是依赖于每次数据库逻辑更改时检查代码和权限的习惯。