Authorization between PHP and Mobile App
I am stuck in a scenario and need someone to help me out.
I have a REST web service written in PHP. Its an open-ended web service with no concept of login etc. Now there is a mobile app (available on both android and an IOS devces) to do certain things when interacting with this web service. To make it more clear, the mobile app can make a POST request to the web service and add data on the server.
Now, I need a way so that I can authorize that the request is coming from that app only and not from anywhere else.
Kindly suggest me a way to do it.
PS: I cannot have a login mechanism as per client's requirement. Also IP filtering wont work in this case because the app can be downloaded by any number of users from anywhere in the world.
Thanks in advance.
You can't really... Not any way that I can think of...
But you can make it much harder.
I would probably consider putting some data in a HTTP request header claiming it's from the app and also coding it in SSL so that it's not easy to be monitored.
You could try an extra level of encryption so even if that tried a man-in-the-middle attack they'd just get rubbish too.
But in the end all the data people need to talk with your server is in your app.
Make sure you obfuscate your code to make it harder for people to get the communication methods from your app.
There's a ton of things you can do, but nothing is perfect.
I can't wait to see what others offer up to you since I personally don't have a clue. It seems to me that if your service cannot ask for some authentication from the incoming POST request and if you also don't have any trustworthy method of verifying the source of the POST, how can you do this? Of course, if the external application has to make some kind of modification in order to interface to your application, perhaps you can make a request for some kind of accommodation from them.
I do have access to modify both the server and the client app i.e. the mobile app but my client (my boss) does *not* want any feature of registration/signups/logins etc
You're telling us now that the 'other appl' is one of yours? That wasn't clear before. Obviously now you can simply add something to that app that gets sent to the service which your service can be taught to recognize and accept - or else!
I am sorry I didnt clear that thing out...
So what exactly should I do so that no one else but that mobile app can only make request?
Not familiar with 'web services' myself, but I see it as some appl that expects certain inputs and after receiving them does something for you. Why can't that service be setup to expect a certain hidden input from the 'calling' appl in order to verify that it is allowed to make that call? In fact, don't any outside processes calling your web service have to already know how to interact with your service? So this particular appl will have to send a particular data item in order to be accepted.
This whole thing would be much more difficult to solve if you did not have access to the 'mobile app' you referred to in your initial post. Since you do it's a no-brainer to modify your mobile app to talk properly to the service.
I am looking for some practical implementation on how this can be achieved.
Originally Posted by ginerjm
I'm pretty sure I just outlined one. Very practical.
You can't, all you can do is make it more harder by preventing people easily finding out how they communicate. It's not THAT secure, but it's better than nothing.
Originally Posted by phantom007
(1) A secret HTTP header added to the request only known by the app and the server.
(2) Use HTTPS to prevent (slow down) Man-in-the-middle-attacks finding out the secret key.
(3) Obfuscate the code for your app so that people decompile it and find out how the requests work (too easily).
If people really want to do communicate with it, then you're fighting a losing battle, especially if you're here asking these questions. However these are some very simple steps that can help to slow down people who want to be able to communicate with your server by their own means.
Originally Posted by Gravy
Thanks for your reply.
What will that secret key be made up of?
Anything at all that you want. The biggest secret about the key is that it even exists.
Originally Posted by phantom007
The idea is to have an extra piece of data in hidden in the request that if people don't know it's there they can't interact with the server.
It's really just some security through obscurity (not really considered security on it's own) and defence in depth.
Anyone really serious can still get around this. (I could)
Make sure that your app will not communicate with the server if the SSL certificate for the site is not valid. This way it makes it rather hard to emulate your site to catch the data or perform a man-in-the-middle attack.
Basically the same thing I espoused with my 'extra piece of data' expected by your appl.
This would make the man in the middle attacks hard to do, even harder with HTTPS:// as the protocol.
Client-side you can not hide code, simple as that, however, you can do things to divert attention towards input elements, generally hackers won't be looking at code, they will have written a crawler to crawl the web and the bot will automatically look for input fields and fill them with data.
So... <input name="login" type="text" value="" /> would draw attention to itself byt the fact that it has something to do with a user login, similar names like username, email, pass, password, pin and anything that is likely to denote an input for a login will come under attack...
Because the web crawler will see inputs, it does not care about specifics like if the field is read only or disabled and hidden doesn't matter, the remote server will still attempt to post data to your server with strings of data in those fields. This can be useful, an input field in a form could be hidden, readonly and given a nice juicy name like userlogin and when your server receives a post, as long as there's no data in that field, it is likely the form came from your server.
So... as long as your web page and server knows the order of things, like <input name="a" type="text" value="" /> <input name="b" type="text" value="" />, etc. and you know that $_POST['a'] "should" contain a users email address, then you can use the common addressed input fields a honey pots and used to validate if your script is being subjected to an attack or not.
Yes, I know I'm about as subtle as being hit by a bus..(\\.\ Aug08)
Yep... I say it like I see it, even if it is like a baseball bat in the nutz... (\\.\ Aug08)
I want to leave this world the same way I came into it, Screaming, Incontinent & No memory!
I laughed that hard I burst my colostomy bag... (\\.\ May03)
Life for some is like a car accident... Mine is like a motorway pile up...
Problems with Vista? :: Getting Cryptic wid it. :: The 'C' word! :: Whois?
Which was also basically what I wrote in the second post (first reply to this thread).
Originally Posted by ginerjm
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)