知识点

1. Java安全-Druid监控-未授权访问&信息泄漏
2. Java安全-Swagger接口-文档导入&联动批量测试
3. Java安全-JWT令牌攻防-空算法&未签名&密匙提取

演示案例

➢Java安全-Druid监控-未授权访问&信息泄漏

Druid未授权访问 漏洞复现 参考链接：https://developer.aliyun.com/article/1260382

简介

• Druid是阿里巴巴数据库事业部出品，为监控而生的数据库连接池。Druid提供的监控功能，监控SQL的执行时间、监控Web URI的请求、Session监控。当开发者配置不当时就可能造成未授权访问漏洞。

发现

• 黑盒：直接访问http://www.xxxx.com/druid/index.htm页面存不存在即可
• 白盒：直接搜全局搜索druid，可以找到配置的登录账号密码

攻击点

1. 直接拼接URL路径，尝试能否直接未授权访问系统功能点。
2. 结合泄露URL路径和Session信息，利用BurpSuite进行尝试登录。
3. 利用Cookie编辑器替换Session，再次访问后台路径尝试进入后台。

➢Java安全-Swagger接口-导入&联动批量测试

简介

• Swagger是一个用于生成、描述和调用RESTful接口的Web服务。就是将项目中所有（想要暴露的）接口展现在页面上，并可以进行接口调用和测试的服务。所以可以对这个接口进行漏洞测试，看是否存在未授权访问、sql注入、文件上传等漏洞。由于接口太多，一个个接口测试的话太费时间，所以一般会采用自动化接口漏洞安全测试。

发现

• 黑盒：url路径常为http://www.xxxx.com/swagger-ui.html
  • 前一天的SpringBoot扫描项目github 地址：https://github.com/AabyssZG/SpringBoot-Scan这个集成了扫描这个路径
• 白盒：直接源码中搜引用即可

测试

1. 自动化发包测试：
   • github地址Postman：https://github.com/hlmd/Postman-cn
2. 自动化漏洞测试：
   • postman联动BurpSuite Xray等
   • 配置：
     1. postman：文件->设置->代理->添加自定义代理配置，代理服务器ip127.0.0.1(自选)，端口配置8080(自选)
     2. burpsuite：添加监听端口8080(和postman代理的端口一样)，配置完这里postman运行集合时的数据包在bp就能看到了
        • 到这一步postman就和bp联动成功了
     3. burpsuite：设置->Network->Connections->Upstream proxy servers->添加ip：127.0.0.1，端口7777(自选)
     4. xray：

        • .\xray webscan --listen 127.0.0.1:7777 --html-output example.html

        • 监听端口和burpsuite设置中添加的Upstream proxy servers一致(测试完成后记得删掉，不然bp数据包会没办法转发)
        • 配置完成后，运行postman接口集成，Bp就会转发请求，Xray就会进行测试接口
   • 我的xray的证书好像过期了，一直报错signature verification failed签名认证失败，所以还没进行测试。
     • 尴尬，不是证书原因，新版one-fox里面xray目录下面有xray_windows_amd64.exe和xray.exe，运行xray.exe就会报上面那个签名认证失败，运行xray_windows_amd64.exe是对的，正常的，同志们注意一下，小迪那个是以前的(或者小迪自己改了名字)，所以直接xray.exe没问题。要是新版one-fox里面的xray里面运行xray.exe不行，要运行xray_windows_amd64.exe，运行成功
       
       

总结

• swagger就是api接口，可以通过这个接口找到更多测试的url接口
• 测试为500，40x之类有的不是没有漏洞，有的是因为请求头还不完整，有的是因为请求数据不完整，后续课程小迪会将怎么修改，完善请求头，从而使测试更加完整精准。

➢Java安全-JWT令牌-空算法&未签名&密匙提取

简介

• JSON Web Token(JWT)。它遵循JSON格式，将用户信息加密到token里，服务器不保存任何用户信息，只保存密钥信息，通过使用特定加密算法验证token，通过token验证用户身份。基于token的身份验证可以替代传统的cookie+session身份验证方法。这使得JWT成为高度分布式网站的热门选择，在这些网站中，用户需要与多个后端服务器无缝交互。
• JWT验证逻辑图
  
  

JWT识别

• 流量特征：用.分隔三部分，前面两个部分头部和载荷的开头为eyJ

JWT构成

1. 标头（Header）
   • Header是JWT的第一个部分，是一个JSON对象，主要声明了JWT的签名算法，如"HS256”、"RS256"等，以及其他可选参数，
   • alg字段通常用于表示加密采用的算法。如"HS256"、"RS256"等
   • typ字段通常用于表示类型
   • 还有一些其他可选参数，如"kid"、"jku"、"x5u"等
2. 有效载荷（Payload）(了解)
   • Payload是JWT的第二个部分，这是一个JSON对象，主要承载了各种声明并传递明文数据，用于存储用户的信息，如id、用户名、角色、令牌生成时间和其他自定义声明。
   • iss：该字段表示jwt的签发者。
   • sub：该jwt面向的用户。
   • aud：jwt的接收方。
   • exp：jwt的过期时间,通常来说是一个时间戳。
   • iat：jwt的签发时间,常来说是一个时间戳。
   • jti：此jwt的唯一标识。通常用于解决请求中的重放攻击。该字段在大多数地方没有被提及或使用。因为使用此字段就意味着必须要在服务器维护一张jti表， 当客户端携带jwt访问的时候需要在jti表中查找这个唯一标识是否被使用过。使用这种方式防止重放攻击似乎让jwt有点怪怪的感觉, 毕竟jwt所宣称的优点就是无状态访问
3. 签名（Signature）
   • Signature是对Header和Payload进行签名，具体是用什么加密方式写在Header的alg 中。同时拥有该部分的JWT被称为JWS，也就是签了名的JWT。
   • 对Header和Payload进行签名，具体是用什么加密方式写在Header的alg中。
   • 同时拥有该部分的JWT被称为JWS，也就是签了名的JWT。
4. 第一部分：对 JSON 的头部做 base64 编码处理得到
   第二部分：对 JSON 类型的 payload 做 base64 编码处理得到
   第三部分：分别对头部和载荷做base64编码，并使用.拼接起来
   使用头部声明的加密方式，对base64编码前两部分合并的结果加盐加密处理，作为JWT
5. 官网在线解析：https://jwt.io/
   BP插件：Hae（这个需要下载一下） 或 JSON Web Tokens(BP插件商店就有)

JWT安全

1. 空加密算法（攻击头部不使用加密）
   • 签名算法可被修改为none，JWT支持将算法设定为"None"。如果"alg"字段设为"None"，那么签名会被置空，这样任何token都是有效的。
2. 未校验签名（攻击签名不使用签名认证）
   • 某些服务端并未校验JWT签名，可以尝试修改payload后然后直接请求token或者直接删除signature再次请求查看其是否还有效。
3. 暴力破解密钥（攻击签名知道密钥实现重组）
   • 针对是对称加密算法（非对称没有用）
   • 非对称要使用方法：获取源码或者公钥私钥文件
   • 某些签名算法，例如HS256（HMAC+SHA-256），会像密码一样使用一个任意的、独立的字符串作为秘密密钥。这个秘钥如被轻易猜到或暴力破解，则攻击者能以任意的头部和载荷值来创建JWT，然后用密钥重新给令牌签名。
4. 其他安全参考：（源码泄漏密匙，Kid注入等）
   https://blog.csdn.net/weixin_44288604/article/details/128562796

JWT利用

利用项目github地址：https://github.com/ticarpi/jwt_tool

使用方式：

• 使用None算法

  python3 jwt_tool.py JWT_HERE -X a

• 自定义修改生成

  python3 jwt_tool.py JWT_HERE -T

• 使用字典破解

  python3 jwt_tool.py JWT_HERE -C -d dictionary.txt

• 指定密码测试

  python3 jwt_tool.py JWT_HERE -C -p password_here

演示案例ctfshow靶场

没ctfshow账号，所以只能看看了

• Web345(None无签名认证)
  • 在官网无法重组，但因为算法是none，所以可以直接base64解密之后把用户改为提示的admin并且访问/admin/即可获取flag
  • 或者若bp中的JWT插件可用，直接在插件中修改即可
• Web346(None算法绕过签名)
  • 官网不支持修改，一改就啥也没了
  • bp插件可以解析，使用bp插件或者jwt_tool工具进行修改
    • 将alg字段算法置空，即设置为None，然后将sub字段设置为admin
    • 将JWT第三部分签名删掉，即第二个.后的内容
  • 修改完成后访问路径/admin/即可获取flag
• Web347(弱口令密钥获取)
  • 使用上一关的方法无法绕过
  • 使用jwt_tool工具爆破密钥，爆破成功后修改密钥为正常值，并修改sub为admin后访问/admin/路径获取flag
• Web348(爆破密钥上题一样)
• Web349（公钥私钥泄露）
  • 公钥私钥泄露，分析源码发现公钥私钥文件路径，访问/private.key /public.key得到公钥密钥
    服务器私钥生成jwt，利用公钥解密jwt，所以使用私钥重新生成一个user为admin的JWT即可

    import jwt
    public = open('private.key', 'r').read()
    payload={"user":"admin"}
    print(jwt.encode(payload, key=public, algorithm='RS256'))

  • python使用import jwt需要安装两个库jwt和PyJWT
  • 将生成的jwt使用post方式(分析源码可知)提交/路径获取flag
• Web350(密钥混淆攻击RS256=>HS256)
  • 将RS256算法改为HS256（非对称密码算法=>对称密码算法）
  • HS256算法使用同一个密钥为所有消息进行签名和验证。而RS256算法则使用私钥对消息进行签名并使用公钥进行身份验证。
    • 所以这里使用RS256的公钥当作HS256的密钥进行加密，服务器解密时仍然使用RS256的公钥进行身份验证，所以可以通过验证
    • 但是我这里有个疑问，虽然公钥加解密确实是这个逻辑，但是一个解密算法是HS256，一个解密算法是RS256，解密结果一样吗？
      • 小迪后面说了，这个解密密钥规定算法，只是使用那个密钥去解密，所以可以换为HS256
  • 将生成的jwt使用post方式(分析源码可知)提交/路径获取flag

黑盒JWT测试

首先找到需要JWT鉴权后才能访问的页面，如个人资料页面，将该请求包重放测试：

1. 未授权访问：删除Token后仍然可以正常响应对应页面
2. 敏感信息泄露：通过JWt.io解密出Payload后查看其中是否包含敏感信息，如弱加密的密码等
3. 破解密钥+越权访问：通过JWT.io解密出Payload部分内容，通过空加密算法或密钥爆破等方式实现重新签发Token并修改Payload部分内容，重放请求包，观察响应包是否能够越权查看其他用户资料
4. 检查Token时效性：解密查看payload中是否有exp字段键值对（Token过期时间），等待过期时间后再次使用该Token发送请求，若正常响应则存在Token不过期
5. 通过页面回显进行探测：如修改Payload中键值对后页面报错信息是否存在注入，payload中kid字段的目录遍历问题与sql注入问题

参考

学习内容均来自小迪安全系列课程：http://xiaodi8.com/