I am looking for a way to encrypt the data sent with the crash from the app to the Fabric servers.
Checking the official documentation I didn't find a method or a property to enable a sort of encryption.
What are you worried about?
A hacker hijacking your network data? Well - all Crashlytics communication is done via SSL. If hackers perform a MITM attak on your app, then crash reports are the least of your problems.
Someone reverse-engineering your app? Well - they won't do it through your crash reports - that's for sure. Not when "decompiling" the Java bitcode straight from the APK is so much easier.
Your best approach here would be to obfuscate your code using Proguard.
Someone identifying a key component of your app through the crash log? Again - easier via the APK itself.
Someone you don't trust, from your organization, learning stuff about your app from the crash results? You shouldn't give untrusted people access to your Crashlytics data. And if you do - obfuscatre first.
So, IMHO, this is a non-issue.
You are asking "from the app to the fabric servers".
If you mean exactly that then you are already covered, already encrypted and safe over the networks:
From their docs and probably easy to verify:
"All server communication is completed over SSL using packed-binary file format"
I'm assuming they actually mean TSL.
If you however mean that the Fabric servers shouldn't be able to understand the data sent (sounds strange), I don't know.
If it shouldn't understand your proguard/dexguard obfuscation (stack traces etc) then don't allow it to get your obfuscation mapping files.
Related
I'm going to release an android app shortly on the Google Playstore. I am aware that most apps probably don't reach the level of success where the authors need to worry about their app being cloned, but I would still have greater peace of mind if I knew that I had done what I can to stop other people copying it/stealing users by creating an identical knock-off.
I suspect that it's unproductive to try to protect the app itself (?) but my app communicates quite a lot with a backend server and I'm wondering if there are ways to detect if I am getting traffic from my app or a copy? Is there any value I can get the app to send that could tell me, or some technique I could use to differentiate my app from copies?
Thank you
Read the below article at developer.android.com.It provides details on how to obfuscate your app.
https://developer.android.com/studio/build/shrink-code#obfuscate
We have a challenge that reverse engineer modding our App and change some behavior of it and repack it.
We added a App signature checking to code but the reverse engineer can found that part and disabled it.
the another challenge is the third-party API we use must done on client and we can't perform it on server.
Anyone have idea to increase security of App ?
I have 3 things in mind for security.
use proguard for code deobfuscation
write native code for your secured part. It can't be reverse engineered
or process your secured part in server side & use the result.
Some users complained about network issues.
Our android app communicates to our server through https.
Our Apache logs showed responses with the status; "405 Method not allowed (CONNECT)", this problem was only reproduced on specific IP addresses.
I don't understand why the android app is trying to reach the server with a CONNECT method, I never use this method in the app, I use only GET, POST or PUT.
It seems a proxy may be involved in that problem, but I have no idea how to solve it. Does anyone know ?
Looking at the wiki for http connect
A variation of HTTP tunneling when behind an HTTP Proxy Server is to
use the "CONNECT" HTTP method.[1][2]
Not to point out the obvious, but enabling the connect method in Apache seams like the answer. Easier than asking the customers to remove their proxy servers.
You need to provide support for the CONNECT HTTP method, which is commonly used to tunnel SSL requests through proxy servers. Thats why you are receiving them, some users are behind a proxy.
In Apache, to enable handling CONNECT requests, mod_proxy and mod_proxy_connect have to be present in the server.
The problem is that you need to secure your server, which will probably defeat the purpose of you app.
DON'T enable mod_proxy and mod_proxy_connect if you have not secured your server.
I cannot provide a turn-key solution, as half the battle here is in the source tree for your supported Android application, as well as a combination of variables pertaining to your employer's infrastructure policies. You have three big questions to answer, and should conceptually do this for every problem brought to you as the Apache administrator:
When were the "problem" clients last able to connect without issue?
What changed between then and now, and when did it change?
Do CONNECT messages correlate 1:1 with clients reporting errors?
Questions one and two are priority, but should not be discussed in depth on a public forum like this. Changes made to your public or private configurations, applications, etc., are often considered the intellectual property of your employer. Use caution if you discuss that here or anywhere. If you find that changes were made, even "harmless" changes, discover their correlation to the customer issue and implement regression testing where applicable.
Question number three is what I will discuss. Based on the messages I've read above, it is not confirmed that CONNECT correlates to every customer issue. It seems as though some customers reported issues, and you looked at logs for symptoms of a problem. The CONNECT errors look like a problem, and based on some of the Android app spec you've shared, they might be the problem. However, they might also be "log noise" generated by someone scanning your server for vulnerable modules.
If you have not yet proven the correlation of CONNECT to customer error, try using the <If> directive and logging additional data about clients who issue CONNECT statements. As a generic example:
<If "%{REQUEST_METHOD} == CONNECT">
... some extra log format fields to get ALL of the data ...
... maybe a special log file just for CONNECTers?
</If>
Use the gathered data to understand a trend. It might be that only specific versions of Android with your app are behaving this way. You can branch <If> to change the way those users receive content, or you can work with the developer of your Android app (the current one, or the next one you hire ;) ) to develop a list of web server requirements based on the app, itself.
Better still, a well-constructed block can enable you capture debug data for specific clients without disrupting those whose apps work. As always, I recommend building and testing in a lab first; never deploy brand new ideas to production, and most certainly never enable modules because the Internet told you to, even if they were right in naming the module.
Here are links to Apache's documentation for the <If> directive:
http://httpd.apache.org/docs/2.4/mod/core.html#if
http://httpd.apache.org/docs/2.4/expr.html
Good luck!
We have developed a service with REST APIs and an Android app that leverages it. We currently don't require our users to authenticate.
We would like to implement a simple mechanism to prevent the random person from invoking the APIs from outside of the scope of the app, mainly to avoid abuses that would spoil the data that we compute.
I stumbled upon this url where they suggest to have authentication enforced by having the server and Android client to share a secret and use that to compute an HMAC to pass along with the request. They claim that they use this approach in Amazon (I have no experience with Amazon AWS yet).
I'm considering to proceed as follows:
store a common secret in the Server and in the Android app (any good idea for obfuscating it, besides using ProGuard?)
Have client and server to communicate over plain HTTP (we don't need confidentiality yet and we will save some CPU) and use the HMAC method to authenticate the calls as "coming from a legitimate Android client".
From time to time we can update the secret (perhaps at each new version of the app).
If in future we will need confidentiality we will enable TLS for the relevant REST calls.
Do you think that this solution would work? Is anyone using something like this? Alternatives? Advices?
Thanks.
I am not a security expert.
Your solution sounds fine to protect you from "the random person", but you are still vulnerable to a dedicated attacker. Anything stored on the client can be dug out and used against you. ProGuard will dissuade a casual attacker, but against a dedicated attacker it's just a speed bump.
Nobody here is going to be able to tell you if that level of security is good enough, because it depends a lot on the specifics of your application. The final decision should rest with the product owner.
I want to develop an android app for my website. One way of doing it is to have an API for the site, and let the app use that API. However i want this API to be used ONLY by my android app, I don't want any other client to be using this API.
Is there a way to ensure this?
I can think of one way of doing it: put a secret in the app and let the app pass this secret always to the API. But i am not sure how secure this approach would be because any packet sniffer can easily sniff the parameters and hence the secret. Any other suggestions?
I think this is something similar to a question I answered a few days ago.
Securing a REST API from Android
Namely, find a way to authenticate all of your requests using a shared secret.
If you sign both the path and params with a secret, then there should be no way for someone to forge requests.
Finally got hold of the answer from the android developer's blog article.
The short answer is no, sorry. If someone really wants to exploit your site/api/device/program/insert anything here and they have the time and resources then they will.
To directly answer your question, putting a key in your app isn't secure as anyone can decompile the app and try to reconstruct the key from the source files, they don't need to sniff traffic.
Correct me if I'm wrong! Packet sniffers can only be used with unencrypted WiFi and in (now) rare network configurations (a router or a switch prevent them).
For serious matters, you should consider secured connections (https).
That said, for standard content, I feel that a passphrase is secure enough. Many popular web apps don't use more than a cookie over http to let you log in, which is exactly what you're proposing.
I struggled with this issue and I actually ended up implementing a version of OAuth for securing my API. It can be difficult if you don't to launch a browser to do the "login" part of OAuth. I baked the login right into my my app and actually implemented the token exchanges under the covers. Too much involved to post the code here, but it works great. Obviously HTTPS is desired for an additional level of security.
If you could get some kind of signature back from package manager of your own app, you could use obfuscation to hopefully make it much more difficult, and have the signature/hash of signature from package manager be the key for your HMAC-SHA1.
Might have to try this ( How to get APK signing signature? )
If you did that, it would make it more difficult to use. Obviously, it could still be decompiled, but if they re-compiled it w/ debugging etc, it would have the wrong key. They would then have to actually make their own package manager on a rooted device to get the signature.