昨晚上课网安的老师带我们现场挖掘漏洞,可谓是一场视觉盛宴!!!
? <---老师? ? ??我-->
真的没有对比就没有伤害😭😭😭,其间他也分享了一些漏洞挖掘的思路,让我来回顾一下!!
jwt(json_web_token)是一种签名验证机制,其中的header和payload部分都以base64编码,直接进行解码即可,当我们发送数据给服务端的时候,就会包含jwt,这时候我们可以
这样当我们得到密钥之后就可以通过枚举其他的用户名来进行token的伪造
???????????????????????????????? 这个对于CTFer应该不陌生
这句话可以说,说的是太真实了,像sql注入,文件上传,支付逻辑漏洞这种高危的漏洞,不必说,是每一个网安人的梦想!!!? ??
但是,在企业的src,或者护网中,可能一个短信轰炸,验证码复用,任意用户枚举这种一个都可能有一两百米,毕竟如果验证码能被复用的话就话就可能导致能暴力跑字典或者撞库,其对应的危害也是不小的,所以我们不要因为挖不到高危而感到灰心,一些相对较小的漏洞也有可能有很大的危害哦!!😊😊😊
在我们一般的url中,经常可以看见一些参数,如a= r=等等,那么一起来看个例子:
当我们去查询一个语句时我们可以在url里面看见对应的参数
那如果我们双写这个参数呢??就会发现我们的搜索变成了后面的新拼接的参数
这样可能会觉得没什么,但是如果这是一个手机验证码呢?这样是不是就可能发生以前面的手机号码验证,但是确将短信验证码发给了后面的黑客的手机号!!!
对于一些能支付的页面,或者存在账号登录的页面,我们可以考虑创建两个帐号来进行测试!!
像csrf ,越权这种基本上都是需要两个账号进行操作,比如在修改密码处看一下是否存在csrf
又或者在一个号生成的支付订单后,在另外一个号进行订单查询,如果成功就是一个水平越权
??????????????????????????????????????????????????????????????????????????????????????????? ?
其实很多业务逻辑漏洞都是因为对鉴权参数没有进行严格的监管,导致一系列的业务逻辑乱序或者越权都是因为鉴权参数,所以我们在挖洞时候就可以多关注鉴权参数,改为负数?改为0?改为很大的数??反正操作和手段一定要骚
???????????????????????????????????????????????????????????????????????????????????
续接上面的改参数问题,在支付的数量修改中,有时候我们改成0,或者0.1,或者负数是失败的,因为其存在最小值支付,有可能当你改成1元,五元之类,超过其支付接口之后就能完成支付测试了,是不是也是一种思路捏😊😊😊