dongzuoyue6556
2015-06-30 16:20
浏览 139
已采纳

为匿名用户使用CSRF保护是否有意义?

Should CSRF protection be used for anonymous users, or does that defeat its purpose?

I have a URL that can be accessed anonymously. When the URL is accessed with the appropriate information, some values are updated in my database. For example, a client can place some code on their order confirmation page that will make a POST request to http://example.com/save-request with the following data sent:

{orderId: 1234, referralCode: 'ABCDEF'}

When I receive this request, I update the given order in my database with the referral code:

$order = Order::find(Input::get('orderId'));
$order->referral_code = Input::get('referralCode');
$order->save();

I am trying to protect this URL from abuse so that a user can't send requests for random Order IDs and try to get their referral code associated to them.

CRSF protection comes to mind, but that would mean I need to first fetch the token, which would require another public URL. It seems like that would make it slightly harder for abuse, but still possible since the abuser can simply fetch a token, and then make requests as normal.

Are there any strategies to protect against this sort of abuse?

图片转代码服务由CSDN问答提供 功能建议

CSRF保护是否应该用于匿名用户,或者是否会破坏其目的?

我有一个可以匿名访问的网址。 使用适当的信息访问URL时,会在我的数据库中更新某些值。 例如,客户可以在其订单确认页面上放置一些代码,这些代码将向 http://example.com/save-request 发出POST请求,并发送以下数据: \ n

  {orderId:1234,referralCode:'ABCDEF'} 
   
 
 

当我收到此请求时,我更新了我的给定订单 带引用代码的数据库:

  $ order = Order :: find(Input :: get('orderId')); 
 $ order-> referral_code =输入:  :get('referralCode'); 
 $ order-> save(); 
   
 
 

我试图保护此URL免遭滥用,以便用户可以 不发送随机订单ID的请求,并尝试将它们的推荐代码与它们相关联。

我想到了CRSF保护,但这意味着我需要首先获取令牌, 需要另一个公共URL。 似乎这会使滥用稍微困难,但仍然可能,因为滥用者可以简单地获取一个令牌,然后正常地发出请求。

是否有任何策略可以防止这种情况发生 有点滥用?

  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • dosc9472 2015-06-30 16:54
    已采纳

    CSRF is meant to protect authenticated sessions. The basic idea is: the server provides a CSRF token to the client for all authenticated sessions. The client should pass the same CSRF token to the server with each subsequent request. So if a request came without the token, the server should ignore / log it. Your CSRF token should ideally only be passed to the client upon authentication. If there's a separate URL to get the CRSF token, it becomes pointless.

    In your case, since the users are always anonymous at "order confirmation", CSRF protection would not be too applicable. I think the best strategy would be to model the data and your API such that each "order confirmation" is one atomic request with an optional "referralCode". Your API function/endpoint, possibly /confirm-order, can then take referralCode and save it into the Order object, along with any other confirmation processing logic. The API function/endpoint to edit order, maybe /edit-order, should require authentication. Then, the standard CSRF protection applies.

    However, if your intention is to allow anonymous users to change their order details including referralCode, you can mitigate abuse by tracking changes, and allowing only a maximum number of changes. You may also add in some time restriction if it helps.

    打赏 评论
  • drbxr86044 2015-06-30 17:11

    I agree that a CSRF token is not useful for unauthenticated requests but it also makes no harm and adds no extra work (in case of Laravel), so in most cases there are no real reasons to omit it here and there.

    What regards to solution of your problem, try replacing an id of an order with something like a generated random order_number which is much more difficult to guess than a simple id.

    Another solution is something like this:

    $order = Order::where('id', '=', Input::get('orderId'))
        ->where('created_at', '=', Input::get('createdAt'))->first();
    
    if ($order) {
        $order->referral_code = Input::get('referralCode');
        $order->save();
    }
    

    In this case a user has to guess an id and also guess when a particular order has been created.

    And you can also mix both solutions (order_number and created_at).

    It's not a perfect 100% solution but drastically decreases probability of fraud.

    Good luck!

    打赏 评论

相关推荐 更多相似问题