威胁分析实战

受邀招某银web端的一次威胁分析案例

背景：

偶然接到一次招商银行的邀请分析，既然作为安全测试，那必须的看看邀请的公司的web做的如何啦，当场做个威胁分析，吹牛逼给面我的人听听。以下我直接作为一个威胁分析案例分享给我的读者们。

此处保护一下，由于本人只是威胁分析，没有任何渗透测试行为，以下观点仅代表本人的分析观点，没有任何实际渗透行为，且该文章仅供安全技术讨论。

威胁分析上连招：

• 收集资产信息
• 套STRIED模型
• 分析影响
• 等等

分析目标：

招某银行招聘门户web网站

类型：认证机制风险

风险1：

使用非常主流的渗透测试靶场都在使用的 “安全” jwt的cookie生成方式

抓包拦截后，我们看报文发现该web使用jwt做cookie的认证鉴权，
经常做web靶机题目的同学会发现，这就是靶机里面经常给我们绕过机会的jwt 啊！

Jwt已经被多方证明不安全认证方式，可以直接使用业内已知漏洞直接搜已知jwt key的破解方式，如果加密算法不合规，很容易被破解

好家伙，直接拿用户的个人数据明文作为jwt第一段base64加密。。。

风险2：

比较“直”地数据保护

此处get查询接口直接明文返回我的个人高敏数据（邮箱，电话号码），就像直男的我，非常直接问女孩纸的年龄一样（真的不考虑隐私合规嘛）

风险3：

比较相信用户的“密码输入”
用户什么肯定是没问题的啦，每个用户都是好用户，防爆破机制什么的，不用管啦。

功能点：重置密码区域

我3000多次都无法让你拒绝我，是真爱啊。
此处这么多条，任然没有锁ip/会话，足以证明防爆破失败。
虽然此处密码存在加密，
但是如果我通过其他方法收集到并推导出加密算法之后，
如果我此时又恰好掏出字典库配合社工攻击，请问阁下该如何应对？

风险4：

证书明文打印，可以直接获取

wowo：
此处框架并没有校验cookie，只校验了Authorization字段，且在认证失败后，仍然不会断开连接，会话持续，该下载任然生效

这里利用场景我都不用说了。。。

下面是修改authorization导致的失败场景

重放仍可以生效

类型：信息收集

功能：某下载接口
风险：下载路径直接拼接mac地址，地址可以被大致查出

此处猜测该mac地址为上传人员，使用的oppo手机，即工作人员的手机mac地址。
这是能被通关的关键信息泄露风险哦