I am an iOS developer & developed a web services app which has been live on App Store for a year. Now I decided to make this app available cross-platform – beginning with Android, for which I hired an Android Developer.
Until this hire, all the web related code & data (PHP / MySQL / XML) was managed & fetched by me alone – so I did not worry much about the security. But now, with addition of another developer I have following concern:
The app sends POST request which includes how many rows to fetch – then a PHP script gets that many rows from MySQL & returns them in a well formatted XML. My concern is that now the employee will also know about the whole process & although he will not have direct access to PHP scripts OR MySQL database, he can still misuse it in a number of ways. For example, he can create a URL on web browser with a POST request for 100000 rows even – which will let him have all the data in an XML.
What measures should be taken to counter this? (Yes, I can force a hard limit of 40 in above particular case, but it is not an ideal or generalized solution.)
BTW, I did an extensive google research on this topic & to my understanding, the above problem is known as “Semantic URL attack”. But I was not able to figure out the right solution for it. Using “Sessions” is suggested, but according to my understanding “Sessions” is only helpful if we have password based user authentication – which is not the feature of my app.
Any help would be highly appreciated.
First you must be aware that if you have no protection and allow just anything, people will be able to do anything, as simple as that. So as I understand, you don’t want to use the standard protections: i.e. users having login credentials, and using per-case defensive programming.
Okay, then one partial solution would be to compute a hash:
You would have to compute the same deterministic hash function in php and in your mobile app, preferably a very complex one, mixing your own dark encrypting algorithms with md5, sha1, synchronized threads, etc.
If you worry about the attacker to repeat an old query with the right hash, you can make a more complex handshake: first send to the client a random number, which will be a part of the hash to compute. Or something based on the datetime, the ip, or whatever.
Of course if the attacker reverse engineers your code, he can find out the hash function, but it would take him some work at least. You can obfuscate your client’s code if you want to make his job harder.
As a testimony, I have used this sort of technique against lame attackers on services which didn’t require a registration. Unless the attacker is a pro and badly wants your private data, it works.