0

I'm developing a mobile app which has to access to an external webapp (PHP + Codeigniter) to administrate the actions queried by ajax.

So by this way, there is a problem. If anyone see the urls used, could delete rows, or modify the user's info from the database. So I thought in this system to aboid this:

After a sucessful login I would do this:

// getToken : https://stackoverflow.com/a/13733588/2154101

$this->session->set_userdata('private_token', getToken(50));
$public_token = getToken(50);
$this->session->set_userdata('secure_token', md5("$private_token:$public_token"));
$data['token'] = $public_token;
// some stuff ...
// send $data in JSON

Then the client would the public token in the next query I would do this on the server:

$public_token  = $this->input->post('token');
$data['token'] = get_public_token($public_token);
// some stuff ...
// send $data in JSON

Where get_public_token is within a helper with this code:

public get_public_token($public_token) {

    $last_secure_token = $this->session->userdata('secure_token');
    $private_token = $this->session->userdata('private_token');
    $actual_token = md5("$private_token:$public_token");

    if ($actual_token === $last_secure_token) {
        $public_token = getToken(50);
        $this->session->set_data('private_token', getToken(50));
        $this->session->set_data('secure_token', md5("$private_token:$public_token"));
        return $public_token;
    } else { // you are cheating me ...
        $this->session->sess_destroy();
        redirect('/');
    }
}

So only the user of this session could modify the data of the database.

I'm just trying to do the same explained here: https://stackoverflow.com/a/17371101/2154101

The session are encrypted, and I store them in a database too. Do you think this method will work ok? Am I missing something important?

Community
  • 1
  • 1
mllamazares
  • 7,876
  • 17
  • 61
  • 89
  • 1
    Is the application remotely accessing a *database* or remotely accessing some kind of *web application* which obscures the database? Huge difference. If it's a web application, what is the authentication and authorization mechanism for that application? How does it identify the user making a request? Clearly any user requesting to modify data he's not allowed to modify should just receive an error message, not actually be able to modify the data. It's not clear from the code how the applications are arranged or how authentication/authorization is tracked. – David Sep 11 '14 at 14:56
  • I've modified the question. Read it again please. Thanks! :) – mllamazares Sep 11 '14 at 15:06
  • 1
    A mobile app accessing a web service sounds like a really good use case for using something like OAuth for authorization. Better to use industry-tested standards than to implement your own. – David Sep 11 '14 at 15:09

4 Answers4

5

You should create an API for your mobile application. Create a authentication mechanism.

If your database holds user specific data, then you should create account for each user. So if the user sniffs the network and tries to call the api manually, then he could only change he's own data.

There are some API libraries for php out there, you should look into that.

Lauri Orgla
  • 561
  • 3
  • 10
  • 1
    https://github.com/chriskacerguis/codeigniter-restserver => API made in codeigniter, since you have previous experience it should make it easier. – James Lalor Sep 11 '14 at 15:01
  • But with my actual method I prevent that the user could modify anything that doesn't be yours. Check it out, please. – mllamazares Sep 21 '14 at 18:31
1

Actually your solution is doing more than necessary. The only token of interest is the public_token sent back and forth. So you can throw away private_token and secure_token from session data, keeping only public_token for checking. Your current check is something like (X + 5)/2 == (14 + 5)/2 (is [received_token + 5]/2 equal to [14 + 5]/2 ?) when you can simplify to X == 14.

However if someone is sniffing the network, he can get the last token sent to a client and use it to hijack into that session. He can execute anything while the original client doesn't send a request with the outdated token, killing the session.

A better solution would be creating a secure_key after login and keep it at both ends (client and server). Then server would keep sending a new public_token at each response, but the client would send a md5(secure_key + public_token) at requests. This would narrow even more the hijacking window to the exact point where the session started. Without the original key, attackers can't create a valid md5.

However we are talking about minor hacking fans here. Anyone more zealous could hack that anyway. If you are concerned about that, then throw away all that stuff and simply use a HTTPS connection. With a trusted connection your sessions and access control rules are protected.

Sérgio Castelani
  • 469
  • 3
  • 7
  • Why the client would have the secure ley too? I've updated the method, check it out, and give me your opinion. And the last question: with my actual method how the heck could someone get the key for the user? The private key and the public key changes with every query, and the session variables are fully encrypted and saved in my database. Thank you so much. :-) – mllamazares Sep 21 '14 at 18:17
  • Ok, a doubt with my actual method (in your second paragraph): Suppose that someone steals my last `public_token`. Then he tries to use it to make a query as me, but the server will check/compare it with his `secure_token` stored in his session, and as it won't match like mine, he will be kicked out. (If you could explain me why this couldn't work, I'll give you the 50 points ;) ). Thank you so much! – mllamazares Sep 22 '14 at 06:52
  • With [spoofing](http://en.wikipedia.org/wiki/Spoofing_attack), any machine can send the pair `(phpSessionID, updated public_token)` through HTTP headers and win that session. It will aways match the pair `(phpSessionID, expected public_token)` stored in the server. – Sérgio Castelani Sep 22 '14 at 14:10
0

The better way is create API using SOAP or SAML2.

Saurabh Kr. Singh
  • 31
  • 4
0

OAuth can be a very good solution: http://oauth.net/. It takes care of token and has a very secured API! If you wish to support secure authentication of web application + mobile application then it can be a good/proven solution!

On the other hand, it really depends on how complex your current system is and how the system is going to be in future.

Ahsan
  • 3,845
  • 2
  • 36
  • 36