1
goodname 2019-11-05 11:13:35 +08:00
这是典型的越权啊,前端校验会被绕过啊,不改后端的话,请楼下老哥回答吧
|
2
littleylv 2019-11-05 11:18:45 +08:00
如果不需要限制可以看到哪个或哪些用户的详细信息,那这个并没有风险,因为反正你可以看到所有人的信息(反正你可以点列表 id=2 的人看,你通过把 id=1 改成 id=2 去看的方法不是绕一圈没必要么)
如果有限制的话,一定要在后台限制校验传入的 id 是否有权限看 |
3
Graves OP @goodname 我想到了一个骚操作,因为是 jsp,我把列表 list 放到 session 域下面,然后按钮放数组的下标,到了详细页面的时候再 session 域取出列表,根据下标获取 id,不知道这么做会有什么问题
|
5
yikyo 2019-11-05 11:26:30 +08:00
id 加密也可以解决。
|
6
littleylv 2019-11-05 11:29:22 +08:00
@yikyo #5 我也想过后端把 id 可逆加密,前端传进来后解密,但硬要说的话还是有风险。比如 A 用户有权限看到 id=1 (加密成了 ABC ),但 B 用户没权限;但如果 B 用户拿到了 ABC,同样可以去看到 id=1
|
7
maichael 2019-11-05 11:38:00 +08:00
既然能筛出列表就说明有权限,有权限就直接根据权限判断不就好了么,建议直接改祖传代码吧,想办法绕只会挖更多的坑。
|
10
sevenzhou1218 2019-11-05 12:10:40 +08:00
这个跟前端没关系啊,服务器端代码需要改啊。
前端能做的就是传两个参数,id 和 hash,hash 是 id 和 secretKey 加密来的,服务器端再解一下... |
11
imn1 2019-11-05 12:22:43 +08:00
始终要改后端
简单的就是 id 变无序,是 hash 值,这样前端难以碰撞 鉴权才是根本 |
12
harvies 2019-11-05 12:37:59 +08:00
服务器需要校验当前用户是否有查看该 ID 数据的权限
|
13
EminemW 2019-11-05 12:59:00 +08:00 via iPhone
我看到的第一眼竟然觉得没有问题。。用户列表根据 id 查详情,不是正常操作吗。
|
14
iyaozhen 2019-11-05 13:11:55 +08:00
典型的水平越权嘛 老代码有啥改不动的,对比一下传的 id 是不是当前用户的 ID
|
15
shehuizhuyi 2019-11-05 13:28:32 +08:00
根据 session 查
|
16
nnnToTnnn 2019-11-05 16:03:14 +08:00
如果是为了应付渗透测试的人可以很好的解决这个,重写页面传值的那个方法,进行对称加密,例如 aes 等等,你随便找个加密算法,然后在点击的在加上另外一个参数 tempid,传过去,判断 tempid 是否和 id 相等,如果是相等则判断是人为修改。
如果不是 ajax 请求,而是 jsp 请求,直接加上一个 tempid 作为一个暗桩就行了。 如果是为了对付国内的渗透测试水平我觉得问题还是不大的 |
17
nnnToTnnn 2019-11-05 16:04:29 +08:00
@nnnToTnnn 不是 ajax 请求,而是用 request 传参数,基本上 aes 加密都不用,直接留下 tempid 暗桩。等等
|
19
wccc 2019-11-05 17:00:28 +08:00
Strus2? 我在想 jar 升级过没.. 毕竟漏洞挺多的
|
20
goldenalex 2019-11-05 17:09:11 +08:00
胡乱猜测。。。
加个加密 session 比对后传输信息? |
21
iyiluo 2019-11-05 17:22:54 +08:00
别搞自欺欺人的骚操作了,有安全问题就老老实实修,即使应付过了安全扫描,指不定系统哪天就被安全通报
|
22
Graves OP |
23
Graves OP 挺自闭的,以前就听别人说祖传代码多恐怖,现在终于见识了
|
24
wangxiaoaer 2019-11-05 18:40:04 +08:00 via Android
暂时用 hashid 这个库把 ID 转成字符(查的时候再逆回来)这个库支持转的时候加盐,你可以每个用户用一个单独的盐放到 session 中。
|
25
beastk 2019-11-06 08:13:17 +08:00 via iPhone
改代码检验 id 吧,最快的方法了
|