1

I'm updating a database via PHP with data that's being sent via ajax. Is there a way to tell whether the script that is sending the data is called by the page on which it is included (remotely hosted), or just being hacked into the JS Console by someone who's "inspected my elements" and trying to pull a fast one?

Thanks in advance...

Danny

allnodcoms
  • 1,244
  • 10
  • 14
  • 1
    If they're "trying to pull a fast one" they really can make the request look like whatever they want it to. – Don't Panic Aug 29 '15 at 18:30
  • @Don'tPanic - good point. The content I'm updating isn't going to start any wars or topple financial markets though, so a simple 'Non-Ninja' proof check should do it - if there is one? – allnodcoms Aug 29 '15 at 18:34
  • 3
    You can use a secret key/token via POST request in your ajax script and use the token to verify if the request was authentic or not. – samayo Aug 29 '15 at 18:34
  • @samaYo - I'm using transaction tokens (sent from the server and returned by the script), but they are held as variables, clearly visible in the dev tools, and obviously required (as they are sent by the ajax call). – allnodcoms Aug 29 '15 at 18:37
  • 1
    Agree with @samaYo. and learn more about `Cross-Site Request Forgery` (CSRF) – Jigar Aug 29 '15 at 18:37
  • @Jigar - Any token sent by the server is visible in the network tab, and as a JS variable when stored. This doesn't prevent someone from copy / pasting it into the console and submitting the call from there. – allnodcoms Aug 29 '15 at 18:42
  • @allnodcoms They will be visible, but this does not make them useless. You can use a simple cryptic hash to send and authenticate it. For the user who sees the src, it might seem gibberish, so it won't make any sense to them, let alone to alter it. – samayo Aug 29 '15 at 18:43
  • @allnodcoms one more thing you can do is to validate the request through hostname. Store in the database if the request is from valid/specific hostname. – Jigar Aug 29 '15 at 19:21
  • @Jigar - That's exactly what I'm after, but will the hostname change if the code is edited / entered on a local machine? I can log the calling ip on successful log on, and monitor throughout the session, I just don't know whether that ip would change if the code is modified... Any ideas? – allnodcoms Aug 29 '15 at 19:40
  • @allnodcoms looking for solution in hostname then look at this Q & A's. http://stackoverflow.com/questions/1459739/php-serverhttp-host-vs-serverserver-name-am-i-understanding-the-ma – Jigar Aug 29 '15 at 19:47

2 Answers2

2

There really is no way of telling between either of them, but you can make the job much harder to do.
But since you say that 'it won't start wars', working off of that, there are a few ways of 'securing' it.

Step 1 : Creating 'Verification' calls
If you aren't already, the very first step would be to implement a few preliminary AJAX calls that retrieve certain variables which are later used in the calls that follow, for example:

  1. Call #1 Retrieves Security-Token
  2. Call #2 Creates a cookie Security-Token-2
  3. Call #3 Call to your php script with Security-Token encrypted with Security-Token-2

What your page would then do, would decrypt the sent text with the 'token' stored in the cookie and use that.

Step 2 : Adding extra logic into javascript
You can add some encoding-decoding logic into the javascript,
I'm not saying this is going to be hard to break, but It might be tough, especially if you obfuscate your code (We all know obfuscation is no good, but bear with me)

Step 3 : Don't keep any names
Another thing you can do is remove all the names from the AJAX variables, or better yet, the names can be different every time.
If you want to go even further, you can encrypt the names, and plus to the encryption add a component of randomness by introducing an IV, and storing the IV in the cookies (maybe even encoded for added security).

(EDIT) Found the 'dynamic name generation' solution I was looking for:
Dynamic Field Names in PHP
The solution was initially designed to fight spambots which 'autofill' certain fields, and if the field names look random it doesn't know which fields are 'traps', however you could use it to generate the names for your AJAX calls.

In the end though, it is always possible to crack, all one needs is enough time and money.

user3788486
  • 88
  • 11
  • thanks for the reply, but I think the answer to this lies in the origin of the Ajax call. Technically all JavaScript comes from the client browser, I just can't believe that browser vendors give you these tools and have no way of letting the server know you've used them - if you get my drift... – allnodcoms Aug 29 '15 at 20:27
  • @allnodcoms, Yeah I get what you mean, I'll have a look around the net. – user3788486 Aug 30 '15 at 08:23
1

This is a youtube guide by phpcademy (now codecourse) that throughly explains how to prevent CSRF (Cross Site Request Forgery) in PHP.

It involves generating a new random token every time a form is submitted. Afterwards you check if a token has been posted. If not, the request is not authentic.

EDIT: you needn't be worried about people seeing the token when inspecting the page, as you have your own (server side) way of validating your token.

  • Yup, I'm using a token, generated on successful login and sent to the client, which returns it as part of the transaction. Once validated and processed, a new token is sent. My point is this token is openly viewable, as would be any code used to modify it prior to return. I was hoping that the origin of the ajax could be checked (in addition to the token) to see if it came from a remotely hosted page, or a the dev tools console. – allnodcoms Aug 29 '15 at 18:59
  • This would probably make it more complicated to implement a possibile 'crack', but I don't see how that would really stop someone from recreating the 'token' retrieving part. – user3788486 Aug 29 '15 at 19:00