I am looking for some guidelines as to how to secure requests from android client to server
How can i prevent un autenthic (users which initiate requests not from the android app) requests to be accepted and processed by the server?
Waybe generate token at user registration and use it somehow at each call?
My server is a lite instance and performance is top issue in the implementation of the server client communication.
Appreciate any help!
You could use Google Cloud Messaging as a via medium to make sure messages that reach your server are from the app, without getting too involved in details. Check the documentation here:
https://developer.android.com/google/gcm/index.html
Or else, as you said, create a unique id on registration and send it back to the client. Store it at both client and server. Now with each request from the client, add an extra field in the request and send the id also. Check this id serverside and make sure it is valid (this check could eventually become heavy on time).
Related
I need to be able to consume a purchase without an Android client being connected using a backend server. Is this possible? If not, why? I am trying to make it possible to process a purchase entirely without a user being connected in the case of a disconnection.
Do I need to send a message to my client from my server requesting consumption and then provide a response to the server when the purchase is consumed? This is what I am trying to avoid.
I see various other similar questions but they are for the AIDL API which is now discontinued for google-in-app billing.
Relative API(s);
https://mvnrepository.com/artifact/com.google.apis/google-api-services-androidpublisher/v3-rev103-1.25.0
SOLUTION: To my knowledge, at this current time, July 2019, it is not possible to consume a purchase from a server. It is only possible from the android client.
This means that the flow of the purchase depends on a request to a client and an response from the client, followed by a required GET to validate the purchase has actually been consumed.
My android app uses GCM to send or receive text messages. At first, when a user install my app, it uses the GCM api to get a GCM_id from Google. After getting this long GCM id, app sends this id to my web server to say that this client is registered with that id.
My question is that about this step. Since firstly app gets the GCM id and sends it to my web server, I think, someone can listen the requests of the app and sends dummy GCM_ids for this client (or any other clients if guess my client id format). How can I secure this step to prevent unwanted interrupts and attacks.
While creating gcm_id, if google would send this id to my server also before sending it to client, it would be a solution to my problem. But google sends it to client only directly.
ps: Using ssl is not a solution I think. Because it can also be opened by programs like fiddler .
I'm currently developing an android app where the user has to fill out and successfully send the data of a few text fields to a recipient/server, to enable a feature.
The big issue is how to do that in a secure way to be protected against e.g. decompiling. My concern is not the security during the transport but rather the security of the transport medium.
What I've thought/read so far:
I could send the data via mail with the Java Mail API.
First of all, I don't want require that the user has to enter his mail credentials and SMTP server.
That would mean that I have to include the credentials to a mail account in the app, though.
To avoid the situation that somebody decompiles the app and takes over my mail account, I thought of encrypting methods, but even if I would save the aes encrypted version of the password, the attacker could decompile the app and could add a syso to output the decrypted password.
The same applies to OAuth authentication because I have to store an authentication token.
In addition to the mail version, I read something about getting the password with a POST request from a web service, which doesn't seem safer at all.
I could search for free smtp server without the need of credentials, but I want something I can rely on instead of waking up each day and looking if the service still works.
Send the data to a web service.
Okay that would require more work for me, but I would accept that, if there would be a solution without saving the credentials in the app or having a web service which accepts data from everybody.
Have I overlooked something? Or is there no safe method without asking the user for his mail credentials or google account etc. ?
OAuth would probably work. The nice thing about OAuth is that if a token is compromised it can be revoked on the server side.
You could create a web service that accepts TCP connections on some port. You could have some authentication mechanism for example Digest authentication that would be carried out before accepting data.
Another option would be to use an API such as Golgi. Golgi requires a developer key, app key and app instance id to connect to the servers and send data. In the event these credentials somehow get compromised you can simply change the app key and push a new version of the app through the Play Store.
As the diagram suggests, there is one main server and more than one user application. Server in its database, has maintained a set of feeds for each application.In other words, each application will have a set of unique feeds.
How does the client application receive the feeds from the server ? The only problem that has kept me away from implementing this is, how client will ask the server to send its feeds. Even if the client pokes the server about the feed, how will the server send them or how will the client receive it. One way out could be, the server writes all the feeds to a file and then the client knowing the address of the file parse it extracting the relevant data. But it could be a very long process if the there are many clients connected to the server.
Note: The client application is a desktop application
You probably want to identify the client by a unique user string or by authenticating the user. The most common way for implementing this is probably basic authentication (username/password) or a security string.
Basic Auth:
User enters username/password in the client software which is bundled with the feed request using either POST or HTTP-BA.
Security/Identifier string:
User enters a unique string such as hashed user ID or alike, which the client bundles with the feed request. E.g https://feed.domain.com?identity=fed54bd54ae...
There's plenty of ways to differentiate clients. Imagine what you will do when you go to a store. Do you just stand there, waiting for the cashier to give you something? No, you ask for something. How you implement that is up to you. You can use different ports, different URLs, define the protocol so that the client passes the name or id of the wanted resource when it connects.... Nothing really special here.
I'm building an android application which uses a PHP web service (I am building this also).
My question is, how do I prevent unauthorised users using my webservice? For example, could someone get the address of my web service and use it outside of my app (e.g. sending post variables to my service)?
Another related question is how do I prevent spam requests on my webservice? Would it be a case of logging the IP address and limiting the amount of calls?
You can use an HTTPS connection between the Android device and your webservice API endpoint.
Limit you webservice so that it accept only HTTPS connections. You can easily do this using Apache (perhaps using the SSLRequireSSL directive) or directly in your PHP connection handler.
While using an HTTPS transport stream, you can pass specific arguments when making an API call to your webservice to ensure the request has been sent from your application. Nobody will be able to know what specific data are transmitted and will not be able to reproduce an acceptable connection to your remote service.
Regarding your second question, you can indeed limit the number of requests for a given amount of time. Either in PHP or by using specific tools such as fail2ban.
PHP can receive data via POST or GET out of your site and even the internet browser. One of the methods used to do this is by curl.
To what are you referring to this question is known as Cross-site request forgery.
If you are able, you should implement the use of HTTPS in your app and this could solve many security problems.
In case you can not use HTTPS (whether it is expensive or any other problem):
You must verify the information received by POST or GET in your PHP, this language has much ability to solve these "problems"; Take a look at this part of the PHP official documentation.
Suppose you're building a login system:
Also you can add in the login page place a hidden element with secret unique code that can happend only once, save this secret code in session, so, the loging script look in session for this code, compare with what was posted to the script, should same to proceed.
And, if you want to get the IP address of your visitors:
function getRealIpAddr()
{
if (!empty($_SERVER['HTTP_CLIENT_IP'])) //check ip from share internet
{
$ip=$_SERVER['HTTP_CLIENT_IP'];
}
elseif (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) //to check ip is pass from proxy
{
$ip=$_SERVER['HTTP_X_FORWARDED_FOR'];
}
else
{
$ip=$_SERVER['REMOTE_ADDR'];
}
return $ip;
}
Finally, read this.
EDIT
If you can't pay an HTTPS certificate, (as Halim Qarroum says) you can use:
Self signed SSL certificates,
which are free.
Of course this has its advantages and disadvantages