XID required for POST requests to action URLs?

Thanks Derek. I agree with you, security needs to be the highest concern. Difficult decision.

Hey Guys,

We’ve mulled this over and the conclusion was that since ajax provides a good measure of baseline security (albeit not perfect), we’re going to temporarily make this opt-in for ajax action requests until we can either make the XIDs more persistent or fully automate the refresh.

My gut reaction for implementation is to have the action receiving class implement a marker interface. So something like this:

class Channel_form implements Strict_XID {

Name pending, but it’s possible that the future default solution will have a reusable xid that would expire after a certain amount of time, so the strict name would still make sense to upgrade the behavior to the single-use token.

We also have a number of gateways that use ACT urls to communicate from the IPN. I’m assuming these would be broken as well by the new XID requirement.

i have a similar situation with some custom API’s using ACT url’s.

I think for those complete opt-out cases it makes more sense to control them per action, since you might have actions in that same class that you want to keep protected. So that will probably end up as a flag on the actions table.

If you have any questions or concerns about implementation, please don’t hesitate to give me a shout. As with all security related things, understanding it and getting it right are not optional.

Thanks Pascal…. Any idea when a preview of this will be available? This effects so much of our shopping experience that I would really like to start testing it as soon as possible.

I’m seeing in Beta 3 that you have added the ‘csrf_exempt’ field to actions and the default is 0. So essentially the use case here is that if you have something like an auto suggest thats going to fire a lot, you’d set it to 1 when inserting actions, otherwise all actions require a fresh XID?

Where does your idea of the exempt class come into play here or is that idea at the wayside for the moment?

So essentially the use case here is that if you have something like an auto suggest thats going to fire a lot, you’d set it to 1 when inserting actions, otherwise all actions require a fresh XID?

Correct - you would basically set that to 1 in instances that either won’t have an XID (payment gateways) or that don’t need an XID check (search, autocomplete, etc). It defaults to 0, because asking people to turn something on is generally not a reliable security strategy.

Where does your idea of the exempt class come into play here or is that idea at the wayside for the moment?

The idea was to allow a module to request strict XID checking on frontend ajax requests. The exploit is complicated and an edge case, so most of the time not checking on ajax requests is fine. If your code deals with something like credit cards, you would want the check to run. I’m not sure if we wouldn’t be better off with another column though. Seems inconsistent.

Hey Guys,

What happened to the field in the actual release of 2.7? We can’t use any of our IPN or API callbacks and are getting invalid action id errors on all callbacks. Is there a different methodology now?

Best, David