今天也是阳光明媚，昨天讲的Sql注入专题让梨子醍醐灌顶，从此对网络安全充满了兴趣，一个小小的可控参数就能造成这么严重的漏洞，这是多么的神奇，于是梨子今天早早地背上了小书包来到了教室，准备学习今天的身份验证专题，快搬好小板凳学起来吧！！！

声明

该系列共三篇，25个专题，前21个专题的大部分内容已于2021年7-9月首发于安全客，由于某些原因，该系列后续更新部分梨子打算转投Freebuf社区(下称"社区")。因后续更新部分的部分内容为前21个专题中的，故在转投社区时会将更新部分一并加入对应的专题中，所以会与发布于安全客的版本略有出入，会更完整，望周知。

本系列介绍

PortSwigger是信息安全从业者必备工具burpsuite的发行商，作为网络空间安全的领导者，他们为信息安全初学者提供了一个在线的网络安全学院(也称练兵场)，在讲解相关漏洞的同时还配套了相关的在线靶场供初学者练习，本系列旨在以梨子这个初学者视角出发对学习该学院内容及靶场练习进行全程记录并为其他初学者提供学习参考，希望能对初学者们有所帮助。

梨子有话说

梨子也算是Web安全初学者，所以本系列文章中难免出现各种各样的低级错误，还请各位见谅，梨子创作本系列文章的初衷是觉得现在大部分的材料对漏洞原理的讲解都是模棱两可的，很多初学者看了很久依然是一知半解的，故希望本系列能够帮助初学者快速地掌握漏洞原理。

服务器端漏洞篇介绍

burp官方说他们建议初学者先看服务器漏洞篇，因为初学者只需要了解服务器端发生了什么就可以了

服务器端漏洞篇 - 身份验证专题

什么是身份验证？

身份验证，顾名思义，就是验证你是不是你，身份验证的因素可以归结为以下三个类别

• 所知，即密码啊，安全问题啊之类的保存在你记忆里的信息

• 所有，即手机或验证码等你拥有的东西，那这时候有人就会有疑惑了，那密码也是我拥有的呀，为什么不算是这个层面的呢，这里的所有主要偏向于物理层面的，大家有这种疑惑的原因就是这个验证码，那么大家想一下，你用什么接收验证码，手机或者什么设备对吧，其实讲手机也不是很严谨的，实际上验证码是因为你拥有一张独一无二的SIM卡，然后验证码才会发到装有这张手机卡的手机里，而不是别人的手机里

• 所是或所做，即你的生物特征或行为特征，生物特征很好理解，就是指纹啊，面部特征啊这些的，行为特征呢，就类似一些你的生活习惯，比如步态之类的，但是目前的技术来看，应该还是没办法用步态去做身份验证的。

身份验证(authentication)和授权(authorization)有什么区别呢？

其实很多人到现在都很容易弄混这两个词，因为都是auth开头的，然后又都和用户有关，所以我们就简单带大家区分一下这两个概念，我们前面讲了，身份验证就是验证你是不是你，而授权呢，是允不允许你做哪些事

身份验证漏洞是怎么产生的呢？

一般来讲，身份验证漏洞一般由两种情况产生

• 一种就是攻击难度比较容易的暴力破解，往往是由于受害者的账号或密码太简单导致的

• 另一种的危害就很大了，就是由于某种逻辑设计上的缺陷导致攻击者可以直接绕过身份验证机制，burp称之为有损身份验证

身份验证漏洞会有什么危害呢？

身份验证漏洞的危害可能非常严重。一旦攻击者绕过身份验证或暴力进入另一个用户的帐户，他们就可以访问受感染帐户拥有的所有数据和功能。如果他们能接管高权限账号(例如系统管理员)，他们就可以完全控制整个应用程序，并有可能获得对内部基础设施的访问权限。这也太可怕了吧！这可比Sql注入漏洞还严重啊。

基于密码登录中的漏洞

基于密码登录这个很好理解，就是这个应用系统采用什么方式验证你是不是你呢？对，就是假设只有本人才知道本人账号的密码，但是如果通过什么方式知道了某人的密码，那不就可以骗过这种验证机制从而也能登录到这个人的账号吗，下面我们来介绍几种获取方法

暴力破解

暴力破解，也很好理解的，就是如果受害者的用户名或密码是有一定规律或者是比较常见的字符串，那攻击者完全可以把这些可能都尝试一遍，没准就能瞎猫碰上死耗子呢，下面我们将暴力破解分为暴力破解用户名和密码两个小节来讲

暴力破解用户名

一般攻击者会遇到这样的网站，就是使用企业邮箱登录的，但是有的企业邮箱的名头是固定组合的，比如姓.名这种的，就非常容易被攻击者猜到，当然了，如果是使用用户名登录的话，也会有一些比较容易猜到的用户名，如admin或administrator之类的，而且这类用户名往往具有非常高的权限，这就非常危险了
除了这些非常容易猜到的用户名以外还有没有什么办法获取到某些用户名呢，比如泄漏的配置文件中往往可能存在一些用户名，而且往往这些用户名也是属于拥有敏感权限的用户名，所以这也是企业应该注意的地方，还有一些地方也可能会泄漏用户名，比如响应包中，评论区之类的地方。

暴力破解密码

暴力破解密码就是当我们确定了想要暴力破解密码的用户以后，采取各种方法去尝试其密码的可能性，如果应用系统并未强制性地要求用户的密码设置强密码则可能存在使用弱密码登录的用户，这些用户就很容易受到暴力破解攻击，所以我们可以这样设置密码复杂度要求

• 最少字符数

• 大小写字母组合

• 至少一个特殊字符
  以上的复杂度要求虽然不是很严格，但是这样也会增加攻击者暴力破解的难度，当然了，虽然一直都在说密码强度的重要性，但是如果一个企业有成千上万个应用系统呢，也难免会存在一些使用超级弱密码登录的敏感应用系统，所以这里梨子觉得可以根据资产的重要性来设置不同的密码复杂度要求，但是如果这样必定会增加运营者的管理成本，不过相对于资产被攻击带来的损失还是值得的，这里burp介绍了一种人们的习惯，就是虽然安全运营者发布了强制性定期修改密码的规定，但是人们为了方便记忆往往仅对原密码进行较小的修改导致如果原密码意外泄漏，攻击者依然能够通过暴力破解的方式猜解密码，所以还需要在修改密码时对变动的字符部分进行对比，但是梨子觉得这种规定根本不会有人遵守的，所以往往这种机制遭到暴力破解攻击有很大部分是人的因素。

用户名枚举

用户名枚举，就是通过一些特征来判断用户是否为有效用户，比如在注册页面，它会检测你想注册的用户是否已经存在，这个功能在攻击者手里的作用就不是用来注册用户了，而是用来枚举用户名，这样可以为暴力破解密码做铺垫，我们可以从三种信息中实现用户名枚举

• 状态码有的应用程序，如果用户名存在与不存在会返回不同的状态码，通过对状态码的判断，攻击者就能很直观地知道暴力破解列表中哪些用户是存在的。

• 报错信息有的应用程序本意是想通过报错信息提示用户检查用户名或密码的错误，但是可能应用系统提示的太明显，比如用户名有误会提示用户名有误，密码有误会提示密码有误，这就给攻击者可乘之机了，通过这种差异报错信息，攻击者也可以用来枚举用户名。

• 响应时间一个应用程序处理请求都是需要时间的，多个请求处理的时间明显比单个请求处理的时间长，所以攻击者可以利用这种差异来枚举用户名，比如当输入过长的密码时，明显请求的处理时间会大幅度增加等差异。

下面我们将通过以上三种不同类型的配套靶场进行深入理解

配套靶场：通过不同的响应枚举用户名

首先我们把登录请求包发到Intruder中，然后将用户名值设置为payload位

然后我们将burp给的用户名字典装填

然后因为用户名错误还是密码错误的响应状态码是相同的，但是响应包正文会有一点差异，所以我们利用正则功能自动提取爆破结果中的特征值

然后我们就能根据提取出的特征值筛选爆破结果了

我们看到提示密码错误了，这就说明用户名是正确的，于是我们接下来爆破密码，步骤与爆破用户名类似，故忽略，爆破到密码以后，打开响应包就能看到已经成功登录了

配套靶场：通过有微妙差异的响应枚举用户名

解决这道题的方法与上一道题是类似的，唯一的不同就是响应包正文的差异比较微妙，只相差了一个英文句号，眼神儿不好的根本看不出来

我们看到这个差异真的太微妙了，所以这时候正则提取的好处就来了，一下子就筛选出来了，然后我们再利用相同的方法爆破密码就可以了

配套靶场：通过响应时间枚举用户名

这次我们发现不管是用户名错误还是密码错误，响应包正文都是一样的了，但是我们发现响应时间不一样，如果正确的话会相差很多，经过burp提示，我们需要将密码填写的特别长，因为这会增加数据库操作时间从而延长响应时间，经过测试发现它会检测IP，所以我们利用X-Forwarded-For伪造IP，于是我们又一次成功爆破到用户名

嗯？为什么有两个账号，因为另一个是burp给的测试用户，不然我们怎么知道用户名正确的时候响应时间会相差很多呢，爆破到用户名了，我们直接利用之前的方法爆破密码就能登进去了，因为burp的靶场目的都是为了让大家理解漏洞，所以都是比较浅显易懂的，没有任何弯弯绕，所以这里的用户密码都是一定在burp给的用户名和密码字典里的

有缺陷的防爆破保护

burp在这里介绍了两种防爆破保护方式

• 爆破次数过多时锁定目标用户

• 爆破次数过多时拒绝来自该IP的所有请求
  但是这两种方法都有一些绕过的方法，比如一般拒绝来自IP的请求是基于计数器的，如果登录成功，则计数器会重置，那么如果我们在计数器到达阈值之前登录成功一次，然后继续爆破，就可以绕过限制让这种防爆破保护方式失效，不过这种绕过方法前提是得有一个有效的用户名和密码

配套靶场：有缺陷的防爆破保护 - IP阻断

因为三次失败的登录尝试就会阻断IP，但是如果中间穿插登录成功一次测试用户则可以重置计数器，这里梨子将字典用Notepad++之类的编辑器打开，然后查找换行符(n)，然后全都换成n[测试用户名]n，然后就能绕过阻断IP进行爆破，剩余的步骤与之前相同，故省略

锁定用户，因为也是会将"该用户已锁定"之类的字样显示在响应包中的，所以也可以用于枚举用户名
但是仅仅靠锁定用户并不能充分防止暴力破解，因为可能人家只是在测试可用用户而已，比如这样的攻击手段则可能绕过这种防护手段

• 制作一个用户名字典，里面全都是可能被爆破到的用户名

• 制作一个精简的密码字典，里面包含的密码不超过锁定账户阈值，比如失败5次就锁定，那就选五个最有可能的密码做密码字典

• 然后利用Burp的Intruder尝试所有的用户名和密码的排列组合，所有的可能都尝试一遍也不会锁定账户，这样爆破成功以后也还是能登录到对应的账户的

锁定账户这种防护手段也无法防护撞库攻击，因为有些人喜欢将不同网站密码设置成相同的，这就导致如果他们其中一个账户密码泄漏以后可以用来登录其他账户，并且因为只尝试一次而无法触发该防护手段

因为如果账户有效的话则会因为超过设定失败登录尝试阈值而锁定账户，所以也可以用来侧面判断那些账户是有效的，虽然这样做有很大副作用，就是不能继续爆破密码了，但是这一道题只是为了开拓大家的思路，因为要尝试所有的用户名和密码的排列组合，所以我们需要使用cluster bomb这种Intruder模式，剩余的过程与前面相同，略

用户频率限制就是当同一个IP单位时间内请求次数超过阈值就会被阻断IP，然后为了避免是误操作，还会有以下几种比较常见的解除方式

• 在设定的时间间隔后自动解除

• 仅能由管理员解除

• 成功输入验证码后可以解除

有了这种防护手段以后就可以用来防护前面讲到的那种绕过账户锁定防护手段的攻击，但是burp说了，即使这样，也不是完全安全的，好家伙，连环套啊，burp说还是有方法可以绕过的，好家伙，burp在这里介绍了一种方法，就是既然速度快了会被禁IP，那么我们就一次请求验证多个账户，开源节流嘛

我们在burp上追踪登录行为，发现登录请求会以json格式发送用户名和密码，那么我们可以将密码设置成一个数组，让应用系统一个一个比对，我们直接将整个密码字典的密码都怼进去，因为是练习，所以必成，然后我们右键选择Show response in browser，这样就可以直接在浏览器中打开响应包了，前面所有的靶场都可以这么做，嘻嘻嘻，是梨子落掉了没讲，抱歉啦，过程大概就是这样，就不截图了(实际上是梨子刷靶场的时候忘记截了，嘻嘻嘻，小懒虫)

HTTP基础身份验证

这是一种比较古老的身份验证方式，但是对于初学者来说是比较简单的，所以burp也提了一嘴，它是怎么进行身份验证的呢，它在HTTP请求包中加入一个头部字段Authentication，然后这个字段的值呢是将以冒号分割开的用户名密码做base64编码后的字符串，长这样婶儿

Authorization: Basic base64(username:password)

因为base64只是一种编码，所以是可逆的，就导致如果应用程序没有启用HSTS(HTTP严格传输安全性)，则用户的登录凭证就会存在被中间人窃取的风险
而且这种身份验证方式还特别容易遭到暴力破解攻击，因为burp有一个功能可以对填充后的payload自动做base64编码处理
burp还介绍称其还可能遭到CSRF攻击，至于什么是CSRF，梨子后面会讲的哦
所以这种身份验证方式遭到攻击时还是很危险的。

多因素身份验证中的漏洞

什么是多因素，多因素就是同时采用多种因素去进行身份验证，但是很多情况下验证生物因素是不切实际的，因为我们之前介绍过，身份验证的因素只有三种，去掉一个不切实际的，那就只剩下双因素认证(2FA)了，那么剩下的双因素都是哪两个因素呢，就是所知和所有，所知就是前文提到的基于密码登录，所有这个因素的身份验证手段就是采用临时验证码的手段实现的，接收临时验证码的终端只要是能唯一确定一个人即可，比如那种硬件的令牌啊，手机啊，电脑啊之类的设备，但是这时候大家一定会问，那有的二次验证的软件呢，其实这也是基于你唯一拥有的手机这一类设备实现的，采用了2FA机制以后呢，除非攻击者通过各种手段获取到了接收设备或者接收终端的使用权，不然就是安全的，但是！对，"但是"永远不会迟到，这种机制还是存在漏洞的，burp在这里讲到，有一种2FA是伪2FA，就是邮箱验证码，因为邮箱验证码并不能完全保证是唯一拥有的，只要攻击者得到受害者邮箱的密码，那么这种2FA就形同虚设，所以这种2FA并不是真的2FA

双因素身份验证tokens

前面介绍过验证码是通过某种设备接收的嘛，为了提供比较强的安全性，有的网站会为用户提供专门用于接收验证码的设备，比如RSA令牌或者小键盘令牌，这些设备除了具有安全性高的优点外，还有可以直接生成验证码的优点，还有的网站会使用专用的APP，如Google验证器
现在比较常用的方式还有使用手机验证码，其实严格意义上讲，它并不属于所有的范畴里，因为它是由SMS服务发送到用户手机上的，并不是手机自己生成的，这会导致一个什么问题呢，这里burp做了一个非常不太会发生，但是还是有概率的情况，就是既然是通过SIM卡来唯一识别一个人，那谁拿到谁就会被SMS服务认为是本人，所以手机验证码会因为SIM被窃取而被窃取

绕过双因素身份验证

前面讲了，双因素身份验证也是有缺陷的，这里burp介绍了一种情况，就是验证用户名和密码、输入验证码是两个步骤，当用户名和密码通过验证以后，此时其实用户已经是处于登录状态了，所以我们就可以跳过输入验证码的环节直接进入用户界面

配套靶场：2FA的简单绕过

首先我们先登录一下测试用户，因为我们可以查看到发送到测试用户邮箱的验证码，成功登录以后我们记一下登陆成功后的路径

然后我们登录目标用户，但是我们没法看到发送到目标用户邮箱的验证码，所以我们利用前面讲过的知识，直接将路径改成刚才我们记下的登录成功后的路径，发现我们直接成功进入了用户界面

我们就这样成功解决了

有缺陷的2FA验证逻辑

有的时候，应用系统并不会验证用户有没有完成第一步，即验证用户名和密码步骤，下面我们看一下这样一个情况，首先我们先登录一个用户

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

然后呢，应用系统会因为验证通过而分配给用户一个Cookie，并且会进入第二步

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

然后在提交验证码的时候会发出一个这样的请求

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

然后应用系统直接通过Cookie指定的用户去验证验证码，那么这个时候我们要是将其修改成目标用户呢

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

然后如果我们能通过暴力破解的方式攻击，那么很有可能攻击者在不知道目标用户的密码的情况下因为验证码正确而成功登录目标用户，这也太危险了吧，再强的密码也防不住啊

配套靶场：2FA有缺陷的逻辑

我们根据前面讲到的，先登录给的测试用户，然后发现提交验证码的时候Cookie中会有一个verify参数，它的值代表当前要验证验证码的用户名，然后还有一个POST参数mfa-code，就是验证码啦

然后我们开始爆破，10000种组合还是要久一点的，耐心等待一下，然后成功爆破到以后，用之前介绍的方法在浏览器打开响应包，发现已经成功登录目标用户而不需要知道它的密码和接收验证码邮箱的使用权

暴力破解2FA验证码

就像基于密码登录的身份验证机制一样，同样会有一些防护2FA验证码暴力破解的手段，因为一般验证码都是4或6位嘛，如果没有防护手段的话，验证码机制就形同虚设一样
比如有的应用程序会在多少次失败的验证码尝试后自动注销用户，但是！对，burp又来了，burp在这里介绍了一款大杀器，Macro，翻译过来就是宏，就是可以录制一系列的请求序列以实现多步骤暴力破解攻击

配套靶场：使用暴力破解绕过2FA

这一道题目非常重要，要认真听哦，这里梨子相信大家用了这么些年的burp，并不知道burp有这么强力的功能，对吧，嘻嘻嘻，那来了就是赚到了，快点学起来吧，这里如果两次失败的登录尝试就会注销用户，所以我们需要通过录制宏的方式来在注销用户以后自动回到登录界面继续暴力破解，下面请跟着梨子的步骤一起学习如何录制宏吧





大家注意一下哦，就是在add Macro以后会弹出一个框框，里面全都是请求包，大家按照一下顺序依次选中

• GET /login

• POST /login

• GET /login2

然后如果顺序没错的话，点击Test Macro以后大家就会得到如图的效果，它会自动获取csrf令牌交给下面的请求使用，从而不会让操作失效，真的是大杀器啊，所以说配置了csrf令牌也并不能一定防爆破，嘻嘻嘻，然后因为我们要爆破验证码，所以我们把提交验证码的请求发到Intruder中，开始爆破，因为csrf令牌的原因，所以我们需要调整线程数为1，所以这样加上录制的宏，就导致完成一次验证码尝试操作需要4个请求包，就是4s，就我们需要等很长时间才能爆破成功，因为burp的靶场开启以后是有一定的时限(burp说可能是25分钟左右)的，所以可能会出现靶场超时了还没爆破出来，梨子也是尝试了好多次才成功的呢，如果有什么疑问直接在评论区问就好啦，嘻嘻嘻

功夫不负有心人，梨子终于爆破到正确的验证码，然后在浏览器打开响应包，发现成功登录目标用户

其他身份验证机制的漏洞

有的应用系统在提供了基本的登录功能外，还提供了一些扩展功能来管理账户，比如用户可以在忘记密码的时候更改或重置密码，这些功能也是为攻击者提供可乘之机的

保持登录

保持登录功能就是你关闭浏览器以后，账户还是保持着登录状态的，一般是首次登录时勾选了保持登录或记住我时就会开启
这个功能一般会生成一个记住我令牌，然后存放在Cookie中，它的值有的时候是可预测的，比如由用户名和时间戳结合生成的，有的情况居然由密码生成，所以如果构造方式是比较简单的可能会导致攻击者伪造真实的Cookie来欺骗登录
有的应用程序认为只要做了一些变换就觉得是做了加密，但是如果只是使用了类似base64之类的编码，这种加密就是自欺欺人，一样是会被攻击者伪造有效Cookie的，而且即使使用了hash算法也不一定就是安全的，如果攻击者猜出了构造组合方式，然后应用程序仅仅使用了一层hash算法并且未做加盐处理，则也会被攻击者成功伪造出来有效的Cookie的

---

即使攻击者不能通过创建一个用户的方式来观察构造方式，攻击者也可以利用XSS攻击窃取受害者的Cookie来分析构造方式，至于什么是XSS攻击呢，梨子后面会讲的，嘻嘻嘻，先吊着你们，而且，如果目标应用系统采用开源技术开发的话，也可以直接下载开源技术的源码包进行分析
如果应用程序仅对密码做一层hash处理并且未加盐的话，攻击者可能会通过一些网站搜索到相同hash值的密码明文，所以加盐或多做几层hash处理是非常有必要的

配套靶场：暴力破解保持登录Cookie

我们先登录一下测试用户，然后勾选保持登录，抓下登录的请求包

我们发现Cookie中除了session这个必须的参数以外，还有一个stay-logged-in参数，我们发现这个参数的值有点像base64，我们就发到decoder里看一下

我们看到我们的猜测是正确的，发现解开以后是用户名和疑似密码md5值的组合，既然这样，我们就假设我们的猜测是正确的，然后我们将这个请求包发送到Intruder中，对payload做以下变换

因为我们的目标用户是确定的，所以我们可以将其设置为前缀，然后上下顺序就代表着变换的执行顺序，大家不要弄错了哦，但是我们需要提取登录成功的特征，所以我们这样设置

经过一顿设置以后，就开始暴力破解吧

因为我们设置了特征值提取嘛，所以我们很快定位到了登录成功的响应包，在浏览器打开发现登陆进去了

配套靶场：离线密码破解

因为上面介绍到可以利用XSS窃取受害者的Cookie，所以我们在提供的服务器里面构造payload

大概的作用就是受害者遭到XSS攻击以后将cookie附加到URL中发出请求，这样攻击者就能获取到受害者的Cookie了

其实这个构造方式和上面一道题是相同的，只是演示一下这种攻击方式，解了base64以后，我们拿着密码去那种在线网站查一下看看能不能查到对应的明文，一般弱密码都能查到的

好，我们查到以后就能登录到目标用户了，非常简单

重置用户密码

有的用户记性不太好，所以应用系统就提供了重置密码功能，但是这种功能验证用户身份方式存在漏洞，就导致可能攻击者会冒用受害者身份去重置其密码从而登录其账户

通过邮件发送密码

有的应用系统不会傻到会把当前密码发送给用户，但是他们居然会将生成的新密码发送给用户，梨子在想，这不还是傻嘛
所以burp建议一般不要将永久性的密码直接发送给用户，可以换成将临时密码发送给用户，并且让他在有效时间内更改密码，这样是比直接将密码发送给用户的方式安全很多
burp认为邮箱并不能认为是一种安全的方式，因为有的时候用户的不同设备之间还会自动同步邮件，就会给攻击者可乘之机

使用URL重置密码

比直接通过邮箱更靠谱点的方式就是应用系统将会重定向到重置密码的URL发送给用户，但是这种方式也有它不安全的地方，比如URL仅仅通过URL参数来确定所重置密码的用户，啊这，这感觉也很危险啊，像这样的

http://vulnerable-website.com/reset-password?user=victim-user

从上面来看，仅仅通过user参数来定位，那攻击者就可以仅仅修改参数值来重置任意用户的密码，所以我们可以生成一个足够随机的，难以暴力破解的令牌来代替仅仅通过用户名来定位的方式，例如这样的

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

然后应用程序在后端将token值与用户绑定，在访问时，验证token是否有效并且开始重置与其绑定的用户的密码，并且建议对token设置一个比较短的有效期，就足够本人操作，又不给攻击者足够时间发动攻击，并且在使用一次后立即销毁，但是呢，有的应用程序并不会强制要求token参数是有值的，就导致我截取对应请求包，然后清空其参数值就导致应用程序不会验证token而也可以重置用户的密码
那么这里有人会问了，如果修复了上述逻辑上的漏洞还会被攻击吗，burp告诉我们，会的，对，就总是有意外，就像上面我们用XSS攻击窃取Cookie一样，我们也可以窃取Token，因为窃取到的Token并未使用，所以Token是有效的，我们依然可以利用窃取来的Token重置受害者的密码

配套靶场：密码重置有缺陷的逻辑

就像我们上面讲的，我们触发一个重置密码的请求，然后清空Token的值，然后将用户名修改成目标用户，密码修改成简单的弱密码，发现也是可以触发跳转的

然后我们跟随重定向，重置密码成功了，然后我们就能用新密码登录目标用户了

配套靶场：利用中间件发动密码重置投毒

我们发现重置密码会将密码重置Token发送Host字段指定的邮箱中，但是我们修改Host为我们的服务器的域并不生效，于是我们可以添加这样一个字段X-Forwarded-Host字段，然后它的值就是我们服务器的域，发现我们接收到了本来应该发到受害者邮箱的密码重置Token，于是我们拦截重置密码请求包，将用户名修改为目标用户

然后我们就会进入密码重置链接，填写窃取到的密码重置Token以后就能成功重置目标用户密码了

更改用户密码

更改密码和重置密码有一点点区别，就是重置密码是旧密码忘了，而更改密码呢，是知道旧密码，所以更改密码的时候需要提供旧密码，应用程序会先验证旧密码是不是对的，然后再更改用户填写两次的新密码
有的应用程序会出现这种情况，应用程序并不强制只能更改当前登录的用户的密码，而是任意用户都可以访问更改密码页面，然后修改某个参数值来定位任意用户从而为更改任意用户密码提供契机，因为应用程序会验证旧密码，所以这个功能会遭受暴力破解攻击

配套靶场：利用更改密码发动密码暴力破解

为了判断旧密码是否正确，我们故意将两次新密码写的不一样，这样当旧密码正确的时候则会提示两次新密码不同，方便我们对爆破结果进行筛选，过程略(才不会告诉你们梨子懒，没有截图呢)，知道用户旧密码以后，还改什么密码啊，直接登录啊

第三方身份验证机制中的漏洞

本节主要内容为OAuth身份验证机制中的漏洞，因为比较复杂，所以梨子打算后面专门做成一个专题来讲，所以这一节暂时不讲，但是不影响大家对身份验证漏洞原理的简单理解哦

如何加固身份验证机制

burp给出了一些关于加固身份验证机制的小建议

留意用户登录凭证

因为如果你泄漏了用户登录凭证的明文形式，那么不管你的身份验证机制多强都形同虚设，所以要保证所有由应用程序发出的请求均采用HTTPS方式，并且将所有HTTP请求重定向到HTTPS请求
还应该检查应用程序的配置文件中存不存在可能泄漏的用户登录凭证

不要指望用户的安全性

因为肯定会有人偷懒，所以建议尽量使用严格的强制的身份验证机制防止有人投机取巧
最有效的方式肯定是设置一个密码强度检查器，比较有名的应用就是由Dropbox开发的JS库zxcvbn，好家伙，这名字起的有点随意啊，就是键盘英文最下面那一行除了m，梨子没有过多地了解这个库，如果有同学有比较了解的，可以在评论区给梨子讲一讲哦

防止用户名枚举

前面有讲过暴力破解嘛，就是对存在的用户发动的，那么如果不让攻击者知道用户名是否存在，可以一定程度地防止暴力破解攻击，比如不管用户名还是密码错误都返回相同的报错信息，并且返回相同的验证码，尽量让响应时间相差不大等等

实施强大的防暴力破解防护

这里建议的方法就是对请求频率过高的IP实施阻断所有来自此IP的请求，然后为了防止通过HTTP头部字段伪造IP，应该要求每次请求都需要输入验证码，虽然这并不能完全防止暴力破解攻击，但是可以在一定程度增大攻击者的攻击难度，试图让其知难而退

再三检查验证逻辑

再三检查验证逻辑非常有必要，往往逻辑漏洞的危害比常规漏洞危害要大，而且利用难度也会更小，所以应用程序架构者一定要再三检查验证逻辑，建议以非常人的角度进行头脑风暴，这样有利于寻找到逻辑漏洞

不要忽视扩展功能

安全防护就是木桶效应，即使你其他的措施做的再好，只要有短板，就会给攻击者可乘之机，所以扩展功能也不能小瞧，比如注册功能啊，忘记密码功能啊，修改密码功能啊，等等

实施适当的多因素身份验证机制

通过前面长篇大论的讲解，我们知道其实短信验证码也不能算是真正是2FA，比较理想的方式就是使用专用来生成验证码的设备或者APP，这样可以极大程度上对身份验证机制进行防护，比较常见的实践就是Steam的验证码生成器，Google验证器，还有Authy等也是非常不错的身份验证器，这些验证器还有一个特点，就是不能随意地重置，需要只有本人知道的救援代码才能重置，而且一个救援代码只能使用一次，还是非常安全的

总结

以上就是梨子去上PortSwigger网络安全学院系列之服务器端漏洞篇 - 身份验证专题的全部内容了，本专题主要讲了暴力破解，绕过身份验证逻辑等常见的身份验证漏洞，同样的，本系列所有文章都只是简单介绍Web漏洞原理，进阶的话需要小伙伴们花费更多时间，精力去学习哦，尤其是逻辑漏洞的发现更是需要非常细心地寻找才能发现，大家对于本节专题有任何疑问可以在评论区讨论哦，嘻嘻嘻！

原文始发于微信公众号（黄公子学安全）：服务器端漏洞篇之身份验证专题