SQL注入漏洞详解
漏洞描述
SQL注入漏洞产生的原因是网站应用程序在编写时未对用户提交至服务器的数据进行合法性校验（类型、长度、业务参数合法性等），同时没有对用户输入数据进行有效地特殊字符过滤，使得用户的输入直接带入数据库执行，超出了SQL语句原来设计的预期结果，导致了SQL注入漏洞。
漏洞原理
简单点说，就是服务端未对用户的输入进行过滤和验证，导致恶意的sql语句直接与后端sql查询语句进行，造成了非本意的查询结果并且回显到页面上，最终导致数据库敏感信息泄露等。
SQL 注入漏洞的核心原理在于攻击者能够将恶意的 SQL 代码注入到应用程序的 SQL 查询语句中，从而执行未经授权的数据库操作
sql注入分类
- 从注入参数类型分：数字型注入、字符型注入
- 从注入效果分：报错注入、无显盲注（布尔盲注、延时盲注）、联合注入、堆叠注入、宽字节注入、二次注入
- 从提交方式分：GET注入、POST注入、HTTP头注入（UA注入、XFF注入）、COOKIE注入
漏洞场景
SQL注入漏洞可能出现在一切与数据库交互的地方，比如常见的查询用户信息、查询订单信息等查询处；搜索、筛选、过滤等；更新用户信息、添加备注等。另外，其他日志记录、分析等处也可能出现，比如记录用户登录处，记录用户登录日志处；比如常见的请求头中的字段，UA、XFF等。
SQL 注入的常见位置
- URL参数：攻击者可以在应用程序的 URL 参数中注入恶意 SQL 代码，例如在查询字符串或路径中
- 表单输入：应用程序中的表单输入框，如用户名、密码、搜索框等，如果没有进行充分的输入验证和过滤，就可能成为 SQL 注入的目标
- Cookie：如果应用程序使用 Cookie 来存储用户信息或会话状态，攻击者可以通过修改 Cookie 中的值来进行 SQL 注入
- HTTP头部：有些应用程序可能会从 HTTP 头部中获取数据，攻击者可以在 HTTP 头部中注入恶意 SQL 代码。
- 数据库查询语句：在应用程序中直接拼接 SQL 查询语句的地方，如果没有正确地对用户输入进行过滤和转义，就可能导致 SQL 注入漏洞
如何判断是否存在 SQL 注入
- 单双引号判断
- and 型判断
- or 或 xor 判断
- exp(709) exp(710)
类型判断
判断是否存在注入，若存在，则判断是字符型还是数字型，简单来说就是数字型不需要符号包裹，而字符型需要
数字型：select * from table where id =$id
字符型：select * from table where id='$id'
判断类型一般可以使用 and 型结合永真式和永假式，判断数字型：
1 and 1=1 #永真式 select * from table where id=1 and 1=1
1 and 1=2 #永假式 select * from table where id=1 and 1=2
#若永假式运行错误，则说明此SQL注入为数字型注入判断字符型：
1' and '1'='1
1' and '1'='2
#若永假式运行错误，则说明此SQL注入为字符型注入然后通过order by来查字段个数，判断字段个数之后查找显示位，然后开始爆破库名、表名、字段名、详细内容等等，这里就先不详细写了。
SQL 注入的另外一个重要知识点，也就是注释的使用（可以确认有没有其他闭合字符），MySQL 提供了以下三种注释方法：
- #：不建议直接使用，会被浏览器当做 URL 的书签，建议使用其 URL 编码形式%23
- --+：本质上是--空格，+会被浏览器解释为空格，也可以使用 URL 编码形式``--%20
- /**/：多行注释，常被用作空格
风险等级
SQL 注入漏洞的风险等级通常为高危。因为攻击者可以通过利用此漏洞来执行各种数据库操作，包括获取敏感数据、修改数据库内容、执行系统命令等，从而造成严重的安全问题。
漏洞危害
获取数据库访问权限，甚至获得DBA权限；
- 获取其他数据库中的数据；
- 盗取用户的机密信息包括账户、个人私密信息、交易信息等等；
- 运行各种操作系统命令；
- 通过构造特殊的数据库查询语句，可操作数据库进入后台并插入木马，以获取整个网站和数据库的控制权限；
- 篡改、删除网站页面；
- 数据库所在服务器被攻击从而变为傀儡主机，甚至可能导致局域网(内网)被入侵；
Sql 注入带来的威胁主要有如下几点
- 猜解后台数据库，这是利用最多的方式，盗取网站的敏感信息。
- 绕过认证，例如绕过验证登录网站后台。
- 注入可以借助数据库的存储过程进行提权等操作
漏洞验证
验证 SQL 注入漏洞的存在通常涉及尝试在输入框中输入恶意的 SQL 代码，并观察应用程序的响应是否发生异常。如果应用程序返回了与预期不符的结果，可能存在 SQL 注入漏洞。
如在url中存在?id=1类似的字眼，可以尝试改为1+1或添加单双引号，改变数值来看页面是否会发生变化。
漏洞利用
攻击者可以构造恶意的sql语句来查询一些敏感的数据库和表内容，导致用户信息泄露。
漏洞防御
代码层面
输入验证
类型判断：字符型、整型；
长度判断：设置最大长度值；
业务参数合法性判断：比如支付金额不可能为负值这种；
特殊字符过滤：比如'，"，\，<，>，&，*，;，#，select，from，where，sub，if，union，sleep，and，or等；
验证所有的输入点，包括UA、Cookie以及其他HTTP头；
预编译处理&参数化查询
所有与数据库交互的业务接口均采用参数化查询，参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中，参数化查询是防御SQL注入的最佳方法，比如：Java中的PreparedStatement，PHP中的PDO等。
数据库层面
最小权限原则
遵循最小化权限原则，严格限制网站用户的数据库的操作权限，禁止将任何高权限帐户（sa，dba、root等）用于应用程序数据库访问，从而最大限度的减少注入攻击对数据库的危害。
禁用敏感函数
比如MSSQL中，拒绝用户访问敏感的系统存储过程，如xp_dirtree，xp_cmdshell等。
权限控制
限制用户所能够访问的数据库表。
编码统一
网站与数据层的编码统一，建议全部使用UTF-8编码，避免因上下层编码不一致导致一些过滤模型被绕过，比如宽字节注入等。
其他措施
- 避免网站异常抛出SQL错误信息，比如类型错误、字段不匹配等，防止攻击者利用这些错误信息进行一些判断；
- 使用通用防注入系统；
- 上设备，装防火墙和waf等安全设备
典型案例
- 登录绕过：攻击者可以通过在用户名和密码输入框中输入恶意的 SQL 代码来绕过登录验证，例如输入 ' OR 1=1 -- 来使查询条件始终为真，从而成功登录而不需要正确的用户名和密码。
- 信息泄露：攻击者可以利用 SQL 注入漏洞来获取数据库中的敏感信息，如用户凭据、个人资料、信用卡号等。通过构造恶意的 SQL 查询语句，攻击者可以检索数据库中的敏感数据并将其返回给攻击者。
- 数据篡改：攻击者可以利用 SQL 注入漏洞修改数据库中的数据，包括插入、更新或删除数据。通过构造恶意的 SQL 代码，攻击者可以修改应用程序中的数据，例如更改用户权限、篡改文章内容等。
- 拒绝服务：攻击者可以利用 SQL 注入漏洞执行恶意的数据库操作，导致数据库服务器负载过高或数据库服务崩溃，从而造成服务不可用的情况。
- 提权攻击：在某些情况下，攻击者可以利用 SQL 注入漏洞来提升其权限，例如通过执行系统命令来获取管理员权限或操作系统级别的访问权限。
- 数据库服务器攻击：攻击者可以利用 SQL 注入漏洞对数据库服务器进行攻击，例如通过执行耗费资源的 SQL 查询来耗尽数据库服务器的资源或导致拒绝服务。