I developed a smart home skill for my company, I did it without using HomeGraph as final user don't care about that they just want a couple of easy traits implemented in devices. Is it required to use Homegraph in order to pass Home suit test and get the certification request accepted?
Thanks!
You can continue to develop your project and test it on your account, but in order to successfully submit for review, you need to abide by several certification policies:
All devices are expected to report state updates to Google through the HomeGraph API’s Report State, with the exception of command-only devices like IR controllers.
Developers shall report device configuration updates in your ecosystem to Google; ... This can be accomplished through the Request Sync API.
To summarize, you will need to integrate the HomeGraph APIs and pass the test suite in order to be ready for certification.
Related
We have a live mobile application supporting registering with the user's mobile number.
We send OTP upon each register request and now we have hundreds of spam requests costing a lot of money due to the SMS service fee.
Rate limiting on Ip is applied.
Rate limiting on device id is also applied.
The register request is secured by adding a signature to the header using the HMAC SHA-256 algorithm, the key used to generate the signature stored in mobile code.
But it turns out that this is not enough to secure the process.
Is there any other practice we should do to solve the spam issue?
We are using Flutter for the mobile app
Your Problem
We have a live mobile application supporting registering with the user's mobile number. We send OTP upon each register request and now we have hundreds of spam requests costing a lot of money due to the SMS service fee.
Registering with the mobile phone number to deter spam isn't enough because a lot of services exist in the internet to provide anyone with free mobile phone numbers, that are often used to workaround registrations or any other services that require you to provide a number.
Rate limiting on Ip is applied.
Malicious users can rotate their IP address when they use a script (bot) or run your app in an emulator. Also IP addresses in mobile are very dynamic, its not like in residential broadband where they stay stable for long periods.
Rate limiting on device id is also applied.
The malicious user will rotate the device id when using a bot, an emulator or a rooted device.
Reverse Engineering
The register request is secured by adding a signature to the header using the HMAC SHA-256 algorithm, the key used to generate the signature stored in mobile code.
The malicious user will reverse engineer you mobile app statically to see how the HMAC signature is done and then replicate it on its script. In a series of articles around Mobile API Security I wrote an article about statically reverse engineering an app, while in the context of extracting an API Key the principles remain to extract the logic for the HMAC signature. You can learn how to it by yourself on your own app by applying the same basic technics I used on the article How to Extract an API key from a Mobile App with Static Binary Analysis:
The range of open source tools available for reverse engineering is huge, and we really can't scratch the surface of this topic in this article, but instead we will focus in using the Mobile Security Framework(MobSF) to demonstrate how to reverse engineer the APK of our mobile app. MobSF is a collection of open source tools that present their results in an attractive dashboard, but the same tools used under the hood within MobSF and elsewhere can be used individually to achieve the same results.
During this article we will use the Android Hide Secrets research repository that is a dummy mobile app with API keys hidden using several different techniques.
The malicious user may also reverse engineer dynamically your app to understand how it communicates with your API server in order to do exactly the same on its bot.
This is usually done with a MitM attack on a device that the malicious user controls and a lot of open-source tools exist to help with the task, being the most known ones mitmproxy and Frida. Turns out that I also wrote an article on how to use this tools, not to extract the HMAC signature, but to bypass certificate pinning, but the basic mechanics to perform the dynamic analysis are the same, therefore I invite you to try this techniques against your own app. Learn the basics of MitM attack with Frida and mitmproxy on the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to disable certificate pinning and in the process you will also learn how to create an Android emulator with a writable system to allow for adding the custom certificate authority for the proxy server into the Android operating system trust store. This will allow us to bypass certificate pinning and intercept the requests between the mobile and its backend with a MitM attack.
The Difference Between WHO and WHAT is Accessing the API Server
But it turns out that this is not enough to secure the process.
No, its not enough because its not that hard to bypass with the several techniques I shown above.
In order for you to improve your security posture when developing an application you first need to understand the difference between who and what is doing the request to the API server.
In the article Why Does Your Mobile App Need An Api Key? you can read in detail the difference between who and what is accessing your API server, but I will extract 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.
So 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.
When you grasp this idea and it's ingrained in your mindset, then you will look into mobile API security with another perspective and be able to see attack surfaces that you never though they existed before.
Possible Solutions
Security must be always seen as a layered approach, where you add as many layers as needed to deter the opponent from even trying to break them, or if in the case they try they will need a lot of resources, knowledge and time. This not new to software development, its being done for centuries, like in the medieval castles and prisons.
Is there any other practice we should do to solve the spam issue?
I recommend you to read this answer I gave to the question How to secure an API REST for mobile app?, especially the sections Hardening and Shielding the Mobile App, Securing the API Server and A Possible Better Solution.
From this answer the Mobile App Attestation would be the most suitable for you to employ in order to give a very high degree of confidence to your API backend that the request is indeed from what it expects, a genuine and unmodified version of your mobile app, not from a bot, an emulator, a jail broken device or whatever other technique being used by the malicious user.
Do You Want To Go The Extra Mile?
In any response to a security question I always like to reference the excellent work from the OWASP foundation.
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.
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.
How smartsheet developer tool account is different from paid account.
Also how developer account can be use for API call as pre-production environment.
Developer Tools can be enabled on any Smartsheet account. Having the Developer Tools enabled allows you to create an app for implementing the OAuth flow.
The purpose behind having a separate Developer account is to ensure you can experiment with the Smartsheet API without worry of making changes to critical items needed for every day work.
Since the Developer account is signed up with a different email address than the one you use for your main Smartsheet account it is a completely separate environment. But, it still acts like any other Smartsheet account. Without sharing the account to items in Smartsheet it won't be able to access them. This way you can create Sheets, Reports, and Dashboards to simulate the data you will be working with. Then as you make API calls to them you know you aren't causing issues for the real items people at your company are working on in Smartsheet.
One approach would be to share the Developer account to a collection of things you will eventually be running your requests against in production from your main Smartsheet account. Then in the Developer account make copies of those items. Once this is done you can un-share the Developer account so that it no longer has access to the real items in Smartsheet. Then you can make requests to the API to test your code and see the results as it would really happen. Once you've proven your code works you can adjust the access tokens and id numbers of Smartsheet items to work for your production stuff.
I need to provide a facility to approve a document through their mobile device.
Does Hyland Onbase provide an API that we can use in a mobile app for approver?
Hyland Software offers a Mobile Application that will allow for use in Workflow or merely document retrieval. They also have a very robust API option.
The new version of Onbase have an Rest API that let you acces workFlow functionality from your program, you will need to check the license to make it work.
All my hardware is already developed. I use MQTT for communication between my devices, I have lights, fans, heaters and many more ioT appliances. I can controll all of these from my Android application which i have built. I would like to use Google Assistant to control my devices as well. The status of my lights (on/off) are stored in a sql database and when ever a change occurs to the database(detected by the hardware) my hardware can control that specific light. In My Android app i do the same thing which is updating the databases value(on/off) of the light and the change is detected by my hardware platform. Can i use Google Assistant to update a sql database value?
I can create a webserver( ASP.NET C#) and pass the command to the sql database of my relevant customer if google assistant can invoke the username or email, lightID, command to my webserver. Can google assistant do this? If not how would achieve this.
It sounds like you want to take a look at the Actions on Google Smart Home API which will let the Assistants Smart Home controls work with your control server directly.
Without knowing exactly how your database or existing web server are configured or hosted, I can speak only broadly at best. Your web server will need to implement two primary things:
You'll need an OAuth2 server that can issue tokens that represent your users. This is how Google will associate the user's account on the Assistant with your account, and how Google will identify (to you) which user is issuing the command.
You will need to implement a webhook at a URL on your web server. This webhook will be sent a POST message containing a header with a valid auth token (that you issued) and a JSON body. The JSON will contain information about the command that has been issued by the user. Your HTTP reply body will also be JSON. For details of the JSON formats and all the fields that it can send and that you must reply with, consult Google's documentation.
There are a number of different commands (which Google calls "intents") that Google can send you on behalf of the user. You should be able to handle all of them by either querying or modifying your database:
SYNC - A request for what devices this user has, some of their configuration information, and what commands they respect.
QUERY - What is the current state of the devices for this user.
EXECUTE - Change the state on some of the user's devices.
RESYNC - (Future update) A re-request of the user's device info.
Today I have been trying to implement the rest API into my application to look up transaction information from a transaction ID (GET /v1/payments/sale/)
I have implemented everything correctly on my end and set the mode to "live" and I can't seem to get details from a transaction.
Here is the full error code:
{"name":"REQUIRED_SCOPE_MISSING","message":"Access token does not have required scope","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#REQUIRED_SCOPE_MISSING"}
And here is documentation on what I am trying to do: https://developer.paypal.com/docs/api/#look-up-a-sale
Any help would be appreciated.
Thanks.
There are few things you could do to make sure your configurations are set right.
If the mode is set to live, are you using the live credentials instead of sandbox. You can select the sandbox app and copy the live credentials from there. See bottom part of this image.
Make sure Payments are enabled on live. PayPal has a dashboard page, where you could see all the services that you have enabled to work with Live environment. This prevents accidents on unknowingly using an API on live. You can check the status here
Is the sale that you are looking for created by the same clientId that you are using for making a GET call ? Only the app who creates the sale, can view the sale.
In the mean time, PayPal has created SDKs for many languages to support REST APIs. They are actively developed, and maintained, and could help you mitigate issues in handling tokens, credentials, etc, and allows you to quickly use APIs faster and in a way that could be upgraded easily. Also, few SDKs come packaged with Sample codes, and wiki documentations. Few are still under development, but you can feel free to contribute back to these open source SDKs.
When I had this issue, the problem was that I was making REST requests using the Identity API token. Basically, I was logging users into my website with Paypal then using that token for REST requests when another token from the REST API service should have been used. "
Here is the support ticket from Paypal SDK deveoper Randy who helped answer my question even though I do not use the SDK. Thanks Randy:
https://github.com/paypal/PayPal-PHP-SDK/issues/785#issuecomment-282749095