I use a device group without a server as documented here. I want to know if it's possible to design a chrome extension in order to use GCM notifications in these conditions. I know I can add/remove a device using HTTP request and an API key (so emulating the server) but this approach has several problems from security point of view because I need to put my API key in the extension. What I'd like to do, instead, is to use the approach used on Android but I didn't find a way.
Related
I'm trying to create some sort of SDK that we intercept each request from my app regardless of which HTTP client it's using (be it native HttpURLConnection, OkHttp, Retrofit etc.). And including traffic from third-party libraries like Firebase Analytics etc.
I need to intercept and check few parameters then decide whether to allow or block current request.
I don't want to use any Custom VPN as it has some side effects like showing system level Notification and all traffic from the user device.
Is it possible to capture all requests by setting app level proxy?
If possible, How to achieve it in code?
You can use Retrofit
The retrofit will save your development time, And also you can keep your code in developer friendly. Retrofit has given almost all the API's to make a server call and to receive a response. internally they also use GSON to do the parsing. you can go through this link you will get more info Alos you can see the difference with other libs
You could give a try to implement a custom VPN with https://developer.android.com/reference/android/net/VpnService. With this you should be able to control which traffic is allowed to access the internet and which not. As you wrote, that you'll create an SDK, the implementors should know the side effects of VPNs in apps (ongoing system notification, every traffic is routet through that VPN, etc.)
I will start with a very very short introduction on OS certificate pinning for Android. Starting with version 4.2 of Android system/OS level SSL/TLS certificate pinning was introduced (see also this URL for more info.). The list of pinned certificates using this mechanism is located at: "/data/misc/keychain/pins" and contains by default around 40 entries for Google services like mail.google.com, youtube.com, etc. I would very much like to have my own certificate pinned by having it added to this list. However, modifying this list requires an Android permission (android.permission.WRITE_SECURE_SETTINGS) that's only available to system apps.
Doe anyone know if there might by some kind procedure in place at Google to submit a request to be added to this list (i.e. /data/misc/keychain/pins)?
WebViews are tricky, not least because there is no perfect way to implement pinning in them except with Android N using Network Security Configuration.
The best you can do is override shouldInterceptRequest and implement the network calls yourself using one of the methods described in Android Security: SSL Pinning, however this only intercepts GET requests so if your WebViews use POST requests then you are out of luck. Android-SSL-Pinning-WebViews shows an example of doing this.
I have an android application. The application reads data from my server and displays them to the user.
Now, the question is: How to prevent someone from making a bogus app and asking my server to send data to this app?
This wastes both my bandwidth and makes use of my content while allowing people to create competitive apps using my data.
As you know, trying to prevent reverse engineering is like trying to stop piracy: impossible. Android reverse engineering especially it's like stealing candy from a baby.
Use API Tokens. Possible solutions:
HTTP Basic Auth example (only if you are using https)
Query Paramter (like https://example.com/resource?token=3786428762) (also only over https)
HMAC - sophisticated and more complex to implement, requires substainsial redesign of the backend communication, but the most secure
But mind you, either way you need to somehow hardcode a key/salt/hash/password in your app which can be reversed engineered one way or the other. There is no real (practical) possibility in Android to avoid rogue clients from accessing your backend (especially in rooted devices).
I would recommend HTTP Basic Auth since it's the best tradeoff in effort, usability and security (It's also used by the majority of public apis) It's very easy to implement since you only need to send a hardcoded http header, it's supported by practically every http server and it does not change your API and pollute it with query parameter and it's also reasonably secure if used over https.
Make the server require an API key and obfuscate the key in your code, see this answer: Best Practice for storing private API keys in Android
If you use http server, you can use http auth basic
Basic access auth
You could use something like reCAPTCHA to verify that the client is not a bot.
I would like to know the differences between creating GCM API Key by Accessing APIs directly from Android and by Accessing APIs via a web server. I'd like to know the advantages and disadvantages of both.
Thanks
I finally figured out what you were asking. According to the GCM Docs, in order to obtain an API Key, you should choose Accessing APIs directly from Android.
To obtain an API key:
1. In the sidebar on the left, select APIs & auth > Registered apps.
2. Click Register app.
3. In the Name field, type your app's name.
4. Click Android > Accessing APIs directly from Android.
5. Under Android identification, type the package name for your app.
6. Enter an SHA1 fingerprint. To get this value, follow the instructions in the console help.
7. Click Register.
As to what's the difference in general between Accessing APIs directly from Android and Accessing APIs via a web server, I assume that in the latter case, the Android device doesn't access the Google API directly. Instead, your web server communicates with the API and delivers to the Android app the relevant data. In GCM, the Android device must communicate with the API directly, in order to register the device to GCM.
I believe you are referring to the differences in the two types of connections allowed for GCM (namely HTTP & XMPP/CCS)? The differences can be found here.
In short...
HTTP can only push messages downstream to devices, whereas XMPP/CCS
is bidirectional.
HTTP is synchronous whereas XMPP/CCS is asynchronous.
A caveat of using XMPP/CCS (that isn't very well documented IMO) is that you must sign up to use GCM with XMPP here and hopefully be approved/accepted where with HTTP, you can just simply use it.
I am beginning a project that will have three layers to it: a web front-end, a mobile front-end and WCF back-end. Authentication needs to be done via Active Directory, but both web front-ends will be using forms authentication to grant/reject access to certain areas, and all user control will be handled via groups inside AD. This specifically applies in the WCF side where I would like to be able to utilize the built-in Permission.Demand() functionality.
I have two questions with this. First, does anyone know of any best practice examples for doing this? Specifically in regards to passing the credentials (without the password) to the WCF service so it knows the context under which it is being accessed. Secondly, the future includes creating an Android app (and probably iPhone/Windows Phone versions as well) so I need to make sure the method used will work cross-platform with those.
set the PrincipalPermissionMode to Custom, write a custom Authorization Policy (http://msdn.microsoft.com/en-us/library/ms729794.aspx) and in the implementation of the Evaluate method do the following:
evaluationContext.Properties["Principal"]=HttpContext.Current.User;
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/8f424d4f-2f47-4f85-a6b0-00f7e58871f1/