0

We are working on a redirecting page for our mobile apps.

Users would go to a page like: https://mobileredirect.our-app.com?target=https://clientdomain.com/some_resource

Mobile apps on iOS and Adroid can intercept the "mobileredirect.our-app.com" domain, when installed. If not installed, the browser will open, and redirect the browser to the client domain.

This is contains an obvious problem. Anyone can put any domain in the scheme and this becomes an attack vector. I would like to be able to verify if the URL is actually coming from a trusted source. We need to do it this way, as we don't control which domains could use our mobile app.

Ideally I'd like to do this in the as well browser, without the need for a server.

I was thinking of using a library like simple-crypt, using the Asymmetric operation. Trusted servers would have the private key, they would encrypt the URL end it would end up like this: https://mobileredirect.our-app.com?target=ENCRYPTED_URL. The clients (mobile apps, and the website) would contain the public key to decrypt the URL. This does mean that the public key will be visible to everyone.

Now my question:

Is this a good idea? How can this be broken? Is it overkill? Are there easier ways (e.g.: use some type of checksum algorithm)?

This has been answered in a cross post on the security stackexchange

Bert Goethals
  • 7,867
  • 2
  • 20
  • 32
  • 1
    Wait, what’s the threat here? Malicious apps installed on the user’s device? You can’t protect the user from their own malware. – Ry- Jul 03 '17 at 10:04
  • 1
    You have the keys reversed, encryption is done with the public key. Signing is done with the private key. Provide the threat model in more detail. – zaph Jul 03 '17 at 13:22
  • The domain https://mobileredirect.our-app.com will be trusted by the user. Anything it forwards to would also - by association - be trusted. It's now very easy to build a phishing attack. Also, by emulating the behaviour of our service, an attacker could try to have the app send user credentials to it, by using the redirect. This is also a problem. By giving the clients (shite, and IOS app) a way to verify if the URL is coming from a know source (ability to decrypt), we build a defence in there. – Bert Goethals Jul 03 '17 at 14:00
  • Using asymmetric encryption here is not a good idea. You don't have two parties that want to verify each other. You have **one** party that wants to ensure it was the one that created the URL. You should instead use a MAC. Consider having `/target=blah&mac=blah`. This way the server can verify that it was the one who created this url initially **and** that it hasn't been modified since it created it. When I say server here, I mean the one that handles the redirects. – Luke Joshua Park Jul 03 '17 at 20:39
  • @LukePark Note that in my examples one of the clients would be browser based JS. That would mean that if I use a MAC based solution, the key would be visible to anyone. If I'm not mistaken, MAC solutions use the same key at the producer and consumer end. This means that anyone could still produce a valid URL, redirecting to their malicious service. – Bert Goethals Jul 04 '17 at 07:59
  • 1
    This is cross posted on sec.SE and has an answer there. https://security.stackexchange.com/questions/163353/validate-if-url-message-is-coming-from-a-trusted-source – Tobi Nary Nov 03 '17 at 12:50

0 Answers0