修改用户信息时，故意将隐藏的id改成其他人的，然后提交，这样的问题怎么解决？
0
悬赏园豆：140
[待解决问题]
比如：用户小明信息如下：{id:1, userName: ‘小明’, phone:'110'}，小强的信息{id:2, userName:'小强', phone:'120'}
controller 方法如下
@Controller
public class UserController {
@Autowried
private UserService userService;
@RequestMapping("/update")
public String update(User u) {
userService.update(u);
...
}
}
sql语句如下
update user set
userName=#{userName},
phone=#{phone}
where id=#{id}修改页面如下：
<form>
<input type=“hidden” name="id" value=1 />
<input type="text" name="userName" />
<input type="text" name="phone" />
<button type="submit" value="保存" />
</form>在提交修改信息之前，故意修改隐藏的id，那么这样不就改了其他人的信息了吗？
----
我自己想了一个办法：
每条记录加一个字段 create_by 创建人
在controller的update方法的中，获取当前用户id，并赋给user对象的createBy属性
...
user.setCreateBy(currentUser.getId());
...sql改为
...
update user
set userName=#{userName},
phone=#{phone}
where id=#{id}
<if test="createBy != null and createBy != 0>
and create_by=#{createBy}
</if>
...----
但是感觉这种方法不是很完美。
请教大神，有没有更好的解决方案呢？
所有回答(13)
0
用户信息表里肯定要有个UserID字段呀，当前登录的用户信息里也应该能取到当前的UserID，update的时候，where后面除了id=id，还要加个UserID=UserID，这样就能保证自己改自己的信息了。
你说的 【每条记录加一个字段 create_by 创建人】其实就是我说的UserID的意思，完整的sql是这样的：
update user set 列=列 where id=id and UserID=UserID
0
用户ID不能从前端传输过来的吧
用户登录的时候不是会存储session吗
修改用户信息的时候从session获取用户ID。
0
一般登录的时候会将登录人的基本信息存到session里，有id，name什么的，如果想自己改自己的，那就写个判断语句就好啦，看隐藏域传的id跟session中登录人的id是否匹配
-1
有九种缓存方法，下面这两种最简单
//每次进来先更新sessionStorage
//方法一
sessionStorage.setItem(key, data); //存
sessionStorage.getItem(key) //取
//每次进来先更新localStorage
//方法二
localStorage.setItem(key, data) //存
localStorage.getItem(key) //取
0
将要修改的主键ID加密存储在隐藏域，后端解密获取主键ID
简单点需求可以验证下修改的数据是否是本人的信息（权限认定）
横向越权：横向越权指的是攻击者尝试访问与他拥有相同权限的用户的资源
纵向越权：纵向越权指的是一个低级别攻击者尝试访问高级别用户的资源
如何防止横向越权漏洞：
可通过建立用户和可操作资源的绑定关系，用户对任何资源进行操作时，通过该绑定关系确保该资源是属于该用户所有的。
对请求中的关键参数进行间接映射，避免使用原始关键参数名，比如使用索引1代替id值123等
如何防止纵向越权漏洞：
建议使用基于角色访问控制机制来防止纵向越权攻击，即预先定义不同的权限角色，为每个角色分配不同的权限，每个用户都属于特定的角色，即拥有固定的权限，当用户执行某个动作或产生某种行为时，通过用户所在的角色判定该动作或者行为是否允许。
0
没看明白楼主想问的是啥问题！
0
应该是后台修改数据，然后使用爬虫提交，这个还真不知道咋防
0
楼主应该问的是，我们都是在界面上隐藏域直接赋的用户Id藏着的，但是现在有些软件可以解出来隐藏域的值，如果用户在提交之前改了这个用户Id，是不是就改成其它人的了。
如果是这个意思的话就是肯定的了，比如我现在上班的地方，加班需要填写5天以内的，有次我超过了，就拿工具改了隐藏域的值，正常提交了。。。。
想避免这个就只有做数据加密，或者其它的处理，比如 后台构造数据之前，按照规则或者算法对主键进行加密。前台找不到规律就可以了，后台再加次验证就可以避免这样的情况。
0
1.加解密了解一下
2.其实我们之前遇到过类似的问题，就是手机号和银行卡号显示问题（看来你们要求不严，phone可以直接显示）
我们的解决方案是在把数据给前端时把中间几位数字替换成*，在后端把完整手机号放到内存中，等前端返回数据后通过前端返回的不完整信息匹配内存中的完整信息
3.处理update、create、delete之前验证登录用户session信息和要修改数据的userid是否一致
这样做，手机号那几位数有重复的呢，还有别的信息存在后台跟前端数据进行匹配吗？
0
“createBy” 的解决方案，跟你实际业务逻辑有关。
如果单纯从防修改上来说。可以将ID进行简单的校验。比如，加一个隐藏值 = id 乘于 31 再取反。
当用户提交时，拿到id时用同样的方法进行计算，再比较就知道，有没被窜改过
0
不要在用户界面保留userid或显示userid，前台都是不安全的。登录的时候生成token，也就是随机加密的一串数字，并存在用户表里，通过这个来判断这个用户。
0
现在用token做登录的比较多，redis存储用户登录信息。
0
这么多人在这里断章取义，是我说的不够清楚吗？
本质是数据权限的问题，一个人对 A 数据有修改权限，对 B 数据没有修改权限，现在修改 A 数据时，将 A 数据的标识改为 B 数据的。这种问题怎么防？
