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?
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.
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!