Note: One, I am not sure if synthetic queries is right word for the risk I am talking about. Second, though I am considering 3-tier model of web-applications general answers are welcome in client-server situations where server side validation is not possible.

Currently I have a page where you do certain computations using what is called as DHTML, This computation generates a string which has no particular pattern as such. This string is sent to a server side script using AJAX.

Anyone with basic training in these technologies can read the code and realize that the query is sent is something like this:


Hoping to exploit a possible flaw, a hacker types in his browser:


He does this a few times and sees no evident benefit and quits, but in the middle tier, the PHP script, completely helpless without a possible validation, updates and inserts the random string into the database impacting its integrity and leading to wastage of resources.

Question: How can I protect my application against such attacks?

  • Why does the middle tier insert it into the database? Why do you not validate? – Rory Alsop May 6 '11 at 17:26
  • Because, the string generated is completely random, for example a comma separated string (CSS) of numbers (3,4,6,9,4,5,19). In such a case, I can validate the string pattern - CSS of numbers - on the server, but when the order of the numbers is important and generated by a client side script based on a DHTML interface, then in such a case my system is still vulnerable to a random CSC of numbers. – check123 May 6 '11 at 17:32
  • Your problem is, then, that an attacker can always subvert the client end and make up a string. Even if you have a way to encrypt it etc., a determined attacker can reverse engineer that code and provide something which can taint your database. Not sure what you can do about that if your app has to accept random strings... – Rory Alsop May 6 '11 at 17:38
  • Why not check for a valid session, or for a valid hidden field, or something else like that. – nealmcb May 6 '11 at 18:40
  • @nealmcb: A hacker may have access to valid session and moreover it does not address the general case for applications without (need for) sessions. As for the hidden, he can tackle it the same way like any other field. – check123 May 7 '11 at 6:31

You should validate the input at the server.

Presumably, if not all strings are OK, then the client is doing something to validate that the string it generates is OK, or is using some process to generate the string. Now do those same checks at the server side, or have the server re-construct that process to verify that it was followed. If the client can do it, the server can do it, too.

The core here is: don't trust the client. Any checks that you rely upon, need to be done on the server (it's OK if they are done on both the client and server, but it is not OK to do checks just on the client and omit them on the server).

If you want more specific advice, you'll need to tell us more about how the client generates the string and what strings are/aren't valid.


It seems that you are not actually asking about 3rd party attacks like CSRF or XSS, but actually worried that the authorized user will rewrite the JavaScript or send a query by hand.

There is no protection against that, unless you're willing to try extraordinary measures to lock the user out of their own computer and browser. See e.g. Is AJAX fundamentally insecure?

  • "There is no protection against that..." - extremely hard to accept and equally hard to reject! – check123 May 7 '11 at 14:22
  • @check123 Well, not really. What you are wanting to prevent is exactly the same thing as what the user needs to do in the first place. The options you have are: validate input, limit number of submit requests (can only submit n number of values over a period of time), or only allowed trusted users to submit. – Steve May 7 '11 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.