Authentication Bypasses
审计


- 创建AccountVerificationHelper实例,用于处理账户验证逻辑
parseSecQuestions函数的作用是从请求体中遍历参数名,找到包含secQuestion的参数,将其值存入Map中并返回
这里直接把AccountVerificationHelper整个分析一下
/** Created by appsec on 7/18/17. */
public class AccountVerificationHelper {
// simulating database storage of verification credentials
private static final Integer verifyUserId = 1223445;
private static final Map<String, String> userSecQuestions = new HashMap<>();
static {
userSecQuestions.put("secQuestion0", "Dr. Watson");
userSecQuestions.put("secQuestion1", "Baker Street");
}
private static final Map<Integer, Map> secQuestionStore = new HashMap<>();
static {
secQuestionStore.put(verifyUserId, userSecQuestions);
}
// end 'data store set up'
// this is to aid feedback in the attack process and is not intended to be part of the
// 'vulnerable' code
public boolean didUserLikelylCheat(HashMap<String, String> submittedAnswers) {
boolean likely = false;
if (submittedAnswers.size() == secQuestionStore.get(verifyUserId).size()) {
likely = true;
}
if ((submittedAnswers.containsKey("secQuestion0")
&& submittedAnswers
.get("secQuestion0")
.equals(secQuestionStore.get(verifyUserId).get("secQuestion0")))
&& (submittedAnswers.containsKey("secQuestion1")
&& submittedAnswers
.get("secQuestion1")
.equals(secQuestionStore.get(verifyUserId).get("secQuestion1")))) {
likely = true;
} else {
likely = false;
}
return likely;
}
// end of cheating check ... the method below is the one of real interest. Can you find the flaw?
public boolean verifyAccount(Integer userId, HashMap<String, String> submittedQuestions) {
// short circuit if no questions are submitted
if (submittedQuestions.entrySet().size() != secQuestionStore.get(verifyUserId).size()) {
return false;
}
if (submittedQuestions.containsKey("secQuestion0")
&& !submittedQuestions
.get("secQuestion0")
.equals(secQuestionStore.get(verifyUserId).get("secQuestion0"))) {
return false;
}
if (submittedQuestions.containsKey("secQuestion1")
&& !submittedQuestions
.get("secQuestion1")
.equals(secQuestionStore.get(verifyUserId).get("secQuestion1"))) {
return false;
}
// else
return true;
}
}
这里直接定义了用户ID和用户的问题关联并将它们存入了secQuestionStore这个变量
- didUserLikelylCheat函数通过
(用户提交的参数数量)=(参数数量) ( 此条可能会被后面覆盖,但是由于后面参数不存在,检验跳过,所以这里是有用的 )
(用户提交参数名包含所需要参数名)and(对应参数名答案正确)
判断用户是否作弊
- verifyAccount函数和didUserLikelylCheat函数很像,也是通过检查用户参数数量和对应参数答案是否匹配(不同的是这里用的不等于的比较,为后面的绕过留下了余地)
didUserLikelylCheat和verifyAccount两个函数判定过了就能绕过了
这里的核心原理是如果 secQuestion0不存在就会跳过检验, 所以其实如果包含 secQuestion 参数名的数量正确之后,剩下的检验就会全部跳过,所以只要构造两个包含 secQuestion的参数就行了
靶场

Insecure Login
靶场


这里就是简单的拦截请求再填入
审计

login部分,主要是js

function submit_secret_credentials() {
var xhttp = new XMLHttpRequest();
xhttp['open']('POST', 'InsecureLogin/login', true);
//sending the request is obfuscated, to descourage js reading
var _0xb7f9=["\x43\x61\x70\x74\x61\x69\x6E\x4A\x61\x63\x6B","\x42\x6C\x61\x63\x6B\x50\x65\x61\x72\x6C","\x73\x74\x72\x69\x6E\x67\x69\x66\x79","\x73\x65\x6E\x64"];xhttp[_0xb7f9[3]](JSON[_0xb7f9[2]]({username:_0xb7f9[0],password:_0xb7f9[1]}))
}
--->
function submit_secret_credentials() {
var xhttp = new XMLHttpRequest();
xhttp.open('POST', 'InsecureLogin/login', true);
// 发送混淆后的请求
xhttp.send(JSON.stringify({
username: "CaptianJack",
password: "BlackPearl"
}))
}
使用了十六进制编码的字符串数组 _0xb7f9,但请求包中仍然是明文
JWT
理论部分:
技术本质
JWT 是一种基于RFC 7519标准的轻量级安全凭证格式,采用紧凑的URL-safe字符串 形式传输经过数字签名 的JSON数据 。其核心价值在于通过密码学签名机制实现了信息自包含 (self-contained)和防篡改(tamper-proof)的特性。
安全机制
- 数字签名保障:支持两种签名方式
-
- 对称加密 :使用HMAC 算法(HS256/HS384/HS512)+ 服务端密钥
- 非对称加密 :使用RSA/ECDSA 算法(RS256/ES256等)+ 公私钥体系
基本结构
Header.Payload.Signature

-
Header (头部):包含令牌类型和签名算法
{
"alg": "HS256",
"typ": "JWT"
} -
Payload(负载):包含声明(claims),有三种类型:
-
-
Registered claims:预定义声明如 iss(签发者), exp(过期时间), sub(主题)等
-
Public claims:公开定义的声明
-
Private claims:自定义声明
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
-
-
Signature(签名):用于验证消息完整性,创建方式:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
令牌
- 两种令牌类型
-
- 访问令牌(Access):用于向服务器发起API请求,有效期较短
- 刷新令牌(Refresh):用于获取新的访问令牌,有效期较长
获取jwt的流程
在客户端和服务端之间

JWT Claim Misuse
**JWT Claim Misuse(**JWT声明滥用)指的是对JSON Web Token中的声明(payload)部分进行不当或未经授权的操纵行为。
- 未经授权的声明添加
攻击者尝试添加未授权的声明以获取不应有的权限
例如:普通用户添加管理员权限声明
- 声明篡改
修改现有声明的值来操纵身份或权限
例如:修改"user_id"来冒充其他用户
- 过度声明
添加大量不必要或虚假声明
目的可能是增大令牌体积影响系统性能
- 过期时间篡改
修改"exp"声明延长令牌有效期
使攻击者能够维持超出预期的访问权限
- 重放攻击
重复使用已过期的有效JWT
用于冒充原始用户或利用有时限的功能
- 关键声明操纵
如操纵"kid"(密钥ID)声明
可能使服务器使用错误的密钥进行验证
JKU相关漏洞
JKU是JWT规范的一部分,允许通过URL动态获取验证签名所需的公钥。
- 漏洞原理
-
- 当JWT使用弱密钥签名,且JKU指向外部公钥时
- 攻击者可制作恶意JWT并控制验证公钥的来源
- 攻击步骤
-
- 识别JKU端点
- 制作恶意JWT
- 使用自有私钥签名
- 发送给服务器
- 服务器从攻击者控制的URL获取公钥验证
- 攻击成功
- 防御措施
-
- 白名单机制
- 静态密钥
- 增强验证
- 监控审计
- 安全测试
实践部分
jwt_decode
靶场

简单的解密之后提取用户名就行了

审计

判断user值是否匹配
jwt_vote
审计

先找到前端触发vote函数

getvoting函数
- 通过$.get("JWT/votings")从服务端获取投票项列表
- 使用字符串替换方式构建HTML模板
- votesList是前端投票面板的id值
vote函数
- 验证用户是否为"Guest"
- 通过$.ajax POST请求发送到JWT/votings/{title}端点

(Claims)设置
- setIssuedAt设置签发时间(10天后),设置admin和user
jwt签名
- 设置声明(claims)
- 使用密钥签名, 对JWT_PASSWORD进行HS512对称加密
其中:JWT_PASSWORD = TextCodec.BASE64.encode("victory ");//注意密钥
cookie设置
- 将jwt存入cookie
生成claims,jwt,cookie,并返回200 OK
若validUsers.contains(user)判断没过,则清空Cookie值,并返回401未授权

从cookie中获取access_token,如果存在
try {
Jwt jwt = Jwts.parser()
.setSigningKey(JWT_PASSWORD) // 使用密钥验证签名
.parse(accessToken); // 解析 JWT
Claims claims = (Claims) jwt.getBody(); // 获取 payload(声明)
核心
boolean isAdmin = Boolean.valueOf(String.valueOf(claims.get("admin")));
if (!isAdmin) {
return failed(this).feedback("jwt-only-admin").build();
}
else {
votes.values().forEach(vote -> vote.reset());
return success(this).build();
}
从JWT的payload中获取admin字段,如果为true则成功
靶场
在删除时抓包

对token解码

把admin改成true,再输入密钥为上文提到的victory,再放回去

成功
JWT 破解
审计

成功条件是WEBGOAT_USER.equalsIgnoreCase(user)
但是注意到这里的有效时间只有一分钟,要不就快速的,要不就要最后把时间戳换一下
靶场

用脚本爆破密钥

我这里是business
重新替换之后编码输入就行

refreshing token
审计

- 检查用户是否是Tom
- 如果是Tom,额外检查JWT头部的算法是否为none
靶场

让我们让Tom付钱,把token改成tom的

题目给了一个文件,解码发现是Tom的token

拦截一个请求,发现里面有jerry的token


第一反应就是替换,但是肯定没这么简单

果然,认证过期了。
改时间戳,欸嘿,成功了!


JWTHeaderJKUEndpoint
审计


重点在这里生成了一个JWT
Jwt jwt =
Jwts.parser()
.setSigningKeyResolver(
new SigningKeyResolverAdapter() {
@Override
public byte[] resolveSigningKeyBytes(JwsHeader header, Claims claims) {
final String kid = (String) header.get("kid");
try (var connection = dataSource.getConnection()) {
ResultSet rs =
connection
.createStatement()
.executeQuery(
"SELECT key FROM jwt_keys WHERE id = '" + kid + "'");
while (rs.next()) {
return TextCodec.BASE64.decode(rs.getString(1));
}
} catch (SQLException e) {
errorMessage[0] = e.getMessage();
}
return null;
}
})
.parseClaimsJws(token);
- **@Override public byte[] resolveSigningKeyBytes(JwsHeader header, Claims claims):**重写方法,根据JWT头部和声明返回签名密钥的字节数组
- kid从jwt头获得id字段
- 执行SQL查询,根据kid 从jwt_keys表获取对应的密钥
- nTextCodec.BASE64.decode(rs.getString(1));返回base64解码后的密钥字节数组
- .**parseClaimsJws(token);**使用配置的解析器解析并验证JWT
靶场

这里是Jerry想删掉Tom的账户,那可能就要构造一个Tom的token
拦截一个请求把它里面的token解码之后得到

讲密钥设为1并在kid中构造联合注入

在webwolf里搞了很久,发现自己拦截没开,哈哈哈

Password reset
Question
审计

就是获取用户名和答案,再根据用户名对密码进行比对
可以对密码进行爆破
SecurityQuestion
前面部分设置了一些问题和答案

- answer.isPresent():检查是否存在有效答案
这里设置了一个triedQuestion类

就是简单的计数和判断
ResetLink

- String resetLink = UUID.randomUUID().toString();:使用UUID生成随机重置令牌
- 将令牌存储在全局集合中
- 获取主机头信息
- 判断 host 当中是否存在 WebWlof 服务对应的端口与 Host
抓包改一下host

在wobwolf中找到对应请并访问