1

I am creating an internal corporate tool which is entirely client driven and utilizes web services to update, insert, and delete data. While creating the application, I was able to use Chrome Debugger to send any type of request to the server in order to test various scenarios.

I would change objects from the debugger and execute AJAX requests right from the console and there were no issues, the web service would call and execute just fine.

This raised a concern for me in that, a majority of my company employees are developers and i worry that they may "play around" with the code to either change, or invalidate the data going to the database.

Is it possible to secure an AJAX request to the server so that users will not be able to change items in their browser debugger and post those changes to the server?

ps_md
  • 209
  • 2
  • 10
  • 5
    No, it is not possible. The client has full control over what it sends to the server. All you can do is validate it on the server-end. – Kevin B Jul 17 '13 at 17:49
  • 2
    This is why you always sanitize the incoming data to the server – Patrick Evans Jul 17 '13 at 17:50
  • 1
    Short answer no, longer answer it shouldn't matter because you should always be validating user input on the server. – Musa Jul 17 '13 at 17:51
  • Common ways to handle this is to be very specific in the format of the ajax requests, use session handling with session keys so that session data is stored on the server and not sent to the client other than the key, and restrict the users to only what they are supposed to be able to access via said session data. You could also implement usage limits, such as only x requests per min per session etc. – Kevin B Jul 17 '13 at 17:55
  • 1
    Best you can do is to validate everything on server and need to have authentication/authorization on server for operation that user use. – maketest Jul 17 '13 at 17:58
  • As commented above there is no way to prevent the data from being altered. What you could do is calculate some sort of hash (md5 for example) based on the content of the params before posting them. Server-side you recalculate the hash and if it's a match you continue with your regular validation process. Absolutely not secure but it discourages tampering the data. – Remko Jul 17 '13 at 17:58
  • @Okmer MD5 is either overkill or not enough, depending on how you look at it. It's not cryptographically secure, but it's also much slower compared to a good non-cryptographic hash. If you're going to be using a JS hashing library anyway, might as well make it something like SpookyHash or MurmurHash or CityHash. – millimoose Jul 17 '13 at 23:48
  • It is not possible. The best you could do is validate and also use a secure transport layer (SSL) but still that would not stop a user from messing in the debugger window. – Jay Patel Jul 17 '13 at 23:55
  • @ps_md For what it's worth, I was never bored or sociopathic enough at work to actually try and corrupt production databases of intranet apps. You might be worrying about nothing here. However it might be a good idea to audit service calls to see what caused breakage. – millimoose Jul 17 '13 at 23:57
  • @millimoose I agree about the md5. It was the first thing that came to mind just to point out the idea of calculating a hash. – Remko Jul 18 '13 at 06:46

0 Answers0