响应变参数-挖掘潜在的逻辑越权
开始
对一个网站做测试的时候发现了这样一条请求:
这条请求返回的是个人信息(用户ID、手机号、密码)
{"responseData":{"userid":"用户id","login":"用户名","password":"密码","mobilenum":"手机号","mobileisbound":"01","email":null}}
一开始的想法是变为GET请求(可行),然后增加JSONP劫持的回调参数。。。(失败)
过程
挖不到漏洞怎么办?瞎想,想多了,尝试多了就会有惊喜!后来想到响应变参数的方式。
一开始我尝试的是将返回的JSON内容变为HTTP请求参数的格式,但没成功。
后来一想会不会是因为参数命名格式问题导致的,于是开始了下面的测试。
注意同网站其他请求参数的命名方式
结论:大写、英文
响应变参数
(注意参数值都应为B用户,也就是你需要准备A、B两个用户)
上面所述的返回信息中包含了很多“参数”,可生成如下(这里可以使用我写的一个BurpSuite插件进行转换 - https://github.com/gh0stkey/Json2Dict ):
userid=B用户id
login=B用户名
password=B用户密码
mobilenum=B用户手机号
email=B用户邮箱
整合
B信息+命名规则,最后变成如下的字典:
(F12进入Console使用JavaScript的 str.toUpperCase()
转换成大写字母)
USERID=B用户id
LOGIN=B用户名
PASSWORD=B用户密码
MOBILENUM=B用户手机号
EMAIL=B用户邮箱
结尾
然后Burp Intruder模块开启(使用A用户的凭证去跑),导入字典(这里参数位置在POST请求正文中),Start :
测试结果发现使用LOGIN参数可以成功的从A用户的个人信息越权获取到B用户的个人信息~
评论44次
学到了。改变请求方式,调用callback测jsonp劫持无果。获取影响数据,将数据改成大写形式符合站点要求,测得其中一个参数存在越权
响应变参数,防护方法验证参数
这一大堆操作的意义就是修改了返回参数吗?
学到!总结:1、如果返回json格式的响应,尝试在请求中添加一个回调参数,如callback,来造成一个jsonp劫持。2、B账号响应中的参数,放到A账号请求中作为参数,测试是否越权
很赞!没想过这种思路
看了两遍,还是没有看懂意思
自我感觉我的表达能力还是可以理解的,那么就是师傅你的理解能力有点问题了。sorry
看了两遍,还是没有看懂意思
burpsuite可以直接修改响应参数的
burp自带的修改不能实现这种效果吧
就利用那个A的登录的那个凭证,然后把其中的所有参数换成另一个用户的,去看能否获取B的信息?
emmmm逻辑讲讲代码审计不好吗
我的理解是 发送的请求必要要满足服务端的格式,所以必须要USERID、LOGIN、PASSWORD、MOBILENUM、EMAIL几个参数全部符合规则,然后分别修改这几个参数为另一个用户的信息,尝试是否越权
一些在客户端校验,或者服务端未未二次校验的,改响应包的参数确实有意外收获,但是这种问题一般很少
我理解也是,Burp里面的Do intercept - Response to this request
师傅,最近正在学xi越权的一些思路,这篇文章有个问题问一下:1. 文章是先用a,b两个账户分别获取USERID、LOGIN、PASSWORD、MOBILENUM、EMAIL、这几个参数。2. 然后,在修改A登录状态下,将某一请求中的参数变为B的上面获取到的参数的值,看是否可以访问到B账户对应的信息,这样的话确定存在越权,是这个思路吗?
我理解的也是这样子,,看到响应包后,构造相应包中的参数,去请求另一个账户的信息。
师傅,最近正在学xi越权的一些思路,这篇文章有个问题问一下: 1. 文章是先用a,b两个账户分别获取USERID、LOGIN、PASSWORD、MOBILENUM、EMAIL、这几个参数。 2. 然后,在修改A登录状态下,将某一请求中的参数变为B的上面获取到的参数的值,看是否可以访问到B账户对应的信息,这样的话确定存在越权,是这个思路吗?
一般什么时候会出现这种情况;这时候程序接口一般是怎么写来接收参数的?
学xi了 ,思路确实很奇特
说实话 感觉稍微有点没看明白。。可能我太菜了
首先核心思路是:响应变参数 其次就是准备两个账号 A B ,B的响应变参数放入A用户凭证的请求中 如果A凭证可越权获取B信息,同理也可以获取其他用户信息,遍历下参数就行了。这是越权的测试方法...
还是转换呀,通过那个getUserAuth请求的响应转换成参数啊
明白了!谢谢解答:)
说实话 感觉稍微有点没看明白。。可能我太菜了
首先核心思路是:响应变参数 其次就是准备两个账号 A B ,B的响应变参数放入A用户凭证的请求中 如果A凭证可越权获取B信息,同理也可以获取其他用户信息,遍历下参数就行了。这是越权的测试方法...
请教下老师傅,依照这个思路,用“A的凭证”加上“B的参数”越权,但是B的参数又是在什么阶段获取到的呢?
还是转换呀,通过那个getUserAuth请求的响应转换成参数啊
说实话 感觉稍微有点没看明白。。可能我太菜了
首先核心思路是:响应变参数 其次就是准备两个账号 A B ,B的响应变参数放入A用户凭证的请求中 如果A凭证可越权获取B信息,同理也可以获取其他用户信息,遍历下参数就行了。这是越权的测试方法...
请教下老师傅,依照这个思路,用“A的凭证”加上“B的参数”越权,但是B的参数又是在什么阶段获取到的呢?
思路值得学xi,核心应该是测试时候多考虑get,post的变化