iOS app security - php

I am in the process of making an app that will allow certain users to insert values into a database. Atm if I go to the php file and add ?year=235&name=ggg to the end of the URL it would be added to the database. What would be the best way to protect against this and only allow information coming from the app to be entered in the database? Or is it a waste of time trying? 
I know really the only way for people to get the URL for the php file, is if they used something like wireshark/packet tracer. 

At the very least, you should be using HTTPS. Secondly, it would be wise to use some form of OAuth. That way, one would require a special token, which the user themself doesn't know, in order to access your page, and you could restrict database access to users who are authorized.

Related

Do my web app's users need direct access to my database?

I'm creating a web app that users will create an account for, which allows them to read/write data on a database. I'm about to start creating the login authentication part of the website, and its my first time really doing this part. As I understand it, I'm going to create a users table which will store all the necessary login info for the website.
I know there are also database roles/permissions. My question is about how the 2 relate in this instance. Do I need to authenticate the users on the website and the database? My thought process was that if all of my PHP scripts are set up in such a way that the session data will only allow authenticated users read/write to the DB, then I don't need to do anything on the database end, but I want to make sure I'm thinking about this correctly.
Is that clear as mud?
If I understand correctly, your question is wether or not your users need access to your database.
Your users are not going to communicate with the database directly. Your app will. Your users are only going to use your app which will act as an interface between the user and the database.
Therefore, only the app needs access (and the appropriate permissions) to the database. Because it now has access to the database, it becomes responsible for making sure that only the right people can perform certain actions. (by means of a login- and permission system)
If not all users should have the same permissions within your app (you might have normal users and administrators), you need to create a permission system within your app that checks wether a user has the appropriate permissions to perform a certain action.
For instance if someone tries to delete some important data, you
make sure he's logged in (if he's not, redirect to the login page)
make sure he has the appropriate role / permissions (in this case he should be an administrator - if he's not, cancel the action)
Symfony's page on Security gives some insight. Just skip the Symfony-specific parts and read about the general idea.
Your users will authenticate on your website (by requesting details about their validity from the database). Once authenticated they can do things that the website gives them access to.
The only user that will communicate with the database directly is you/your website. Your database will have a table entitled 'users', but the actual user of the database should be no one else but you - you don't want to give random users free reign. You can then set what database queries you wish the database to perform on certain users actions.
Hope that helps clarify

Android App User Authentication with PHP

first time poster here.
I'm a college student working on an Android app right now that collects location data from users and stores them on a server for later retrieval. I've got the front end running fairly nicely (collects the data and has the ability to store it locally or send it via POST data to my php server).
Now I just need to figure out how to implement a user authentication system on the back end. I'm really not storing very much data, just user credentials and the location data linked to it, so I've kind of been shying away from using a full-fledged CMS or some sort of framework for the back end. Like I said though, I'm still a student and I'd be all ears to any suggestions.
My initial idea is to just use the filesystem. When a new user creates an account, a new directory is created with their user name and their password is hashed and stored in a separate directory as a file named something along the lines of newuser.pw. When a user tries to login, their credentials are checked against this file and if they match, they are granted access to their directory holding their location data which they can then browse via an interface on the phone.
My question to all of you is, is this system too simple.? Could it ever be secured and if so, how would you go about doing that? If this sounds like a security nightmare, what sort of back end framework/CMS would you suggest?
I was doing this before. You can collect the data to .TXT on your server. Or store data in TXT on device and upload it periodically. What datas you'll store ?

Android device login to php/mysql website for syncing

Im going to make an app that will be able to sync data between android mobile phone and a webpage database. At the moment im trying to think things through and figure out the hard parts. The first thing that crosses my mind is the login part.
The best idea i have is that before starting my app user has to log in. When he logs in it sends user data to my web page and it returns true/false. If it returns true i make somekind of an session in my app that says i am logged in (to access app features) but also stores my username and password. Now if i press the sync button or do something else that will need communication with my webside i can check the user/password every time. Because on the web site im planning to do different actions (login, sync, something else) i need to check the login every time - otherwise a third party could just access sync action without actually logign in first.
Anyway, that my thoughts at the moment. Im sure ill ask more detailed questions when i get to coding (im a beginner with android/java) but at the moment i wish to know if the idea of the thing is good or can it be done smarter/better?
Thank you.
I'm suggesting you to create API based application so you won't be troubled if you want to create it in many platform (in case you also want to create in iOS).
What I'm usually used is using API_KEY. API_KEY is a random number generated by the PHP side to save the login session of the user. When the user login from the mobile phone (sends the username and the password) the PHP side will generate API_KEY and updatethe existing API_KEY (if the user have logged in before in other device) in the web database so the login session in the other device will be automatically expired but you must add API_KEY validation everytime you try to access the the database (sync your application) or if you want more strict you can do the checking everytime the user change the screen.
If you have some question about this feel free to ask in the comment ! :)

Reusing OAuth Access Tokens

On my site, I intend to offer users the ability to authenticate via OAuth. I don’t want to ask them to first register with me and then connect an external account; I want to offer single sign on.
I believe we’re supposed to reuse Access Tokens; certainly within sessions and even between them.
Google goes so far as to say they’ll limit the number of access tokens to 10 per user per application. (Apparently Google still supports OAuth1, but recommends Auth2 now) 10 is a pretty small number.
Using cookies (like this) seems like a good plan for identifying a user between sessions, but I’m having trouble with the scenario where a user has deleted cookies or connects from a new machine.
How do I know who the user is before I’ve requested another Access Token for them? Request tokens do not contain the userid, right?
Thanks
You will have to maintain your own user accounts anyway, no matter which protocol and which provider you choose. A token (or a URL in the case of OpenID) that you get from a provider is unique for a given user and you are supposed to associate it with your internal user account and recognize user by it.
If you don't want to provide any registration UI it's okay: just get the token, retrieve all the user info you need from the provider and store all this somewhere in your database. You will also have to issue and recognize your own cookie for your users, or else they'll be forced to go through provider auth every time they visit your site.

Authentication without username/password?

We are building a PHP multi-tenant application. Each company's account will run on their own subdomain abcorp.example.com. The application allows companies to write and publish content (faqs, etc) for their customers to read.
They will tell their customers to visit: abcorp.example.com/ to read the content. Or they will put a link to that URL in their secure web application.
However these companies may not want just anyone reading the content by going to abcorp.example.com/
So, the question I have is there any way to provide some basic authentication without getting into username and password authentication. I was thinking about some kind of hidden token added to the hyperlink or something like that
My goal:
If users type abcorp.example.com/ directly in the browser, they will not be able to see the web page because they didn't authenticate or pass the token in.
Avoid using username and passwords
Another option would be Referring URL Authentication
Of course, if someone makes the token public, it will open up access to whoever finds it.
I suppose each company could link to their page using a shared token, for example:
abccorp.example.com/?t=4rrfwr23rwads3
Each token could be stored in a file or a database.
When someone requests a page, it checks the value of $_GET['t'] with the one stored on the server. If it matches, it loads the rest of the page. Of course, this variable would have to be carried throughout the site, and included in every link.
Again, this will not be very secure. An exposed token could give access to the site to the entire world.
Your "hidden token" idea is essentialy the way sessions work. A session can be used to identify a user (ie. keep track of what a user does as they browse through the site), and is propagated either by passing the session ID along in links or by storing it in a cookie.
However, using a session without any other sort of authentication is inherently insecure! When you expose the way to authenticate and track users to the user itself, the user can modify or forge their authentication. For instance, the user could change the value passed along for the session ID or change the value stored in the cookie.
Please read the PHP manual section on sessions and security.
Client-side certification. Check out http://en.wikipedia.org/wiki/Mutual_authentication.
You could also use the clients IP address as a token, giving different IP addresses access to different (parts / instances) of the system. But gain, this is not very secure, as
you have no way of knowing who is behind the client PC and
IP addresses can be spoofed. Perhaps you could develop additional specs; giving IP addresses only access during office hours, or check the clients browser (user agent) and check it against the user agent officially being used at the client.
You can use basic hashing whereby a shared secret password or "key" is stored on your system and each company system (a different key for each company and not published publicly), and then you hash the secret password with the subdomain in the link and include the digest as a parameter. Then you validate it by running the same algorithm on your side and compare to the digest.
the link might look something like
abc.example.com/?d=b5939ca22f5dcf345b4000641995478c5910dbd1607b1bdadcbf4a8618a95211
where digest is:
$d = hash('sha256', $secret_password.$subdomain);
or including the referer:
$d = hash('sha256', ($secret_password.$subdomain.$_SERVER['HTTP_REFERER']));
The hurdle to get over is making sure each of the companies can support the correct generation of these links based on the company specific key/algorithm - and that it is different for each company so one company cannot produce links for another.
It is better than no authentication, or a public shared token that is not validated at all, but I'm sure it still has vulnerabilities.

Categories