We continue to build our fairly small applications on Android, iPhone and other mobile operating systems. This is fine and fun in the beginning of a new era, but when mobile OS matures, gets to be the preferred device for business people in motion, they want something more.
One would guess they want the same access and capability to ERP, MRP, BI-solutions and other reporting systems in there phone, right here, right now. How would we as developers deliver these demands, in a secure yet useful way? Is there today support for this kind of applications given they are not today on the web?
EDIT: I understand the fact most EIS-solutions are web based. Still they are behind company gates, heavily garded by Cheif Information Security Officer (CISO) and his/her staff. Thus they are not accessible through the open unsecure internet but insede companies intranet or internal network. To my knowledge, accessing an EIS using an adress like https://www.thecompany.com/eis-solution/ signing in with username/password isn't done today. In the old days, a VPN-solution was one way to access inside EIS-solutions, but will this be done using a mobile device as well?
I cannot understand what distinction you are making. Oracle Financials -- for example -- is a web-based application. It requires username and password. It can be run in a "portal".
Most companies (even very small ones) use the Web-based deployment through Virtual Private Networks.
ERP, MRP, Financial and BI applications
Are web-based.
Are trivially available from mobile devices.
The vendors are starting to include appropriate changes for the small screen.
"business people in motion" have complete access to all web-based applications. All a company needs to do is (a) purchase or (b) convert their applications to the web.
And Oracle, IBM, CA, HP, SAP and many others have already made many of their applications web-enabled.
Related
I want to build an app to transfer message history between iOS and Android.
Apple does not allow third party apps to access messages, but Samsung Smart Switch circumvents this by using either phone-to-phone USB connection or by accessing iCloud. Google phone transfer seems to do a similar thing.
How do these apps make this possible and is this something third party developers can do?
I don't think you can transfer things over like that from Android to Apple iPhone unless they give you the option when you are first setting up the iPhone to transfer contents over from android and it also transfers the messages.
Another option though it's been a long time since I have used an Android device. You could use something like https://messages.google.com/web to load up your android messages from your phone and possibly just export them and save them to your computer.
As for developing such a tool, working within the messages API for apple. I think you can only develop extensions or addons but can't directly access the content for security reasons. Without further research, the companies might be only allowing the company to do this via a contract between them, but would not let a 3rd party vendor such as you or I access this data.
https://developer.apple.com/app-store/review/guidelines/
Nowhere in the guidelines does it specify that you can't access the SMSes. But you can only access it if you use private methods which are not allowed and will get your app rejected.
You can only access data for which Apple supplies a documented API. You can not access files outside of the Sandbox of your App unless Apple provides an API for it.
Is it possible for other apps to read my app's signature toString() format? Because I'm using my app's signature as the first core security of my app. Is it possible to crack? What else can i use as a password of my app that can't be seen even when decompiled? That my app will get void when that thing has changed or my app gets decompiled?
Your Mobile App APK is Public: You Don't Control It Any-more
Is it possible for other apps to read my app's signature toString() format?
From the moment you ship your mobile app to the public you loose the control of it and anything on it it's not a secret any more because a lot of open source tools exist to help reverse engineer it easily, for example MobSF - Mobile Security Framework:
Mobile Security Framework is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing framework capable of performing static analysis, dynamic analysis, malware analysis and web API testing.
Instrumentations frameworks are also often used by attackers to perform dynamic analysis at runtime, for example Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
If your mobile app relies only on its own signature to prevent modifications to it at runtime then it will fail to be effective to defend against attackers, but may prevent abuse from script kids. All an attacker needs to do is to statically reverse engineer your mobile app, find and remove the protections you put in place, repackage it and sign the app with it's own key.
Repackaging mobile apps and offer them in the official Google Play store or other alternative stores is more common then lots of developers may think, and a well known one that made the news was Pokémon Go:
Remember Pokémon Go, the location-based augmented reality mobile game from Niantic Labs that became an overnight global sensation when it launched in 2016? Well, the game has had a record 2019 having surpassed its launch year in revenues, announced a live AR multiplayer feature, and, on a slightly dissonant note, sued an “association of hackers” for creating and distributing unauthorized derivative versions of the company’s mobile apps.
The staggered release of Pokémon Go meant that obsessive fans in as-yet unserved regions gravitated to repackaged apps. The relatively innocuous of these apps merely contained modifications to by-pass in-app controls. However, the sheer demand for these apps also meant that unscrupulous actors were now able to get players to download versions that had either been injected with Trojans and adware or, worse still, completely repackaged malicious apps with no Pokémon code whatsoever. These repackaged apps, however, do not automatically spawn any Pokémon in regions where the official app is yet to be launched. To get around this, players had to hack API communications to spoof locations. At scale, the proliferation of repackaged apps and API abuse opens up a new vector for sophisticated DDoS attacks.
As you can see the use of in app controls can be bypassed and repackaged apps are offered and users end-up to install and use them without knowing or knowing that is not indeed the original app, but they don't mind once it's bypassing some controls that benefits the user.
So, am I saying that you shouldn't use in app controls? In my opinion you should use as many layers of defence as you can and afford in order to make the life of attackers as hard as possible, but bear in mind that if you don't combine this in-app defences with a mechanism that lets the API backend for your mobile app to know when request are from the genuine and untampered version of your mobile app, then you will end-up to fail on your efforts to thwart the attacks of the most de-terminated attackers.
Reverse Engineering Techniques
Because I'm using my app's signature as the first core security of my app. Is it possible to crack?
Yes, it can be done using static analyses via decompilation of the mobile app and/or with dynamic analyses.
An attacker may first decompile your mobile app in order to inspect the code and understand how it works and if necessary also use an instrumentation framework to to see at runtime how it behaves and how it could be bypassed in real-time.
You can learn how to use MobSF for static reverse engineering in this article I wrote:
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.
For an example on how to use an instrumentation framework at runtime you can see the article I wrote about How to Bypass Certificate Pinning with Frida on an Android App to learn how to use it:
Today I will show how to use the Frida instrumentation framework to hook into the mobile app at runtime and instrument the code in order to perform a successful MitM attack even when the mobile app has implemented certificate pinning.
Bypassing certificate pinning is not too hard, just a little laborious, and allows an attacker to understand in detail how a mobile app communicates with its API, and then use that same knowledge to automate attacks or build other services around it.
Possible Solutions
What else can i use as a password of my app that can't be seen even when decompiled? That my app will get void when that thing has changed or my app gets decompiled?
You can make it more difficult but you cannot make it impossible for being decompiled and reverse engineered. For example, you can use the built-in Proguard or R8 compiler on Android Studio:
When enabling shrinking, you also benefit from obfuscation, which shortens the names of your app’s classes and members, and optimization, which applies more aggressive strategies to further reduce the size of your app.
Obfuscation: shortens the name of classes and members, which results in reduced DEX file sizes. To learn more, go to the section about how to obfuscate your code.
A possible better solution is to shift the decision to the API backend of the mobile app, provided it works with one. The API backend will be the one deciding when to provide or not the necessary data for the app to work, but for that the backend needs to know if the requests are from what it expects, a genuine and untampered version of your mobile app.
So, if your mobile app works with an API backend then 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 where you will learn that the use of a Mobile App Attestation solution allows for the API backend to know when the request is indeed from your genuine and untampered mobile app, thus being able to deny the ones that come from tampered or repackaged versions of your mobile app, therefore rendering them useless due to the lack of data to work with.
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 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.
Native mobile apps can use the Secure Element (or Enclave), e.g. to generate and use private keys for encrypting and signing data. These private keys are stored in the hardware of the mobile device, inaccessible to even the phone manufacturer, giving them extremely strong security properties.
I'd like to have the same functionality in a web app (which would be more widely usable since it requires no installation). Is this possible?
I've scoured the web but haven't found any good information on this. In principle, it seems that mobile browsers (because they're native apps themselves) could use the Secure Element just like any other app. In fact, as one example, I'm pretty sure they're using it to enable authentication through WebAuthn, which uses key pairs with the private key stored on the device. But... as far as I know the browsers don't expose access to web apps.
Any information on this would be much appreciated! Thanks
While you can generate keys with the Web Crypto API, accessing special security hardware chips is not possible. There is an open Issue for the spec, where this feature request is being discusses. Feel free to chime in there if you want, or just subscribe to the Issue to be informed of progress.
I have an Android application on Play Store and I want to detect if a user is using the original version of the app downloaded from play store or a mod apk from other sources.
Your Question
I have an Android application on Play Store and I want to detect if a user is using the original version of the app downloaded from play store or a mod apk from other sources.
A very simple question that embraces so many things to be fully answered, but from an high level view you can tackle this from within you mobile app or doing it from the outside.
Detecting from Within the Mobile app
Doing it from inside is known as RASP:
Runtime application self-protection (RASP) is a security technology that uses runtime instrumentation to detect and block computer attacks by taking advantage of information from inside the running software.
RASP technology is said to improve the security of software by monitoring its inputs, and blocking those that could allow attacks, while protecting the runtime environment from unwanted changes and tampering.
One thing that I observe often is that many developers are not aware that any protection they may add to the mobile app code to try to secure it can can be bypassed during runtime with an instrumentation framework, even when the code itself is strongly obfuscated. A well known instrumentation framework used to manipulate code at runtime is Frida:
Inject your own scripts into black box processes. Hook any function, spy on crypto APIs or trace private application code, no source code needed. Edit, hit save, and instantly see the results. All without compilation steps or program restarts.
In the case a developer adds a function to their code to detect if the app is the original one, the attacker will eventually find it through static analysis of the binary or through dynamic analysis at runtime, and then use Frida to hook on it to change the outcome, like returning always a result that says it's the original one. Another alternative for the attacker is to recompile the binary without said function, thus removing the protection.
So, Am I saying for you to not use self protecting code or RASP solutions on your mobile app?
No, I recommend you to use all the mechanisms you can afford in order to stop the bad actors, but you also need to be aware that they can bypass them, and try to make as hard as possible to overcome your defences, to the point that it will be time consuming for them and they will just prefer to go elsewhere to look for easier targets.
Detecting from outside the Mobile App
A better alternative is to delegate to outside the app the detection when it's running or not an original version of the binary, and if it doing in a device that is not rooted or jail-broken, and this can be done by using the Mobile App attestation concept, that I explain on this answer I gave to the question How to secure an API REST for mobile app? in the section about A Possible Better Solution.
In a nutshell the Mobile App Attestion is a solution that when full implemented attests if your mobile app is the genuine and untampered version you have uploaded to the play store, and that is running in a trusted device, not jail-broken or rooted.
The Mobile App Attestation solution differs from RASP solutions in the fact that the decisions are made outside the mobile device, therefore cannot be manipulated by instrumentation frameworks, and they also issue a JWT token that allows the backend for the mobile app to know when it can trust in requests is receiving from it.
Summary
RASP solutions fall short, because usually they don't let the mobile api backend know if the request is from a genuine version of the mobile that is running in a trusted environment, aka a device not rooted or jail-broken, but even if they do that, once the logic for doing so is running inside the mobile app, it can be manipulated by the attacker with Frida or similar tools.
On the other hand a Mobile App Attestation solution will make decisions outside the mobile device and allow the mobile api backend to be aware when it can trust or not in the incoming requests.
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.
This is possible if your app is using an external server under your control providing some important functionalities to make the app useful. This might be some cloud database or an enrollment feature. For offline or device only apps the following approach will not work.
When using the SafetyNet API the SafetyNet is returning as part of the response to the server under your control a apkCertificateDigestSha256 from the app executing the call. This can be checked if it is matching your app.
Note, that the evaluationType from the response is also important. Newer devices and versions of SafetyNet are supporting here HARDWARE_BACKED making shielding frameworks like MagiskHide useless.
I am new to android development, I have a website that is for online shopping and I want to make an android app so the smart phone users can also access it. It will use something like PHP post/get, JSON, JavaScript to get values from server and submit forms from app. My question is after doing all these, mean HTTP Connection and all that, is there any need to make a special website for mobile device too, that will be compatible with mobile device? or no need of this, just to open it in mobile app? I have googled it but can't find something useful.
I think most of visitors will visit the normal site instead of installing a unknown app.
It's your own choose, if i have the the choice i would choose both (web and app).
I think it's important to have a user and mobile friendly website.
At least you could make your website responsive so that user have the choice whether they will install a Native app or use the 'web' app.
I've met the same question.
Apps are good-looking and functional.
But the thing is, especially in China, almost everybody around me uses "Wechat" as a daily app. The most important thing Wechat can provide is an entry. By establishing an official accounts, customers can be easily linked to your mobile website. And 1)it's way more convenience than Apps. 2)Mobile website has a less developing cost than an App. 3)With HTML5 spreading to mobile terminals, the interfaces can be cool and the function can be amazing.
So, for middle/little companies, I personally recommend mobile website.