盲目的SQL注入--是威胁还是儿戏？
SQL注入是数据库管理员关注的主要问题之一。在这篇博客中，我们将介绍盲目的SQL注入对你的数据库的影响。
数据库领域的主要问题之一是SQL注入--它的流行程度甚至达到了OWASP不断将其列为针对网络应用的第一大威胁的程度。SQL注入有许多类型，其中一种类型是盲目的SQL注入--在这篇博文中，我们将介绍这种攻击的危害。
什么是SQL注入？它的类别是什么？
SQL注入 是针对数据库的主要攻击方式--当用户提供的输入没有经过净化和适当处理就直接转入数据库时，应用程序就容易受到SQL注入的攻击。
由于一些关键的原因，了解SQL注入的类别是非常重要的：
- 不同类型的SQL注入以不同的方式影响网络应用。
- 一些类型的SQL注入比其他类型更容易被预防。
- 有些类型的SQL注入直接依赖于我们的Web应用程序的功能（例如，一个成功的盲目SQL注入攻击的结果直接依赖于我们的Web应用程序是否显示错误。）
- 有些类型的SQL注入攻击有子类型（想想基于时间的盲目SQL注入）--这些子类型可能对邪恶的一方来说也会使交易失败，因为它们直接依赖于一个特定的因素，在这种情况下，无法控制，所以它们是直接的--时间。
SQL注入有几个类别：
SQL注入类别 | 关于 |
经典SQL注入 | 最普遍的SQL注入类型。这种注入类型最常被检测到（而且最著名的是被脚本小子们描述为 "非常简单的使用"），在一个GET参数上添加一个单引号，然后由数据库进行评估。 |
带外的SQL注入 | 这种类型的SQL注入可以用OOB（带外）技术来检测--可能有助于检测这种类型的注入的函数包括 |
盲目的SQL注入 | 这种类型的SQL注入，应用程序不返回任何错误--因此，攻击者无法确定他或她的恶意查询是否成功执行：在这种情况下，查询的结果经常通过查看被攻击的网页本身来决定--被返回的空白页面可能没有结果，而如果攻击者提交了一个错误的查询，它应该返回相同的页面（这可能看起来有点奇怪，因为有些东西可能丢失，等等。） |
正如你所看到的，SQL注入的类别并不多--然而，虽然经典的SQL注入被使用得最多，但当经典的SQL注入攻击不起作用时，攻击者通常会转向SQL的盲点--他们尝试用盲目的SQL注入攻击应用程序。
盲目SQL注入的王国
把你的应用程序想象成一座城堡。我们知道这可能看起来至少有点奇怪，但请容忍我们。现在，把你的网络应用程序想象成一座城堡。完成了吗？好吧，想象一下，一群拿着长矛的盲人士兵正在攻击它，他们的长矛经常错过城堡的坚固防御。你认为--拿着长矛的瞎子士兵有多少时间可以完成你城堡的防御？这需要一段时间，但士兵们最终会通过的。这倒是真的--而一旦士兵打通了，你储存在城堡里的宝物（你的网络应用程序里面的数据）就是仙人掌--他们会偷走一切。
士兵们装备精良，尽管他们是盲目的，但他们最终会将你的防御措施进行到底--哦，不！是的。这几乎是盲目的SQL注入在现实世界中的运作方式，所以让我们给你举另一个例子：
- 攻击者通过在某个参数后添加一个单引号，发现你的网络应用程序容易受到盲目的SQL注入的影响--然后你的网络应用程序返回一个错误。
- 攻击者不断制作SQL查询--没有一个返回任何错误。然而，他很快发现，如果他执行一种类型的查询，你的Web应用程序中的数据就会显示在屏幕上，而在他执行另一种类型的查询后，数据就会消失。"啊哈！"，--攻击者认为。"抓到你了。得到了一个盲目的SQL注入缺陷"。
正如你可能已经注意到的，盲目的SQL注入是一种攻击，它以查询的形式向数据库提出 "问题"，并试图根据Web应用程序上的响应来确定它们是真还是假。盲目的SQL注入最常通过运行这样的查询来检测。
如果一个网络应用程序返回一个 "积极的 "响应（意味着它在网页上返回一个可见的差异），该网络应用程序就容易受到这种攻击，而如果一个应用程序无动于衷，它可能就不会。在第一种情况下，攻击者会知道你的数据库出了问题，并试图进一步渗透你的防御。于是游戏开始了--攻击者试图注意你的网络应用程序愿意返回什么样的响应。一个查询返回一个有结果的页面--好的，他们进一步探测，一个查询返回一个空白页面--嗯......他们改变查询并再次尝试。就这样，游戏继续进行，直到从你的数据库中提取出所有让邪恶的一方感兴趣的数据。是的，这样的查询需要很长的时间（这也是盲目的SQL注入最出名的地方之一），但请记住，时间，尽管它可能是可悲的，可能不会阻止一个攻击者，他的目的是尽可能地伤害你的系统或窃取你的所有数据。
一些网络应用程序甚至可能过滤GET或POST参数中的部分，这意味着他们可能会 "捕捉 "正在使用的单引号或双引号，但这只是难题的一个部分而已。这样的功能经常是网络应用程序防火墙类型的一部分--我们已经在另一篇文章中讨论了WAFs（网络应用程序防火墙的简称），所以我们不会说得太详细，但请记住，网络应用程序防火墙可以抵御各种攻击，从拒绝服务到，你猜对了，SQL注入。
盲目SQL注入的类型
有两种类型的盲目SQL注入 - 基于布尔的和基于时间的。基于布尔的盲目SQL注入依赖于向数据库发送某个SQL查询 ，通过查看应用程序的响应来确定查询是否返回TRUE 或FALSE ，而基于时间的SQL注入则依赖于时间--探测Web应用程序的基于时间的盲目SQL注入的查询将迫使数据库在返回响应之前等待几秒钟，如果响应是在确切的指定秒数过去之后返回，攻击者将能够确定该应用程序容易受到基于时间的盲目SQL注入。下面是这两种类型之间的几个主要区别和相似之处：
| 盲目SQL注入的类型 | 关键方面 |
|---|---|
| 基于时间的 | 依赖于Web应用程序的响应 |
| 基于布尔的 | 依赖于网络应用程序的响应 |
| 基于时间的 | 依赖于时间 |
| 基于布尔值的 | 依赖于网络应用的 "外观"。 |
| 基于时间的 | 通常很慢，因为需要时间来确认每个查询是否正确执行 |
| 基于布尔值的 | 通常很慢，因为需要花时间以可视化的方式评估应用程序的反应 |
| 基于时间的和基于布尔的 | 通常通过采用基本的安全措施来预防，如准备好的语句、输入验证、执行最小权限原则等。 |
防范盲目的SQL注入
与流行的看法相反，防止盲目的SQL注入并不需要太多的技巧或努力--它可以通过基本的安全措施来防止。是的，就这么简单!我们可以通过在 PHP 中使用准备好的数据对象（PDO）来实现（它们将用户提供的输入和查询的其余部分分开，因此任何类型的SQL注入都是不可能的），通过使用自动测试解决方案来告知我们我们的应用程序是否容易受到SQLi的影响，或者，当然，使用白名单安全控制--我们，作为开发者，应该有一个习惯，即过滤和净化每一种以某种方式与我们数据交互的参数。通过这样做，我们可以把我们的Web应用程序放在下一个安全级别，既可以防止各种SQL注入攻击和其他类型的安全问题。
一旦我们把我们的网络应用程序放在下一个安全级别，我们也必须照顾到我们自己账户的安全 - 我们可以通过BreachDirectory进行搜索，看看我们的任何账户是否处于风险之中，并根据给我们的建议采取行动。一旦我们这样做，我们的账户也应该是安全的。双赢!
盲目的SQL注入是一种类型的SQL注入，攻击者无法弄清楚我们的网络应用程序是如何 "思考 "的，因此，他或她必须依靠网络应用程序给我们的输出或依靠时间，这取决于使用哪种方法（基于布尔或基于时间）。当依靠基于布尔的SQL注入时，攻击者依靠的是网络应用程序可能看起来与平时不同的事实，而当使用基于时间的SQL注入时，攻击者主要依靠的是时间。
无论攻击者选择使用哪种类型的SQL注入，都不能为攻击者提供快速获取数据的方法--攻击者可能真的要花几个小时、几天甚至几个月的时间来获取他感兴趣的数据，但一旦攻击成功，这些数据通常会在暗网上以数千美元的价格卖给其他邪恶势力，这样的循环还将继续。
为了防止盲目的SQL注入，确保采用安全的编码方法，不要将用户的输入直接转入数据库，并完善你的网络应用程序中的错误返回方式。
此外，确保通过已知的数据泄露搜索引擎进行搜索，以确保你的数据在白天和晚上都是安全的，直到下一次。在下一篇博客中见!
