这导致以下输出:

SELECT * FROM users WHERE username="admin" AND SLEEP(10)#" AND password="superSecretPassword"

这对几乎所有形式的 SQLi 都是脆弱的。

我想我的问题是:

a) 为什么您会选择执行基于时间的 SQL 注入而不是任何其他注入方法,因为基于时间的注入需要这么长时间并且可以说比其他方法更容易检测到?

b)(在这种情况下运行 SQLMap 或类似工具)其他方法如何失败,但存在基于时间的 SQL 注入?

1个回答

它与“常规”盲注 SQL 注入在价值上没有区别,只是利用方式不同。

基于时间的唯一真正原因(当然,除了学习之外)是其他类型的 SQLi 不可用。同样的原因,您会使用“常规”盲 SQLi,而不是常规 SQLi。

“常规”盲 SQLi 依赖于取回一些价值,即使它只有一点点不同。很容易想象一个零位直接泄漏的场景,例如,一个应用程序清理响应,无论数据库中发生什么,都返回一个静态响应。

在这种情况下,Blind SQLi 将无济于事。因此,您被迫以其他方式取回那一点信息 - 即时间延迟。现在,基于这一间接信息,其他盲 SQLi 技术可以介入。

因此,以相反的顺序回答您的直接问题:

b) 其他方法如何失败,但存在基于时间的 SQLi?

因为应用程序不会直接返回任何信息,即使它是可注入的。

a) 为什么您会选择执行基于时间的 SQLi 而不是任何其他注入方法,因为基于时间的注入需要这么长时间并且可以说比其他方法更容易检测到?

因为(b)。

其它你可能感兴趣的问题
上一篇TeamSpeak 3 中身份的“安全级别”是如何实现的? 下一篇如果我还是自签名,使用 CA 是否更安全?