目录
今日目标
这是什么漏洞？
我的目标是要登录到 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。那么例如 <，在传输的时候，会被转换成 <，也就避免了注入代码执行。
