-1

I'm creating a custom e-commerce module for the web application I'm working on. We give to our users the chance to create a module for their sites that will be hosted with us into a domain e.g: http://example.com.

That module has a Javascript interface into user's account administration panel. In order to access to the administration panel, they have to log in with their account into our web application.

They can add products, change e-commerce settings (such currencies), etc. When a product is added or something is modified, calls for an URL into the user's domain, a dispatcher calls for the PHP function (add product, remove product, etc.) and modifies their databases, but if someone knows the handled URLs, can use a REST API Client to send information and it's supposed to work (e.g. sending a product ID to the remove product action). We want to prevent that from happening, because someone could delete the clients products or modify some e-commerce settings.

We thought into using a token stored in the PHP SESSION when the API URL is called, return the token to the AJAX call, then do another AJAX call to the requested function with the given token. When the function is called, compares both tokens and if they are the same, then changes are allowed. Otherwise, they are rejected, but we don't know if this is a "good security" to prevent accessing to the API from outside. Because you can "find" the way to know that you have to call an URL to get an accessing token, then do another call with the given token and perform your destruction.

Thanks in advance. Any information or suggestion will be appreciated.

Regards.

DaGLiMiOuX
  • 889
  • 9
  • 28
  • 1
    Read more on using a [cryptographic nonce](https://en.wikipedia.org/wiki/Cryptographic_nonce). Along with what you're already doing with a unique session token. – apokryfos Apr 13 '16 at 15:51

1 Answers1

1

You could try the following:

  • A user must be logged in to manipulate the database (E.g. add/remove records).
  • When said user logs in, store a token (randomized value) in a session variable $_SESSION['token'] = md5( time() ); // for example
  • Then add a hidden form input (<input type="hidden" name="token" value="<?php echo $_SESSION['token']; ?>">) to be processed with the form that handles the DB manipultation.
  • Add a condition where $_SESSION['token'] == $_POST['token'] must satisfy in order for the desired action to succeed. But of course, make sure to check that $_SESSION['token'] even exists in the first place. if it doesn't, they're accessing your system externally.

This is one way of doing it.

mferly
  • 1,646
  • 1
  • 13
  • 19
  • Yea, that was the first idea. The problem is that the DB manipulation is made through AJAX calls, with jQuery framework, and our forms are implemented into jQuery Dialogs, so when you add a product it is loaded in execution-time and webpage is not reloaded, only the Dialog information retrieved by the API and token should be created again for the next API call, to prevent using the same token again. So we are kinda worried of it is a good practice or not of retrieving a new token when the function finished succesfully. – DaGLiMiOuX Apr 13 '16 at 15:57
  • You can still pass session and form variables (tokens) through AJAX. Then, once complete, you can regenerate those if need-be for the next time. For example, on each page load you can regenerate the tokens. Then, as long as the user is residing on a single page, you just continue to reuse the token until the user jumps to a different page. – mferly Apr 13 '16 at 16:01
  • So there will be no problem, because the token will be stored in the user's SESSION and if you try the same token via REST Client, it should fail, becuase when you call for the function, there is no token generated in the SESSION since you didn't accesed through the web app, am I right? – DaGLiMiOuX Apr 13 '16 at 16:06
  • The tokens being generate at all are strictly dependant on a successful login within the site to begin with. The initial token generation is done within your user login script, once the user has successfully logged in. Then any time you look to regenerate the token (if at all) you must ensure that the user is logged in and that the token has already been set. So yes, if the user is trying to access your service via an external REST Client, they won't be logged in and no `$_SESSION['token']` would have been set to begin with, causing the `if ($_SESSION['token'] == $_POST['token'])` to fail. – mferly Apr 13 '16 at 16:14
  • Okay, thanks for everything :) I'm pretty new into security. – DaGLiMiOuX Apr 13 '16 at 16:15
  • There are a lot of well-documented methods out there, but in the end, it's all about taking a logical approach. You can look further into this approach (called nonce) here: http://stackoverflow.com/a/4145848/3126629 – mferly Apr 13 '16 at 16:18