-1

I have been thinking over this issue from past few months. Recently, I have started with complete JS Built front-end, where the forms are posted using Ajax.

I have a doubt, how to recognize on the server side, from where the data is coming from. Is it coming from actual form event or it is coming from browser console.?

What I have tried:

Creating a two way handshake: Before posting the form, the Application will contact the server, and the server will send a token inside the cookie, which will be sent back with the form post. But, even if we post by browser console, that cookie will go carrying the token. So, Failed.

Binding Hidden Field: But if someone, is posting the data from browser console, he would definitely look for the hidden fields as well. Basically, he'll replicate my AJAX to send the same request, in the same fashion. FAILED!!

I am not able to figure out this part. Can anyone help?

Thanks in advance.

Veer Shrivastav
  • 5,434
  • 11
  • 53
  • 83
  • 3
    You can not “recognize” that in any way. All your server will see, is that a request has been made – so make it deal with that request accordingly. “Where” such a request comes from should not matter at all to your application, as long as it satisfies all necessary requirements (f.e. a correctly authenticated user, that is allowed to make such a request). If you think it does, then you are doing things wrong from the very beginning already. – CBroe Aug 15 '14 at 04:48
  • You may want to review [this Chrome question](http://stackoverflow.com/questions/7798748/find-out-whether-chrome-console-is-open). – PM 77-1 Aug 15 '14 at 04:49
  • @CBroe: Suppose, my server has to accept all the special characters that are present in the data, then how will I validate for a script tag. at the server end.? If the user posts a ` – Veer Shrivastav Aug 15 '14 at 05:21
  • Not sure what you are trying to say here … if this is about XSS, then what I said still stands: Your application has to be able to handle _any_ kind of data that it gets send, no matter where that data comes from – and if only that “handling” of data would mean to _reject_ further processing. You can in no way rely on _“my app will receive only certain kinds of data, because I programmed the client-side part that way”_ – the data that gets send to your app might not even come from a “browser”, but literally anything else that is able to make an HTTP request … – CBroe Aug 15 '14 at 05:26

1 Answers1

4

Rule #1 of programming for the Internet: Never trust anything from the client. EVER.

Rule #2 of programming for the Internet: Never trust anything from the client. EVER.

Rule #3 of programming for the Internet: You can not make the client trustworthy.

I know the first rule is duplicated twice, but it is worth it.

There is simply no way to do what you intend to do.

A person who wishes to send data to your server, via an AJAX request or a POST request, can easily do any of the following:

  • Modify the form using browser tools or a proxy and force-feed in whatever information he wants.
  • Capture the entire transaction, through a tool like fiddler2, and change the values and re-send them. No browser needed.
  • Modify the code running from your site to send (or allow) whatever data he wishes to send.
  • Use a tool like Curl to fake an browser and send whatever information he wishes to.

There is simply no way of knowing, on your server, where that information came from.

From a security point of view, you simply can not trust anything -- ever.

Validate the credentials, give the user a login token (usually a cookie) and then still be suspicious of everything the client sends you. If there is something that shouldn't be changed or updated, make sure your back-end doesn't allow it to be changed or updated.

We have tons of code in our application that looks like this:

if (user.HasPermission("MayUpdateFirstName") {
   record.FirstName = FormData.FirstName
}

That way, if FirstName is passed in, and the user can't modify it, then it doesn't get modified.

Jeremy J Starcher
  • 23,369
  • 6
  • 54
  • 74
  • 1
    Who doesn't have the ability to change their first name? – John Dvorak Aug 15 '14 at 05:35
  • 1
    @JanDvorak Egads, don't get me started. Our app has an insane level of permissions, with pretty much every field being wrapped up like that. WE do business-to-business software, and some of our clients only *their* customers to edit personal data. Some of our clients require that any changes to personal/profile information be done *by* an employee. Some of these are for legal reasons in various countries -- if someone has all their tax forms made out to a certain name, all paperwork must be issued to that name. – Jeremy J Starcher Aug 15 '14 at 05:37