如何防止用户修改他们不拥有的资源? [英] How Do I Prevent Users From Modifying Resources They Do Not Own?

查看:74
本文介绍了如何防止用户修改他们不拥有的资源?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在写一个服务器,其中拥有拥有或具有 @OneToMany 关系的实体 StoreOwner 到一个 Store 实体(一个店主拥有1到N个店铺)。每个 Store 都有 Offer Item ,每个也都有一个 @OneToMany 与商店的关系(一家商店有1到N个商品和1到N个商品)。



I我已经在使用GWT Xsrf保护,每次登录(cookie)后都会与登录用户关联。 strong>关于会话ID的一件事:当用户识别自己输入用户名和密码时,会话ID被置于我的数据库中。无论用户是否被黑客入侵,丢失了笔记本电脑或正确输入了凭据:用户都会以我登录的服务器计数 - 它应该如何知道更好?但是..



有一件事丢失了恕我直言:如果登录(验证)用户发送一个删除请求到ID为他不拥有他不拥有的商店的物品?目前,我在 StoreService 中执行此操作:

  / / StoreService.java 

@Transactional
public ItemDTO deleteItem(String sessionId,long storeId,ItemDTO itemDto){

// sessionId是我放置的cookie我的数据库
//这种方式我想确保我只访问与已登录的商店所有者(基本上是用户)相关联的商店
// $ b $ store store = this。 storeOwnerRepository.getStore(sessionId,storeId);

Item item = ConvertDTO.convertItem(store,itemDto);

//检查我使用cookie得到的商店ID是否与应该删除的商品的商店ID相同的
// ID ID
if(item。 getStore()。getId()== store.getId()){
item = this.storeOwnerRepository.deleteItem(item);
} else {
//如果这不起作用,我们有一个潜在的敌对用户:
throw new RuntimeException(有人试图删除他不拥有的商店的商品? );
}

itemDto = ConvertEntity.convertItem(item);
返回itemDto;
}

这是我第一次尝试编写更大的服务器应用程序,我想阻止用户做这样的事情。



我的问题是双重的:[1]我做的事情真的会阻止登录用户走私ID他不拥有我的服务器的另一家商店?此外,[2]我可以简化这一点吗?



我的问题是随着应用程序的增长,人们可能会 - 每隔一段时间 - (item .getStore()。getId()== store.getId()){/ * .. * /} $>

  b $ b  

当然,我可以将它移入我的 StoreOwnerRepository ,但是我有更好的选择吗? 可以复制会话ID 。任何知道您数据的用户都可以使用上述方法删除资源,特别是如果通过网络将方法作为端点公开时。除非采用某种形式的验证机制,否则传递和使用会话ID是不固有的安全性

在不了解应用程序架构的情况下,只要我能够做出回应即可。



作为恶意用户,我会问:我需要做些什么来造成损害?


  1. 会话ID

  2. 商店ID

  3. 商品结构

  4. 上述所有信息如何发送到后端(XML,JSON等)

知道这些信息,使用某种排序像 Fiddler PostMan ,我可以向您的后端发送虚假请求。

因此,这个问题是上面的问题容易发现,复制有多容易?答案是:可能不那么困难。换句话说,上面的你的实现不会阻止用户做我刚才提到的(再次,不了解你的应用程序)。


Hibernate本身并不是一个安全提供机制 - 它唯一的责任就是ORM。您可以考虑查看 Spring Security - 这可以更好地实现更具扩展性的安全措施。

根据您访问的信息,您需要确定一种最好的方法来防止用户伪造他们。会话ID似乎是可证伪的。

I am writing a server where I have an entity StoreOwner that "owns" or has a @OneToMany relationship to aStore entity (one store owner has 1 to N stores). Each Store has Offer and Item, each also have a @OneToMany relationship with the store (one store has 1 to N offers and 1 to N items).

I am already using GWT Xsrf protection and a session ID that gets associated with the logged in user after each log-in (cookie).

One thing regarding the session ID: The session ID gets placed in my database after the user "identified" himself entering his username and password of course. Not matter if the user got hacked, lost hist laptop or entered the credentials correctly: The user counts as logged in for my server - how should it know better? But ..

There's one thing missing IMHO: What if a logged in (validated) user sends a delete request to the server with IDs of items that he does not own of a store he does not own either? At the moment, I am doing this in my StoreService:

// StoreService.java

@Transactional
public ItemDTO deleteItem(String sessionId, Long storeId, ItemDTO itemDto) {

    // sessionId is the cookie I have placed in my database
    // This way I want to ensure that I am only accessing a store
    // that is associated with the logged in store owner (the user basically)
    Store store = this.storeOwnerRepository.getStore(sessionId, storeId);

    Item item = ConvertDTO.convertItem(store, itemDto);

    // Check if the store ID that I got using the cookie is the
    // same ID as the store ID from the item that should be deleted
    if(item .getStore().getId() == store.getId()) {
        item = this.storeOwnerRepository.deleteItem(item);
    } else {
        // If this didn't work we have a potentially hostile user:
        throw new RuntimeException("Is somebody trying to delete items of a store he doesn't own?");
    }

    itemDto = ConvertEntity.convertItem(item);
    return itemDto;
}

It is the first time that I am trying to write a bigger server application and I want to prevent users from doing such things.

My question is twofold: [1] does what I am doing would really prevent a logged in user from smuggling the IDs of another store he does not own to my server? In addition, [2] can I simplify this a little bit?

My problem is that as the application grows one might - every now and then - forget this check

if(item .getStore().getId() == store.getId()) { /* .. */ }

Of course, I could move that into my StoreOwnerRepository, but do I have better options?

解决方案

It is possible to replicate session IDs. Any user with knowledge of your data could use the above method to delete resources, particularly if the method is exposed via the web as an endpoint. Unless some form of validation mechanism is in place, passing and using the session ID is not inherently secure.

Without knowing more about the architecture of your application, that is about as far as I can take my response.

As a malicious user, I would ask: "What do I need to do to do damage?"

  1. The session ID
  2. The store ID
  3. The item's structure
  4. How all of the above information is sent to the back end (XML, JSON, etc.)

Knowing that information, using some sort of application like Fiddler or PostMan, I could send bogus requests to your back end.

So, the question, then, is what of the above is easily discoverable and how easy is it to replicate? The answer is: possibly not that difficult. In other words, Your implementation, above, does not prevent a user from doing what I have just mentioned (again, not knowing more about your application).

Hibernate itself is not a security providing mechanism - its sole responsibility is ORM. You might consider looking into Spring Security - that better enables more scalable security measures.

Depending upon what information you have access to, you need to determine a way to best prevent the user from falsifying who they are. Session IDs seem to be falsifiable.

这篇关于如何防止用户修改他们不拥有的资源?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆