5

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: 

 http://domain.com/script.php?var=theStringSoGenerated

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

 http://domain.com/script.php?var=aCompletelyRandomString

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?

AviD
  • 72,708
  • 22
  • 137
  • 218
check123
  • 534
  • 1
  • 5
  • 14
  • Why does the middle tier insert it into the database? Why do you not validate? – Rory Alsop May 06 '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 06 '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 06 '11 at 17:38
  • Why not check for a valid session, or for a valid hidden field, or something else like that. – nealmcb May 06 '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 07 '11 at 06:31
  • I'm not sure I understood the question, are you asking how to prevent users from flooding the database with invalid (i.e. junk) requests? – AviD May 07 '11 at 22:01
  • @avid: Yes and that also by typing request directly into the browser, rather than, say request being generated through user interface. – check123 May 08 '11 at 04:37
  • Guys, any idea how (http://www.nseindia.com) could have implemented a protection which works somewhat this way: You go to their website and search for a quote, lets say, RELIANCE. We get a page displaying the latest code, on analysis we find that the query being sent across is something like: http://www.nseindia.com/marketinfo/equities/ajaxGetQuote.jsp?symbol=RELIANCE&series=EQ. But when we directly copy paste the query in the browser, it returns "referral denied". There could be some help for me here. – check123 May 25 '11 at 17:33
  • @check123, the site you've linked to implements HTTP referrer-checking. The second link that you've listed will not work, for the server verifies if the referrer was from nseindia itself. This is no protection against synthetic queries, for adding/spoofing a referrer is very easy. Refer to D.W.'s answer if you want to implement a more comprehensive solution. – Vineet Reynolds May 30 '11 at 16:39

2 Answers2

3

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?

Community
  • 1
nealmcb
  • 20,693
  • 6
  • 71
  • 117
  • "There is no protection against that..." - extremely hard to accept and equally hard to reject! – check123 May 07 '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 07 '11 at 18:30
3

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.

D.W.
  • 98,860
  • 33
  • 271
  • 588