0x02-SQL注入-绕过登陆验证

目录

• 今日目标
• 这是什么漏洞？
• 这个漏洞是怎么造成的？
• 怎么判断漏洞是否存在？
• 如何利用这个漏洞？
• 如何应对？
  • 过滤
  • 校验
  • 编码
• 参考链接

今日目标

这是什么漏洞？

我的目标是要登录到 Bender 这个用户的账户。

Bender 是一个普通用户，要完成这个挑战，必须要猜测该用户的 email 账号，并且这是一个注入的漏洞，而不要去尝试获取该用户的密码 hash，或者尝试爆破该用户的密码，这是一个注入的练习。

跟第一篇文章一样，这还是一个绕过登陆验证的注入漏洞。

这个漏洞是怎么造成的？

开发者在开发登陆流程的时候

• 没有使用 ORM 进行数据库请求，而是直接拼接了请求语句；
• 没有对用户输入做过滤，校验，和编码；

关于第一点，可以参考这一系列文章的第一篇。

关于第二点，在后面的如何应对一节中做说明。

怎么判断漏洞是否存在？

记得在第一篇文章中，说明了判断此类漏洞的方法。通过在输入框中输入单引号，或者双引号，然后查看服务端返回结果，如果返回结果有异样，那么可以判断注入漏洞存在。

如何利用这个漏洞？

在第一篇文章中，我们可以绕过登陆验证，注入之后构造的数据库请求如：

SELECT user_name from Users where email = '' or 1 = 1 -- AND password = ...

由此，我们可以登陆任何用户的账户。

上一篇文章在成功绕过登陆验证之后，admin 账户的邮箱是这样的

那么 bender 用户的邮箱，就可以猜测应该是

bender@juice-sh.op

构造如下用户名，即可完成登陆

bender@juice-sh.op'  -- 

如何应对？

过滤

对于用户输入的过滤，也就是把一些敏感字符直接删除掉。例如，如果用户输入中有 < > 这样的尖括号，直接删除掉。但是这样的方式很粗暴，如果用户并没有注入的意图，只是有使用尖括号的需求，那么用户体验就会很差。

校验

暴力过滤会影响用户体验，那么可以稍做改进。在服务端收到用户输入之后，对用户输入进行一定的校验。我举得正则是比较好的方式，任何符合 <script 的非大小写敏感的模式，如果出现在不该出现的如用户登陆的逻辑当中，做统一的错误处理。

编码

更进一步，对于用户输入，在开始传输的时候，做一次 URL Encode。那么例如 <，在传输的时候，会被转换成 <，也就避免了注入代码执行。

URL Encode 官方文档。

更加详细的防御方法，参见 OWASP 官方文档。

---

参考链接:

• https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection
• https://www.w3schools.com/tags/ref_urlencode.ASP