JSRC安全小课堂开课群 Q群：464465695 公众号同步往期文章 京东安全应急响应中心
JSRC审核的核心成员shadowkiller
- 大佬原语
各位师傅好，我是咱们JSRC的现任审核，冒着生命危险来到这里和大家交流，各位大佬手下留情哈
最近很多师傅联系我说漏洞太难挖了，其实完全不是
目前咱们的提交的漏洞大部分分布于web端，其实除了web端还有很多方向可以挖
比如咱们的公众号，小程序，和移动app端
以下思路来源于咱们JSRC的各位大师傅，关键信息已经脱敏
第一点：js文件、源代码泄露敏感信息。
通过js文件可能会发现很多敏感的信息，比如秘钥，用户名和密码，以及一些敏感接口，可以试下这些接口有无权限校验问题。
再者有些接口参数是被加密的，成为阻碍咱们进行测试的一大障碍，js文件里往往会有惊喜
比如下面的这个接口 老实说，看到了这个接口，我可能就没有测试的欲望了
这里的请求参数是被加密的，很难进行测试
我们在浏览器的开发者模式里到了如下js文件
利用该js文件，我们获知了加密方法为AES加密，然后还有有key和iv等
加密模式
并可以对响应包进行解密
这个漏洞比较典型
对响应包里的数据进行解密后会发现是用户MD5密码
正好这里接口有个越权，遍历请求包里的id获取全部用户密码
AES加解密的关键信息都在上面的js文件里，有在线工具
第二点：一些越权问题
越权比较多的就是增删查改各种id
如果遇到多id参数，不方便一一调试，可以替换整个cookie快速测试，确定漏洞存在后再查找漏洞具体参数，这样可能心态会好一点
还有一种是cookie里的越权
比如这种，除了鉴权参数，多出来很多username或者phone这种字段的
就可以特别注意下
很多接口，研发是不走正常套路的
怎么方便怎么搞，所以会有些接口直接替换username就可以越权
还有个实例，虽然很常规，但是很好用
下单时越权引入他人地址id
一个网站的地址编辑保存处一般都会控制的很好
但是下单的时候引入地址的时候非常容易忽视
可以下单不付钱，查看订单详情处能看到别人的地址
3、手机号校验逻辑的问题
3、唯一性校验逻辑的问题
案例：短信轰炸，研发一般会根据手机号对发送短信的频率做限制
后端逻辑有时候这三个会被认为不同的号码，过滤空格后发送短信
也是轰炸
- 下面讲一下漏洞规则评分要点
这个可能大家最关心
越权，SQL注入，信息泄露类，根据当前影响的数据量级及数据敏感性等综合考虑，如果业务刚上线，用户数量级还比较少，可以进行适当提升分数
XSS漏洞：反射型XSS我们会看几个浏览器能复现，以及业务重要程度等方面综合考虑。存储型XSS如果打到后台cookie且能登陆，可以提分的哦
CSRF类，敏感操作的咱么是正常收的，如果不敏感，如修改个头像是不收的
粉丝提问：可以尝试用后台cookie登录吗，（万一打到了的话
可以登录验证下，但是不要再有深入的操作了
有些挂了jdcloud域名的，其实是第三方的服务，这种是按照边缘收取的
粉丝：暗示挖jd.com （补充：新手就不要想主站了，还轮不到咱们）
哈哈，京东可以狠狠地挖一波，奖励多多
- 还有一些常见的典型违规行为，各位师傅可要注意喽
1、得到的弱口令进入系统继续进行测试
2、通过敏感接口给自己添加管理员账号进行测试或者操作敏感接口把xxx产品给下架，这个还真遇到过
3、利用后台cookie登录进行测试，这个也不行哦
3、利用XSS打的的后台cookie深入测试，这个也不行哦
4、测试越权修改了非本人信息或者大量遍历非本人信息
5、开大功率扫描器，把业务扫挂了或者产生大量的脏数据对正常运营可能会产生较大的影响
还有一个风险较高的点，也碰到过：京东云上有部分是和政府合作开发的网站，这种政府网站很敏感的，最好是不要测试
如果已经发现了弱口令，可以找运营或者审核申请测试，我们会和业务进行沟通，具体能不能测还要看业务那边的回复