I developed an app using the platform codename one, after submit the app in Play Store I received the following warning email:
*"We detected that your app(s) listed at the end of this email are using an unsafe implementation of the WebViewClient.onReceivedSslErrorHandler. You can also see the list of affected apps, as well as details such as version numbers and class names, on the Alerts page in your Developer Console.
Your current implementation ignores all SSL certificate validation errors, making your app vulnerable to man-in-the-middle attacks. An attacker could change the affected WebView's content, read transmitted data (such as login credentials), and execute code inside the app using JavaScript.
What’s happening
Beginning November 25, 2016, Google Play will block publishing of any new apps or updates that contain this vulnerability. Your published APK version will remain unaffected, however any updates to the app will be rejected unless you address this vulnerability.
Action required
To properly handle SSL certificate validation, change your code to invoke SslErrorHandler.proceed() whenever the certificate presented by the server meets your expectations, and invoke SslErrorHandler.cancel() otherwise.
If you are using a 3rd party library that’s responsible for this, please notify the 3rd party and work with them to address the issue.
After making changes, sign in to your Developer Console and submit the updated version of your app.
Check back after five hours - we’ll show a warning message if the app hasn’t been updated correctly."*
I was researching but unfortunately I didn't find anything about that. I think that maybe is an internal issue of the platform but not sure. What do you think?
Thanks in advance.
Not properly validating the certificate of a SSL connection is a serious issue because this way you effectively weaken the protection offered by SSL a lot and allow easy man in the middle attacks. This way an attacker might sniff the transferred data and even modify the data.
Thus the issue should be fixed.
But with the currently shown information it is impossible to say if the error is in your (unknown) code or some (unknown) third party library or in the wrong usage of a third partly library. But a common cause for such errors is that one is trying to use a self-signed certificate and switches off validation for this purpose. Another common cause is the intention to switch off validation for development only but then inadvertently fail to enable it again for production.
You can look thru the sources of the Codename One port and see that there is no usage of that method:
https://github.com/codenameone/CodenameOne/blob/master/Ports/Android/src/com/codename1/impl/android/AndroidImplementation.java#L3768
So there is no such violation within Codename One as far as I can tell. There are thus two options I can think of:
Google is wrong - wouldn't be the first time with those guys... +
I submitted a Codename One Android app just the other day and didn't get such an error
You added a 3rd party cn1lib/extension/native code to your project which you can verify by looking under android/native or within the lib directory to see if you have anything in the former or a .cn1lib file in the latter.
Related
I would like to get the list of all revoked certificates list downloaded on an Android device? I know that this class allows you to check if a certificate is revoked or not, but I want to get the whole list of revoked certificates. Is it possible? Does Android store such a list or it uses OCSP to check the certificates?
It would appear that Android does not store a certificate revocation list (or at least if it does then it doesn't use it). There's a reddit thread from a few years ago that brings this up and discusses the pros/cons of it, but the essence of it is that if you go to https://revoked.grc.com/ (which should throw an error if your browser checks for revoked certificates) on mobile Chrome, you'll be notified that your browser doesn't check for revoked certificates.
From the page above (revoked.grc.com, which you shouldn't be able to see unless you're using a browser without a CRL):
The mobile Android platform currently offers no certificate revocation checking of its own, so Android apps (including all users of Google's Chrome browser) are vulnerable to malicious certificate abuse. The only way to use Android securely today is with Firefox, which brings along its own certificate security.
A couple more sources I found (again a few years old, but they still seem to be relevant and accurately describe the current situation):
An issue on the OkHttp (an Android http client) github discussing whether to add certificate revocation checks, where they decide not to
The CommonsBlog, discussing the lack of certificate revocation checks on Android
A Chromium issue about the lack of a CRL, where one of the developers states that it won't be added and presents the justification:
Marking this WontFix for two reasons:
1) Revocation checking is the responsibility of Android and the related SSL APIs. Android itself does not and has never performed revocation checking [...]
2) Revocation checking generally doesn't work (as a security feature), and especially for mobile, greatly affects performance (negatively) and privacy (negatively)
My app uses Google App Engine as backend and it provides google plus & facebook login option to user.
One of the endpoint Api takes user profile picture url as input parameter and tries to store it in the user profile table. My endpoint Api was not getting called successfully when user choose the option of google plus as login,
I have narrowed down the issue to find out that it only happens during google plus login scenario and from the backend logs I see the issue is only because of below parameter which is profile photo url.
https:%2F%2Flh3.googleusercontent.com%2F-xPc6TIzQiFA%2FAAAAAAAAAAI%2FAAAAAAAAAeU%2FUIIpz-4G1dQ%2Fphoto.jpg%3Fsz=400
Backend Request from logs(Data changed for privacy reasons).
/_ah/api/registrationAPI/v2/XXXXXX/Rahul%20Purswani/rahulfhp#gmail.com/https:%2F%2Flh3.googleusercontent.com%2F-xPc6TIzQiFA%2FAAAAAAAAAAI%2FAAAAAAAAAeU%2FUIIpz-4G1dQ%2Fphoto.jpg%3Fsz=400/XXX/YYY/VVV, returning NOBODY to imply authentication is in progress.
My Api Class Declaration :
#Api(name="registrationAPI",
version="v2",
namespace=#ApiNamespace(ownerDomain="backend.XXX.XXX.YY",ownerName="backend.XXX.XXX.YY",packagePath=""))
public class PlayerRegistrationEndPoint {
}
And to my surprise this only happens when I test the Api on local development server through real device. If I deploy my api all works fine, I have spent almost the day to narrow it down, If you have any clue about it that will be really appreciable.
Are you accidentally logging the bytes of your pictures using logging.info(), logging.error(), print, etc? Logging bytes to either the logger or standard out can make the dev instances (or even production instance) go into zombie mode.
This has happened to me many times. Check all logs to make sure you aren't trying to log something that isn't a basic variable type.
I was getting this issue since we migrated our code base from Eclipse to Android Studio, during this migration our app-engine sdk version got changed from 1.9.22 to 1.9.18.
Looking back and doing comparative analysis with why it used to work with eclipse, I tried using 1.9.22 app-engine sdk here and issue got resolved, the zombie behavior is no more and even in development environment everything is stable now.
I also checked & removed all the loggers and out statements, though the issue was not fixed with trying that alone.
Thanks for even letting me know that it can also go wrong in future during development environment testing.
I'm making a Cordova 4.0 Android app that will be sold in Google Play, and I would like to prevent illegal use of it (for example preventing someone to extract the APK from the system and re-distributing it).
One theoretical way of doing this would be by checking that when the app is launched by the user, he did actually download it from Google Play (versus being it sideloaded). I'm not even sure if this is possible or if there's an alternate way of doing something like this.
One way that works in other cases is to use require some sort of login when accessing the app, but in this case I can't do that. Any advice would be appreciated!
Google offers a way to implement validation / licensing:
http://developer.android.com/google/play/licensing/index.html
Take a look if this is what you need!
One suggestion would be for those apps which are get connected to a server to fetch some data.
App verification token
Generate an encoded 64-bit long token and store on both device & server as well. This will be a unique token per app
Whenever app tries to connect to server, it sends the device token details. Server needs to verify it before fulfilling its request.
On specific events, server can generate a new token for a device.
Same way, device token can be mapped to a user or an app on the server side.
Token could carry some app related information, for instance.
first 4 or 6 digits represent app size
second block of digits could represent user specific or device or some other details
Or another block could hold app contents modification date
In case of any change, server could verify the app size, last app contents modification dates, etc.
Generally it is recommended to uglify, obfuscate and minimize app resources before submission.
You can use the package manager class to determine the source of an app (only google or amazon currently detected)
You can similarly use google analytics which gives same information.
This is pretty neat since Android stores the source of every package, allowing apps to know where they came from, to prevent piracy and sideloading.
Great if you always publish to google or amazon. Useless if you sideload your app.
We run a web application with a Java Script- and an Android front end. We use Google IDs with OAuth for authentication. Everything worked find until today authenticaiton suddenly stopped working. There was no new software version deployed or any operational changes. Now, when a user tries to log on via the browser application, Google issues
401. That’s an error.
Error: disabled_client
The OAuth client was disabled.
Request Details
scope=openid profile email
response_type=code
redirect_uri=https://***.net/signin-google
state=***
client_id=******.apps.googleusercontent.com
That’s all we know.
When logging in via Android App, authentication fails too, GoogleAuthUtil.getToken raises an unspecific exception.
I couldn't find much information when googling for this error message. Some say, one should try to change the application name in the consent screen. This didn't help in my case.
In developer console I noticed, that I cannot create a new Client ID for this project. I always get a technical error ("Server Error Whoops! Our Bad.") with a tracking number. Seems to be related.
I have a total of 7 Client IDs registered for this project and 3 public API access keys.
Is it possible, that Google explicitly disabled our project? That's how it actually feels. For what reason? I didn't get any notification. Our product is an application for access control, nothing special or illegal here.
Any ideas? This is a production environment, so for us the problem is absolutely severe.
Thanks for any help!
In the meantime we found out, that our Android App was removed from the Play Store and we got following notification:
This is a notification that your application, <...>, with package ID <...>, has been removed from the Google Play Store.
REASON FOR REMOVAL: Violation of the Personal and Confidential Information provision of the Content Policy.Please refer to the policy help article for more information.
We don't allow unauthorized publishing or disclosure of people's private and confidential information, such as credit card numbers, government identification numbers, driver's and other license numbers, non-public contacts, or any other information that is not publicly accessible.
We are very careful about the data inside our application and we take privacy and security extremely seriously as the hole app is about security and our customer's trust is absolutely essential. However, we recently introduced a feature that periodically sends the LogCat output to our servers for debugging reasons. Our app is in an early preview state which we make clear in the app description. It's used by a very limited number of people as it can only be used with a special piece of hardware we provide. The LogCat output only contains data from the app itself, no confident data of any kind. We published a couple of related apps and not all have the feature even included but all were suspended. However, we guess that this feature is the reason for removing.
Edit
In the meantime we wrote an appeal via the form provided on Google Play. The ban was removed from Google Play and the related Google OAuth Client shortly after.
We were informed, that our App collects names of running tasks and sends them to our servers, which is not the case. However, we used the crittercism library and the crittercism docs suggest to require the "GET_TASKS" permission, what we did. I don't think, that Crittercism is considered as dangerous as it's used by lots of applications. But maybe the combination of a Logging Service on the one hand and the GET_TASKS permission on the other hand, although not dangerous in our case, triggered some automatic rules at Google.
To fix this we simply removed Crittercism and all related permission requirements as it wasn't very useful for us anyways.
Is there any way, to check on server if this is my application sending data or it's someone's who decompiled my app? Note that both my and fake apps may be downloaded by user from Google Play. I have only one idea - in Google Play you cant post two applications with the same package names, so maybe I can send package name to server or something like this.
It can't be done without some help from OS - because an app would not know whether it was modified (the modification check itself can be hacked).
The ways I'd go would be the following:
Excercise the options Google Play Store gives you - license check and app encryption
Add some auth data to the application itself and verify it on the server (some encryption key). The data should change with each version
Accept only 2-5 last versions (for people who haven't yet updated)
This way, any pirated version will be valid for only a week or so... And for someone wanting to use the app constantly it will be easier to buy it, than re-download it every 1-2 weeks.
It won't protect you completely, but will make thievery time-consuming and hardly worth it given the option to buy the app. Enough to convince the users who would have bought the app to buy it. Those who pirate things out of principle can not be converted in any case...
there are some points which can make your code and application more safer.
use proguard(see on android devlopment site) it offuscates(other words makes it messy at compile time) your code.
secondly you could use encryption and decryption send some secret key encrypted