WebRTC的学习
0-前言
https://cliayn.github.io/WebRTC/test.html
[测试用例,正在优化中]
全锥型 vs 对称型:不需要预测,基本能秒连。
受限型 vs 对称型:需要预测(或者叫端口试探)。
对称型 vs 对称型:预测基本没戏,一般只能走 TURN。
https://cliayn.github.io/WebRTC/test.html
[测试用例,正在优化中]
全锥型 vs 对称型:不需要预测,基本能秒连。
受限型 vs 对称型:需要预测(或者叫端口试探)。
对称型 vs 对称型:预测基本没戏,一般只能走 TURN。
记录fastjson的漏洞的测试心得,更为详细的可以参考大佬的安全笔记Java Web安全
第一步看报错类型。
构建报错类查看报错:{@type:xxx.class,val:xxx.String}等json;
如果是 type not match,通常是顶层类型和接口期望类型不一致;如果是 autoType is not support,说明已经进了 Fastjson 的类型安全检查;如果返回的是业务提示,比如“请输入id”,说明对象已经成功落到业务层。这个区分对定位问题非常关键。你前面的日志已经足够证明:业务类可反序列化,危险类被拦截。
第二步看版本与配置。
优先从代码依赖、jar 文件名、启动参数、fastjson.properties、异常堆栈里确认版本和是否启用了 safeMode。Fastjson 官方文档明确给了三种开启 safeMode 的方式,且 safeMode 打开后会完全禁用 autoType。Fastjson 2.x 则是默认禁用 autoType、以更安全的方式设计。
第三步看“是否存在 AutoType”。
不是只看能不能写 @type,而是看它能不能把类型落到你控制的类上。你这里 GetxxxParam 能进业务层,说明接口的对象绑定链路存在;但 BasicDataSource 被拒,说明高危类型没过安全门槛。
第四步看是否“可绕过”。
可以直接按版本和官方公告判断:1.2.83 之前存在被修复的绕过问题,1.2.68 起有 safeMode;如果目标已经开了 safeMode,autoType 会被完全关闭。
第五步,不能绕过时就做业务类审计。
没有历史漏洞则真正能做的部分:反编译 GetxxxParam(对应的业务类),看 setter、构造函数、字段类型、后续 controller/service 是否会继续调用它的方法。Fastjson 官方也提供了 AutoTypeCheckHandler 这类扩展点,说明很多场景最终要回到应用自己的类型与业务逻辑上看。
工作的时候看到了一个特殊的过滤表达式:(&(objectClass=user)),虽然这个功能并没有起作用,但为了防止下次遇到想不起,还是记录一下;学习文章LDAP注入与防御剖析 - test_user、从一次漏洞挖掘入门Ldap注入、Web漏洞那些事儿:LDAP注入 、 ldap过滤条件语法 等等
因为主要的作用在于过滤,所以不像sql注入、表达式注入那样直接危害系统,但是会根据执行过滤的这个主机的权限导致一些泄露问题。
取自https://hackerone.com/介绍的漏洞类型的整理
分为以下主要类别:
之前用ai结合unidbg操作的有点云里雾里,手似懂非懂,脑子也是什么都没学到,所以单独写一个关于unidbg的笔记,学习视频是大佬的黑盒魔法之Unidbg,课件:《安卓逆向这档事》吾爱破解等