OWASP - 认证测试

一、凭证加密隧道传输测试

客户端在以下四种情况中会收发认证凭证：

1.客户端发送凭证以请求登录
2.服务器带session token响应成功登录
3.认证过的客户端发送session token请求来自站点的敏感信息
4.忘记密码时，客户端发送token到站点

传输过程中如果不对认证凭证进行加密，就能让攻击者使用嗅探工具捕获它们并很可能用来窃取用户账户。
攻击者可以使用像Wireshark之类的工具嗅探传输，或者建立一个代理服务器抓取HTTP请求。

但事实上传输数据被加密并不是百分百安全的，也依赖于使用的加密算法和应用口令的强壮程度

测试目标

• 评估任何致使站点或者应用未经加密而交换凭证的情况

如何测试

抓取客户端和服务器间需要凭证的传输过程。 在登录和使用有效session的时候，检查被传输的凭证。

1. 部署和使用抓取传输过程的工具
2. 关闭所有主动选择HTTPS传输的功能或者插件，一些浏览器或者扩展比如HTTPS Everywhere，会通过重定向HTTP跳转到HTTPS来防止强制浏览(Forced Browsing)

在捕获到的传输过程中寻找如下敏感数据：

• 私钥密码或口令，通常在消息体部分中
• Tokens，一般包含在Cookies中
• 账户或者密码重置验证码

登录和创建账户

如果登录页面是通常的HTTPS，那么尝试去掉后面的s再访问。

如果服务器为session token返回一个Cookies信息，那么Cookie应当包含Secure属性来避免客户端在未经加密的通道中暴露它，数据包示例如下：

Request URL: https://www.example.org/j_acegi_security_check
Request method: POST
...
Response headers:
HTTP/1.1 302 Found
Server: nginx/1.19.2
Date: Tue, 29 Sep 2020 00:59:04 GMT
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID.a7731d09=node01ai3by8hip0g71kh3ced41pmqf4.node0;Path=/; Secure; HttpOnly
ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE=dXNlcmFiYzoxNjAyNTUwNzQ0NDU3OjFmNDlmYTZhOGI1YTZkYTYxNDIwYWVmNmM0OTI1OGFhODA3Y2ZmMjg4MDM3YjcwODdmN2I2NjMwOWIyMDU3NTc=; Path=/; Expires=Tue, 13-Oct-2020 00:59:04 GMT; Max-Age=1209600; Secure; HttpOnly
Location: https://www.example.org/
...
POST data:
j_username=userabc
j_password=My-Protected-Password-452
from=/
Submit=Sign in

密码修改、重置或其他操作账户的行为

像在登录和创建账户的版块一样，如果站点有允许用户修改账户或者使用凭证调用不同服务的功能的话，请验证这些交互都是基于HTTPS的，有包括以下的交互行为用以测试：

• 允许用户处理忘记的密码或者其他凭证的表单
• 允许用户编辑凭证的表单
• 需要用户使用其他渠道来验证的表单(比如说支付过程)

登录后访问资源

在登陆后访问所有的功能，检查是否有未经加密的凭证传输（session tokens，Cookies）

二、对预设凭证的测试

测试目标

• 枚举具有默认凭证的应用并确认他们是否存在
• 审查和评估新创建的用户，以及他们是否以任何预设或者可识别的模式创建

如何测试

• 尝试使用对应系统的默认凭证
• 用空密码尝试每个可能的用户名
• 审查HTML中的注释
• 审查Javascript，寻找涉及到的用户名和密码还有后台地址等敏感信息
• 对比有效和无效的登录请求和返回消息，可能发现隐藏参数或者其他有意思的GET请求
• 可以结合找回密码方式，使用收集到的联系方式中的名字进行组合尝试(制作社会工程学字典)

相关资源：
四千个厂商默认账号密码、默认登录凭证汇总

三、测试账户锁定机制

测试目标

• 评估账户锁定机制对暴力破解的削弱能力
• 评估解锁机制对未授权账户解锁的防御能力

如何测试

锁定机制

• 测试账户锁定阈值
• CAPTCHA缺陷：
• 1. 太过简单的验证，比如算术或者有限个的问题集
  2. CAPTCHA只检查HTTP响应码，而不是响应成功
  3. CAPTCHA服务器端默认为成功处理
  4. CAPTCHA验证结果不经过服务器端确认
  5. CAPTCHA输入处被手工处理，或被不正确地验证或绕过（逃逸）
• 评估CAPTCHA作用效果：
• 1. 根据难度尝试自动化处理CAPTCHA验证
  2. 尝试不在用户界面完成验证而直接提交请求
  3. 尝试故意提交一个导致验证失败的请求
  4. 尝试不完成验证(假设有默认值被客户端代码传递)，使用测试代理服务器提交请求（请求被直接提交到服务器端，即检测绕过前端验证的可能性）
  5. 尝试使用常规的注入payload或者特殊字符序列来fuzz下CAPTCHA数据入口点(如果存在)
  6. 检查CAPTCHA的答案是否可以是在相关的hidden field里的替代文本(图片，文件名，值等)
  7. 尝试重新提交之前已知通过的请求
  8. 检查清除Cookies是否会导致CAPTCHA被绕过(比如，CAPTCHA只在几次登录失败时出现)
  9. 如果CAPTCHA是几个步骤中的一部分，那么尝试直接访问或者完成在CAPTCHA之外的一个步骤(比如说如果CAPTCHA是登录过程中的第一步，那么尝试直接提交第二步[用户名和密码])
  10. 检查可能没有强制CAPTCHA验证的替代方式，例如为使移动设备更便利设计的API访问点

解锁机制

该部分的总结省略，但在测试过程中不可省略。

四、认证架构绕过测试

测试目标

• 确保认证程序在需要它的服务上都被应用

如何测试

黑盒测试

• 直接访问(强制访问)
• 参数修改
• Session ID 生成
• SQL注入

灰盒测试

比如说拿到一段源码(原文的没看懂就改了一下)：

if (isset($_COOKIE[$cookiename . '_sid']) {
     
    $sessiondata = isset($HTTP_COOKIE_VARS['_data']) ? unserialize(stripslashes($HTTP_COOKIE_VARS['_data'])) : array();
    $sessionmethod = SESSION_METHOD_COOKIE;
}
if(md5($password) == $row['user_password'] || $sessiondata['active']) {
     
    $autologin = (isset($HTTP_POST_VARS['autologin'])) ? TRUE : 0;
}

这个时候传Cookie：

a:2:{s:11:"active";b:1;后面的内容}

就可以绕过认证机制了。

五、Remember Password测试

测试目标

• 确认生成的session被安全地管理并且没有把用户的凭证置于危险境地

如何测试

• 通过编码形式将凭证存储在浏览器存储机制中，这可以通过接下来的web storage testing scenario和浏览session analysis方案。凭证不能以任何方式被存储在客户端并且应该被服务器端生成的tokens替代。
• 自动注入可能被点击劫持(Clickjacking)和CSRF的用户凭据
• 检查Tokens的过期机制

六、浏览器缓存测试

测试目标

• 审查应用是否将敏感信息存储在客户端上
• 审查是否会出现未授权访问

如何测试

浏览器历史

输入一些敏感信息然后登出(log out)，再点击后退，如果页面包含敏感信息，那么意味着应用没有禁止浏览器将其缓存下来，可以通过如下方法阻止浏览器缓存敏感数据。

• 使用HTTPS传输页面内容
• 设置 Cache-Control: must-revalidate

浏览器缓存

核实在每个包含敏感信息的页面，服务器都命令浏览器不要缓存任何数据。 服务器可以在HTTP响应头中发出如下的指令：

• Cache-Control: no-cache, no-store
• Expires: 0
• Pragma: no-cache

这些指令通常都是很强壮的，尽管为了持续保护系统上的文件，额外的标识可能是必须的，这些标识包括：

• Cache-Control: must-revalidate, max-age=0, s-maxage=0

HTTP/1.1:
Cache-Control: no-cache

还有

HTTP/1.0:
Pragma: no-cache
Expires: "past date or illegal value (e.g., 0)"

一些缓存路径：

• Mozilla Firefox:
  • Unix/Linux: ~/.cache/mozilla/firefox/
  • Windows: C:\Users\\AppData\Local\Mozilla\Firefox\Profiles\\Cache2\
• Internet Explorer:
  • C:\Users\\AppData\Local\Microsoft\Windows\INetCache\
• Chrome:
  • Windows: C:\Users\\AppData\Local\Google\Chrome\User Data\Default\Cache
  • Unix/Linux: ~/.cache/google-chrome

审查缓存信息

火狐中可以使用about:cache来检查缓存细节
对于其他浏览器可以使用相对应的扩展或者外部软件。

检查对移动设备浏览器的缓存处理

在移动浏览器上，对缓存指令的处理可能完全不同。所以，测试者应该在无缓存的情况下建立一个新的会话，并在例如谷歌浏览器的开发者模式(Device Mode)下或者在火狐浏览器的Responsive Design Mode对以上内容重新测试。

七、弱密码测试(略)

八、弱安全问题测试(略)

九、密码修改或重置功能测试

PS：这部分多看大佬们实战SRC的文章，姿势太多了。

测试目标

• 确定应用对允许用户修改账户密码的账户修改过程的破坏行动的抵抗强度
• 确定密码重置功能对猜测或者绕过的抵抗强度

如何测试

对于重置或者修改密码包括如下重要的几点需要检查：

1. 除了管理员之外的用户可以修改除了他们自己的密码外的其他账户密码
2. 用户可以操纵或者破坏重置或修改密码的过程从而修改其他账户或者管理员的密码
3. CSRF(懂的都懂[doge])

十、测试其他更脆弱的认证渠道

直接放原文，学java去了(我太菜了)
Testing for Weaker Authentication in Alternative Channel