请教一个数据库安全的问题？

  • Z时代
  • 2024-03-15
  • 分类：IT

// 文章表
let tb_list = [
  {
    id: 1,
    content: "好的文章",
    // 属于哪个用户发布的
    userId: 1,
  },
  {
    id: 2,
    content: "好的文章",
    userId: 1,
  },
  {
    id: 3,
    content: "好的文章",
    userId: 2,
  },
];
// 用户表
let tb_user = [
  {
    id: 1,
    content: "用户a",
  },
  {
    id: 2,
    content: "用户b",
  },
];

现在存在一个问题是：
有一个页面获取所有的文章列表，自己发布文章的显示删除按钮，别人的不显示删除按钮

之前的做法是删除接口只传 id 过去就可以删除了
调用一个 del 接口 -http://localhost:8001/del?id=1
但是这样子发现用户在控制台可以看到请求回来的列表数据，能够看到所有的 id
因为知道请求接口，这样子发现会被用户用接口来攻击了，全部给删除了

现在的做法是用 jwt 的方式，加了一个 jwt 的方法在 header 上面，里面把用户的 id 存进去了，后端通过 jwt 可以解析出这个请求是哪个用户，然后删除的时候用 jwt 的 userId 和文字的 userId 对比，如果是同一个就可以删除

但是这个方法感觉有点怪怪的
这样子数据库所有的表都要加上一个可以操作的 id 来作为权限判断
还有一个就是多角色操作，因为这个文章列表，管理员在管理后台也是可以帮助删除的
这样子不是每个数据都要加上一个 adminList 的字段了，并且是个数组，因为管理后台有多个管理员

现在的逻辑就是先判断用户是否匹配，不匹配则匹配管理员，感觉要崩了

因为整个系统还有很多个表，这样子不是要很大量的工作吗 T_T

回答：

让后端拿到id后再校验下当前用户有没有权限就行

回答：

程序员的工作不就是这些吗？
业务需求定义的规则很明确了，表操作麻烦可能是表结构设计不合理，一些附属表可以和主表关联查询，不一定个个都要加userid字段

回答：

用户控制台的sql:
delete from article where userId=1 and id=2
管理员的sql:
delete from article where id=2

回答：

Artical文章表本来应该就有userId字段来表示文章的作者，至于adminList字段则不需要，只要先判断当前用户如果是管理员，则允许该删除操作，否则判断是否为文章作者

回答：

将用户Id和权限(auth)写到JWT的载荷中，每次删除时进行额外的判断。如果你是使用Node来实现服务器，写一个express之类的中间件即可

回答：

登录时保存生成token（加密什么的，唯一性，时效性（两小时有效）），然后进行后台接口调用时，传入token，后台写个拦截器，根据token获取你的id，这样就不需要传id了。

回答：

就你说的，前端的所有限制都可以被懂技术的人绕过，人家发起恶意请求就会出问题，所以用户的请求参数都是不可靠的。

所以数据必然要和用户关联，比如一条文章记录要保存是那个用户的。这个工作量大不大都不是问题，因为这个是必须要做的。

更极端的情况，用户1发布文章,但是给后台的字段中userId字段传递的2。你会不会认为这是用户2发布的文章。
这种情况，就应该对传递的参数中，所以的userId字段，都应该用jwt中的userId重新赋值。

对于删除操作，你可以分成两种接口，一个专门给用户自己用，只能删自己的数据。一个给管理员用，做权限判断，有权限才能操作。

回答：

通过接口和数据的权限两个方面管理。

角色\权限接口数据
管理：可以增删改查所有作者的文章增删改查全部数据权限
作者：只能增删改查自己的文章增删改查仅本人数据权限
访客：只能浏览作者的文章查全部数据权限

角色接口权限
1、通过角色字符权限控制，权限一般分配增删改查等，也可以自定义。
2、每个接口加上权限字符注解。
3、通过token 判断当前操作人所在的角色是否配置有这个权限。
角色数据权限
1、通过token 判断当前操作人所在的角色配置的数据权限范围。
2、如果是“全部数据权限”则直接通过。
3、如果是是“仅本人数据权限”，则通过附加sql，增删改查自己的文章。


以上是 请教一个数据库安全的问题？ 的全部内容， 来源链接： utcz.com/p/944946.html

回到顶部