Does Google expose API for Find My Device service?
I would like to build a NodeJS backend to extract the location of my friends` phone using Google Find My Device service (using their gmail email).
Of course, they need to approve sharing their location first.
If these API are exposed, what is the process and how the authentiction works in this case.
GCP support recommended posting my question to the developer community on Stack Overflow.
There is currently no API for googles Find my device feature.
This is a featue they offer themselves I don't think this is one they will want to share with developers.
Related
After reading around it appears that trying to protect a publically accessible API (API used by an app/site that does not need a user to log in) appears to be fruitless, e.g. store key in app, user can reverse engineer app.
My question relates to how one can protect as much as possible and slow down abuse of a public accessible API...
Rate-limiting? Check request origin (although can be spoofed).... anything else?
Also if the site is SSR, could it just be protected by the server's IP?
YOUR QUESTIONS?
After reading around it appears that trying to protect a publically accessible API (API used by an app/site that does not need a user to log in) appears to be fruitless, e.g. store key in app, user can reverse engineer app.
Security is all about defense in depth, thus is all about adding as many layers as you can afford and required by law in order to mitigate the risk, therefore any defense you add it's one more layer that will prevent that simple/dumb automated scripts from accessing it, while at same time will increase the level of skills and effort necessary for an hacker poking around to overcome all defenses.
Rate-limiting?
This is kind of mandatory for any API to employ, otherwise an automated script can easily extract an huge amount of data in seconds. The more strict this rate limit is applied, the greater may be the chances for other layers of defense to detect that unauthorized access to the API may be happening and try to mitigate/block it. To bear in mind that the rate limits can be bypassed by adapting the attack to make requests that do not trigger it, and in some cases easily automated for that Software that give back in the response header the throttling values being applied.
Check request origin (although can be spoofed)....
Yest it is easily bypassed, but why not? It will be one more layer of defense that filters out some dumb automated scripts/bots.
Also if the site is SSR, could it just be protected by the server's IP?
No matter if a SSR site or any other type of app, when used from a mobile phone the IP address can change during the load of a page or mobile app screen, because when the phone switches between masters the IP will change. Also to bear in mind that in an office or public wifi all the users on it will have the same IP.
The use of it as a blocking measure on its own needs to be carefully evaluated, and normally requires fingerprinting the request in order to reduce the risk of blocking other valid users sharing the same network.
I would use it very carefully to avoid/block/throttle requests only when I could establish that hey are known bad IPs, that you can collect from your own requests history and/or from public datasets.
WHO IS IN THE REQUEST VS WHAT IS MAKING THE REQUEST
A common misconception around developers of any seniority is about not being aware that the who is in the request is not the same as what is making the request, therefore we will first clear it out...
The Difference Between WHO and WHAT is Accessing the API Server
While your API is not using user authentication is important to be aware of this distinction in order to better perform informed decisions around the security measures to be adapted in the API server.
I wrote a series of articles about API and Mobile security, and in the article Why Does Your Mobile App Need An Api Key? you can read in more detail the difference between who and what is accessing your API server, but I will quote here the main takes from it:
The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is it a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?
The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.
The best way to remember the difference is to think about the who as the user your API server will be able to Authenticate and Authorize access to the data, and think about the what as the software making that request in behalf of the user.
DEFENDING THE API SERVER
My question relates to how one can protect as much as possible and slow down abuse of a public accessible API...
For Mobile APIs
For an API serving only mobile apps you can use the Mobile App Attestation concept as I describe in my answer to the question How to secure an API REST for mobile app?.
For Web APPs
For an API that only serves a Web app I would recommend you to read my answer to the question secure api data from calls out of the app?.
DO YOU WANT TO GO THE EXTRA MILE?
anything else?
It seems you already have done some research but you may not know yet the OWASP guides and top risks.
For Web Apps
The Web Security Testing Guide:
The OWASP Web Security Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.
For Mobile Apps
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
OWASP - Mobile Security Testing Guide:
The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.
For APIS
OWASP API Security Top 10
The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.
Just for a quick answer
I can suggest at least one via solution which is to use an API Gateway (like Kong, Express Gateway or AWS API Gateway, etc.).
The API Gateway allows you to create API consumers (e.g: buyer mobile app, seller mobile app, buyer TV app). For each API consumer, an auth key (or even OAuth 2.0 credentials) will be generated and asigned respectively.
You then can use the auth key or OAuth 2.0 credentials (ID and secret) to access the APIs securely (even for the public ones, as API Gateways will only allow access from valid API consumers).
How about request from web?
You can configure API Gateway to detect requests from web and instead of using auth key or Oauth mechanism, it can use domain white-listing CORS protection mechanism.
How about user access token (generated from successful login)? Any conflict here?
IMHO (emphasized), after getting user access token (e.g: a JWT), for every authenticated-user-only requests you will send both API Gateway auth key token user auth access token. Referencing to Exadra's answer above, we can consider API Gateway key is to verify the "what" (mobile app) while user access token is to verify the "who" (login user).
For our mobile apps we implemented our adapters using JavaScript where procedures simply do MFP.Server.invokeHTTP. But now we need somehow integrate with IBM Integration Bus (IIB), and I can't find any information how to do it.
I have only limited knowledge how Integration Bus works and why it needs.
Is it possible to do it with JavaScript or it possible only in Java (also all examples, that I found - it simple how to create services for IIB)?
Should we configure MobileFirst Server (via Operation Console) to connect to IIB or we need import additional packages?
If I get it correct you are already calling web services via HTTP .
IIB provides you web services like REST SOAP... in your case you can simply ask your team (IIB ) to build services as REST and expose them... from you mobile server you can simply call them like any other service... like you can provide the IIB rest service url in you http method and get resoonse back.
I'm trying to create an integration to OneDrive using the Microsoft Graph API. Our app is fully client-side, there's no moving parts on a server, so authentication has to be directly browser to Microsoft.
We have an existing integration with OneDrive that uses the older OneDrive API. That does permit client-flow authentication.
There is an example for AngularJS, but that turns out to require a NodeJS server and have a server-flow authentication, again. NodeJS authentication requires a secret to be passed over, which I obviously can't put in public JS.
I cannot find any examples of authenticating to the graph API without a secret, am I right in saying that client-flow authentication is not supported?
p.s. I have looked at Writing a simple microsoft graph client without using a web server, but this question seems to be asking whether it's possible to make API calls without user interaction, rather than what I'm asking.
If I understand your scenario correctly, you're looking for the implicit grant. I wrote a blog post on using this a while back that might also be helpful.
What should be a better way to specify a valid SDK domain for LinkedIn Oauth while using it in your Chrome extension?
I am trying implement LinkedIn Oauth in my chrome extension and got confused because chrome extension it completely different environment than a simple web application. Don't what should be callbacks functions.
If anyone has done linked Oauth with Chrome extension then please share your experience.
If you're using chrome.identity API to handle OAuth, then you can specify
https://<extension-id>.chromiumapp.org/<anything-here>
as your callback URL. Note that no network request will actually go to that address - it'll be automatically intercepted in your extension. See the Non-Google account authentication guide in the docs.
Note that this potentially involves putting your secret API keys inside the extension. If you want to avoid that, you'll need to set up your own server to handle it for you (and not use chrome.identity).
I am trying to access GCE information in a read only way to display data about an infrastructure on my web site. Basically I want to get an OAuth2 token using JS API and then pass it to a Python Backend to do the API calls to GCE. My site is not hosted on GCE at all.
I get however confused in the proper way to set this up. I have created a Google application so it can ask for the authorizations and ask for access to the GCE APIs. I did start from the sample available at https://code.google.com/p/google-api-javascript-client/source/browse/samples/authSample.html. However each time I do run the sample I get an error in the first phase of the authorization process, mentioning an error due to 'X-Frame-Options' to 'SAMEORIGIN'.
Trying to isolate the error and comparing with running the Google sample from my site, it seems this is purely linked to the settings of my app (basically the google sample with my app ID does not work ) and I get lost in how to debug this process. Is there any methodology that could be applied here?
The sample you are following is for retrieving a profile in Google Plus, using the 'Public API key'. This type of key is used only to retrieve public data. If you want to access information on GCE, you must use OAuth 2.0 to authorize requests. For implementing this, you have different scenarios as web server, installed app, client-side (JS), etc.