Burpsuite靶场——SQL注入

在本篇文章中，咱们将解释什么是 SQL 注入，描述一些常见的例子，解释如何发现和利用各种 SQL 注入漏洞，并总结如何防止 SQL 注入。

废话不多说，开始正篇。

一、什么是SQL注入

SQL注入漏洞（SQL injection）是web层面最高危的漏洞之一。曾在2008-2010连续三年期间位列OWASP年度十大漏洞排行榜第一位。

SQL注入允许攻击者干扰应用程序对其数据库的查询。它通常允许攻击者查看他们通常无法检索的数据。这可能包括属于其他用户的数据，或应用程序本身能够访问的任何其他数据。在许多情况下，攻击者可以修改或删除这些数据，从而导致应用程序的内容或行为发生持续变化。在某些情况下，攻击者可以升级 SQL 注入攻击以破坏底层服务器或其他后端基础架构，或执行拒绝服务攻击。

二、SQL注入的影响

成功的 SQL 注入攻击可能导致未经授权访问敏感数据，例如密码、信用卡详细信息或个人用户信息。近年来，许多备受瞩目的数据泄露事件都是 SQL 注入攻击的结果，导致声誉受损和监管罚款。在某些情况下，攻击者可以获得进入组织系统的持久后门，从而导致长期危害，而这种危害可能会在很长一段时间内被忽视。

三、常见的SQL注入类型

SQL注入其实可以归结为两大类，一类是数字型注入，一类是字符型注入。我们平常所听到的cookie注入、post注入、盲注、延时等等注入其实只不过是上述两大类的不同展现形式或者不同展现位置罢了。

那么为什么SQL注入只分这两大类呢？因为对数据库进行数据查询时，输入的数据一般只有两种：

数字类型：where id = 1、where age > 18

字符串类型：where name = 'root' 、where datetime > '2022-05-13'

虽然不同的数据库的比较方式可能不一样，但是带入到数据库查询时一定是字符串。严格的来说，数字也是字符串，因为在数据库中进行数据查询时，where id = '1' 也是合法的，只不过查询条件为数字时我们一般不加单引号。

以下是我们常见的注入叫法：

POST注入：注入字段在post数据中

cookie注入：注入字段在cookie数据中

延时注入：使用数据库的延时特性注入

base64注入：注入字符串需要经过base64加密

四、实验环节

咱们先来看下第一题：where子句中允许检索隐藏数据的SQL注入漏洞

进入实验室，是一个显示不同类别产品的购物应用程序。

咱们点击“礼物”类别搜索商品，burpsuite抓包浏览器url请求

 

这会导致应用程序进行 SQL 查询以从数据库中检索相关产品的详细信息：

SELECT * FROM filter WHERE category = 'Gifts' AND released = 1

此 SQL 查询要求数据库返回：所有详细信息 (*)、从产品过滤表、其中类别是礼物、并隐藏未发布商品。这里的限制条件released = 1应该是隐藏未发布的产品。那么对于显示未发布商品应该为released = 0。

该应用程序没有实施任何针对 SQL 注入攻击的防御措施，因此攻击者可以构建如下攻击：

https://xxx.xxx.com/filter?category=Gifts'--

咱们分别请求filter?category=Gifts和filter?category=Gifts'--，来对比看下

请求filter?category=Gifts

请求filter?category=Gifts'--

很明显 ，请求参数重加的SQL注释指示符双破折号--起到了作用，导致SQL查询：

SELECT * FROM filter WHERE category = 'Gifts'--' AND released = 1

有效地删除了查询的其余部分，因此它不再包括AND released = 1. 这意味着显示所有产品，包括未发布的产品。

此外，咱们可以更进一步的构造请求参数从而使该应用程序显示任何类别的产品，而不仅仅是礼物类别。包括后台数据库中尚未定义的类别的产品。

https://xxx.xxx.com/filter?category=Gifts'+OR+1=1--

这将导致 SQL 查询：

SELECT * FROM filter WHERE category = 'Gifts' OR 1=1--' AND released = 1

修改后的查询将返回类别为礼物或 1 等于 1 的所有项目。由于1=1始终为真，因此查询将返回所有项目。

接下来看第二题：屏幕前可爱的你给弟弟点点关注点点赞呗，后续会更新更多好玩实用的实验案例给大家，今天先休息一下～

五、如何防止SQL注入

1. 避免使用动态SQL

避免将用户的输入数据直接放入 SQL 语句中，最好使用准备好的语句和参数化查询，这样更安全。

2. 不要将敏感数据保留在纯文本中

加密存储在数据库中的私有/机密数据，这样可以提供了另一级保护，以防攻击者成功地排出敏感数据。

3. 限制数据库权限和特权

将数据库用户的功能设置为最低要求；这将限制攻击者在设法获取访问权限时可以执行的操作。

4. 避免直接向用户显示数据库错误

攻击者可以使用这些错误消息来获取有关数据库的信息。