Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Securing their AJAX-like server requests?

For my app I'm using a Xhr request which passes a few variables to my server, which then performs DB stuff, and the returns with a response. I'm using Facebook as a login system.

Even if I use https:// how are we going to prevent people from sending their own requests to where my php files are on my server?

1) Will my app be encrypted when it gets sent to App Store? This way the user can't see where the request is being made? a hacker wouldn't have any problems working around this with packet sniffing.
2) Should I send an JavaScript generated encryted key and decode it on the server side? If a hacker could look at the .ipa file they will be able to see how the key is encoded
3) is there a way I can access the Facebook session keys and send that with the request? Will I need to request 'offline_access' permissions in order to get a session key that doesn't expire. I could save this on the device and our server.

Please advise. Currently anyone can pass GET variables to my PHP files and make database changes.


— asked April 12th 2010 by Ryan Gartin
  • ajax
  • encrypt
  • mobile
  • secure
  • security
  • xhr

4 Answers

  • if you use POST instead of GET that helps in the first instance to the casual hacker.

    Then you probably want to authenticate the user - request a user/pass combination and then send to the server to validate authority. You probs want to use SHA1/MD5 to encrypt the password and match that to the DB.

    Working over SSL is also a plus.

    Otherwise what you're asking for is user validation without actually validating a user which is pretty bad app design.

    Of course, in your PHP you should be sanitising absolutely 100% of all incoming data as well ;)

    — answered April 12th 2010 by Andrew Waters
  • I did plan on locking the scripts down to POST instead of REQUEST and soon as I get out of testing. I also plan to use SSL. I currently am using mysql escape string on all incoming variables as well.

    But since I'm using Facebook as my auth source, I don't have a user/pass that I can validate against the DB.

    I'll keep this open if anyone else wants to chime in with their experience, otherwise I would mark this as solved. Thanks Andrew!

    — answered April 13th 2010 by Ryan Gartin
  • You sould be able to get the users Facebook ID - I haven't tested any FB Connect functionality yet. You can use that as the Username :)

    And then you can use the ID with some salt to create a password (see http://en.wikipedia.org/wiki/Salt_(cryptography) ) which you match in your DB - so you create a dummy user with a cryptic user/pass pair that you can validate against.

    For your PHP scripts take a look at hard sanitising rather than just escaping - it's a much more thorough test on incoming data, especially if you know the parameters that are being passed. Again, check out the PHP manual for a bit more info:


    Hope this helps


    — answered April 14th 2010 by Andrew Waters
  • Short answers: Use PHP sessions.

    Since I don't know enough about the internal structure of your app and haven't authorized with Facebook, it's hard to be more specific. For example, if you authorize with Google's Oauth for Apps, you still have to send the user to a callback page on your site that Google transmits an intermediate key to. When this happens, your site can generate a PHP session ID and transmit the ID to the app via various methods.

    You can then use the session ID to verify the app. You can also give it a specific TTL (time to live) so it expires and can't be used long-term. Furthermore, the session ID allows you to store certain information server side so you minimize its transmission between the client and your app.

    Last, check the User Agent of the browser in your PHP code and return a vague/non-specific error message if the User Agent isn't right. I haven't tried it with mobile, but Titanium desktop identifies itself in the User Agent header it sends to browsers. You can always falsify the user agent your browser sends, but it adds one more hurdle to overcome for anyone trying to send illegal requests to your PHP scripts.

    — answered April 18th 2010 by Greg Bulmash
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.