3

I am creating a web app that I will wrap in a web view for Android and iOS devices. The web view will be very simple code basically pointing at my web app. For example: www.myapp.com

I want the users to only be able to access the web app (use it) after they bought the apps in appstore. How can I prevent users from decompiling the source and go to the URL directly?

LuckyLuke
  • 47,771
  • 85
  • 270
  • 434
  • Sorry if I'm missing something really obvious, but how would a user get the code to decompile without first buying the app? Are you asking about what to do if one user buys it, decompiles it, and shares the URL? – guest Apr 01 '14 at 21:39
  • possible duplicate of [Django: Only accept requests coming from my applications](http://stackoverflow.com/questions/22750014/django-only-accept-requests-coming-from-my-applications) – Paulw11 Apr 01 '14 at 22:07
  • 2
    A word of warning - Apple has a history of rejecting apps that simply wrap a website in a UIWebview - your app needs to offer functionality above what you could do with a web browser - e.g. make use of the camera, location services etc – Paulw11 Apr 01 '14 at 22:09
  • @Paulw11 I use HTTP Basic + SSL. – LuckyLuke Apr 02 '14 at 18:20
  • hi @LuckyLuke , your purpose is just hiding your url? – CompEng Apr 08 '14 at 12:44

6 Answers6

2

There is no way from preventing the user from obtaining the URL and accessing it directly, if he really want's to, and then positing it in a online forum.

There is a way to prevent this particular scenario, but it still does not protect the application completely. The idea is to ship the application with a secret key in it's binary that get's used to sign every request sent from your site, see here for some details.

This way you can ensure that the request came from someone who had the API key, most likely your app. This would prevent the scenario where the URL gets posted on a forum and the app gets accessed directly via web browser.

This mechanism is normally used to protect JSON APIs, but can also be used to protect access to web pages from a web view app.

But this does not prevent someone from inspecting the binary to get to the API key, and produce another app or program that signs requests with it, creating a clone of your app.

For example apps like twitter had their keys exposed in blog posts.

So it's a tradeoff of security versus convenience: if you want to cover the URL being access from browsers, use an API key and periodically scan the android store for clone applications and report them to be shut down. This should be infrequent and easily spotted, and also users will report it to you.

If you want more security then put the app up for free, and manage login/payments yourself: it's much more complicated, and will discourage users meaning less sales. Using an API key seems to be the best security/convenience tradeoff.

Community
  • 1
  • 1
Angular University
  • 42,341
  • 15
  • 74
  • 81
  • I understand. What I am doing is making a web application for mobile devices and eventually desktop applications, but I want to offer the app against money on the different app stores so I don't need to deal with that my self inside the app. I also think people would appriciate that instead of having to deal with credit cards etc after they downloaded the application. But at the moment I am afraid that someone gets the URL and avoid the payment and just register an account and starts using it. – LuckyLuke Apr 05 '14 at 11:55
2

This question reminds me of another discussion here in which I participated in with a similar problem. The accepted answer have quite an extensive list of things that you can try.

For my own answer there, this is the short summary from the "Verifying Back-End Calls from Android Apps" article) that I linked:

You use the GoogleAuthUtil class, available through Google Play services, to retrieve a string called an “ID Token”. You send the token to your back end and your back end can use it to quickly and cheaply verify which app sent it and who was using the app.

In general, the approach is to add some code to check that the requests coming to your URL are produced by "authenticated/paid" users (which in the Android blog example is by checking their Google Play Services account).

Community
  • 1
  • 1
Joe
  • 14,039
  • 2
  • 39
  • 49
  • Does the same thing exists in iOS? – LuckyLuke Apr 05 '14 at 14:08
  • And in iOS this would be? – LuckyLuke Apr 06 '14 at 16:45
  • I wasn't aware whether a similar practice is available/recommended on iOS. Searching with "ios user identify" here yield some interesting results though, for example [this](http://stackoverflow.com/q/7273014/1023092), and [this](http://stackoverflow.com/q/11597100/1023092). – Joe Apr 06 '14 at 17:35
2

Client side verification would be useless, because, if anyone knows the URL will be able to access it. And, no matter how much code obfuscation you use, it will be never hidden from a determinant hacker. Furthermore hacking is even not necessary if the request is route through a proxy, log will revealed URL anyway.

You should do a server side verification and have a simple script to see where those request are coming from.

Every HTTP request provide some information about the client. You can look into that information to determine where the request exactly came from. To add little bit more security you can modify and set your own value in HTTP header from client side.

Implementation would be different in Android and for IOS as the challenges are also different .

Android

On Android, it is relatively easy to publish an app into market, and if anyone knows your url, they can do the same trick with HTTP request and release another app. To prevent that:-

Every android app is signed by a certificate, you can send signature value with HTTP header verify that on server side. See this for how to get signature from android app.

Remember that app signature is unique and this is how Google Play store identity an app, So their is no way another developer will get a hold on that. if it doesn't satisfy you add additional header value (some secret) and change it every with every update.

HttpURLConnection and other HTTP API from Android or from Apache provide support to do that.

iOS

See this for how to modify http header on iOS.

In this case one problem is still exist is anyone can create an iOS app and do same but, on iOS, people can not simply do that as every app goes through lengthy Apple verification process. You can even have rotating secret, or generating it on the fly, with every new app update or http request, which only your server will be able to verify to make things more difficult.

Community
  • 1
  • 1
minhaz
  • 4,233
  • 3
  • 33
  • 49
  • If other developer passed my APK's package name in package manager. Then he will also get my secrets i.e. Signature value. Right? – Shreyas Patil Jun 27 '20 at 06:03
2

I believe you should use OAuth 2 to restrict access to your web server.

This question maybe of help: Options to securely authenticate mobile access using OAuth2

Community
  • 1
  • 1
Khurram Ali
  • 835
  • 12
  • 18
1

You can download from a webservice the wrapped URL (use https) and that way the URL will never be inside the app to decompile it.

Anyway, a web request could be monitored by a sniffer and possibly still retrieved.

EhTd
  • 3,260
  • 4
  • 19
  • 18
  • But can't the user just make an request to the web service that provides the URL for the real app and then proceed? Or is it something that I don't understand? – LuckyLuke Apr 02 '14 at 18:18
  • Some sort of authentication can be made for the request – EhTd Apr 02 '14 at 18:49
0

You can try these ways :

  1. Use shrinker, optimizer, obfuscator, and preverifier class like PROGUARD
  2. Divide your web site url in more pieces and put it in your strings.xml
  3. Write encryption like AES or DES to encrypt your strings of url in strings.xml
  4. On runtime you can decrypt,combine your url string and set it to a variable. And when you use it then you can set that variable to null so people cant get it on memory

I think this hides your string and people cant find it easily,

CompEng
  • 7,161
  • 16
  • 68
  • 122