6 ms·

This needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much

This needs a little elaboration. Cached Javascript in any hybrid app is a security hole because that can be exposed through a jailbreak. Depending on how much of your business logic you've pushed into the JS layer to enable that "80% code sharing" that makes managers go all tingly you may be exposing all kinds of things - cached access tokens, API keys and whatnot - to anyone who wants to install your app and mine its secrets.

scarface74 10y ago
You as an end user jailbreaking your own phone is not a "security hole". I'm not aware of any non-tethered jailbreak for iOS 10
- nb777 10y ago
  I think he's talking about application wide (not user specific) "secrets" in the javascript layer.
  - menckenjr 10y ago
    Yes, I am. As for untethered jailbreaks, http://pangu8.com/10.html http://pangu8.com/10.html mentions a few.
- rimantas 10y ago
  Just using one to potential open many more to other apps.
- davewritescode 10y ago
  Yes it is, jailbreaking bypasses critical security features of your phone. Granted, it's required to run certain kinds of software but there are better ways to run your own code on your phone (like getting your own developer certificate) that preserve the security model.
woah 10y ago
Huh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?
- menckenjr 10y ago
  Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but... http://www.wikihow.com/Bypass-iPhone-Passcode http://www.wikihow.com/Bypass-iPhone-Passcode
  - mikewhy 10y ago
    "This bypass won't work on iPhones running iOS 9.3 and up"
    - menckenjr 10y ago
      https://threatpost.com/ios-10-passcode-bypass-can-access-photos-contacts/122033/ https://threatpost.com/ios-10-passcode-bypass-can-access-pho...
  - a_t48 10y ago
    At that point your phone is fucked, anyhow. If you've lost physical control of the device and an attacker has broken the lock, you're compromised in much bigger ways.
marcinzm 10y ago
How is this any different from native code? Afaik, you can access the native compiled source code of an app on a jailbroken phone. Sure it's more of a pain to parse through but security through obscurity isn't security.
- menckenjr 10y ago
  You aren't "parsing" through compiled (and linked) code; you're decompiling it, which is a much trickier thing to do and get right. Having your app logic in Javascript in the sandbox cache is just serving it up on a plate.
- jameside 10y ago
  Definitely, running "strings" on a binary is about as easy as finding the JS for a hybrid app (WebViews or React Native). Depending on your experience it could be easier to extract API keys from an IPA than from JS. In either case the root issue is about sending secrets like an unscoped API key to the client. "Client secret" is an oxymoron in this context regardless of the programming language.
  - menckenjr 10y ago
    You'd have to know a few things first, like (1) the IPA is a ZIP file, (2) the ZIP file is actually of a directory and (3) you can dump the actual code in the JS files (if they're in the bundle directory) much easier than you can look for strings from the binary that might look like an API key. The API key is actually the least of the hazards, since you can hide that in the keychain. Having source code for your business logic shipping in your app is not good; having it be hackable business logic (by changing the JS in place) is very not good.
    - jameside 10y ago
      Shipping source code with business logic (assuming the definition of source code includes obfuscated JS) is how the entire web works today! With WASM the code that is shipped will be even further away from the original source code and really not so different from downloading ARM from the App Store or Java/ART bytecode from the Play Store.
trakout 10y ago
I'm having trouble seeing this as a valid argument when applied to cached JavaScript within a mobile browser. The same security practices apply.
- menckenjr 10y ago
  They do, and it's for this reason that the really important stuff isn't in the web page at all - it's behind the company's API. The "business logic" that you can safely push out to a browser or hybrid app is somewhat limited, which means there is a hard upper limit on the real code sharing savings you can get with hybrid apps versus full native.

scarface74 10y ago

You as an end user jailbreaking your own phone is not a "security hole". I'm not aware of any non-tethered jailbreak for iOS 10

nb777 10y ago
I think he's talking about application wide (not user specific) "secrets" in the javascript layer.
- menckenjr 10y ago
  Yes, I am. As for untethered jailbreaks, http://pangu8.com/10.html http://pangu8.com/10.html mentions a few.
rimantas 10y ago
Just using one to potential open many more to other apps.
davewritescode 10y ago
Yes it is, jailbreaking bypasses critical security features of your phone. Granted, it's required to run certain kinds of software but there are better ways to run your own code on your phone (like getting your own developer certificate) that preserve the security model.

woah 10y ago

Huh? Are you saying that the security hole is that a user could see stuff in the memory of their own phone?

menckenjr 10y ago
Or someone that steals your phone, or picks it up when you lose it somewhere. Yes, there's the lock screen and passcode but... http://www.wikihow.com/Bypass-iPhone-Passcode http://www.wikihow.com/Bypass-iPhone-Passcode
- mikewhy 10y ago
  "This bypass won't work on iPhones running iOS 9.3 and up"
  - menckenjr 10y ago
    https://threatpost.com/ios-10-passcode-bypass-can-access-photos-contacts/122033/ https://threatpost.com/ios-10-passcode-bypass-can-access-pho...
- a_t48 10y ago
  At that point your phone is fucked, anyhow. If you've lost physical control of the device and an attacker has broken the lock, you're compromised in much bigger ways.

marcinzm 10y ago

How is this any different from native code? Afaik, you can access the native compiled source code of an app on a jailbroken phone. Sure it's more of a pain to parse through but security through obscurity isn't security.

menckenjr 10y ago
You aren't "parsing" through compiled (and linked) code; you're decompiling it, which is a much trickier thing to do and get right. Having your app logic in Javascript in the sandbox cache is just serving it up on a plate.
jameside 10y ago
Definitely, running "strings" on a binary is about as easy as finding the JS for a hybrid app (WebViews or React Native). Depending on your experience it could be easier to extract API keys from an IPA than from JS. In either case the root issue is about sending secrets like an unscoped API key to the client. "Client secret" is an oxymoron in this context regardless of the programming language.
- menckenjr 10y ago
  You'd have to know a few things first, like (1) the IPA is a ZIP file, (2) the ZIP file is actually of a directory and (3) you can dump the actual code in the JS files (if they're in the bundle directory) much easier than you can look for strings from the binary that might look like an API key. The API key is actually the least of the hazards, since you can hide that in the keychain. Having source code for your business logic shipping in your app is not good; having it be hackable business logic (by changing the JS in place) is very not good.
  - jameside 10y ago
    Shipping source code with business logic (assuming the definition of source code includes obfuscated JS) is how the entire web works today! With WASM the code that is shipped will be even further away from the original source code and really not so different from downloading ARM from the App Store or Java/ART bytecode from the Play Store.

trakout 10y ago

I'm having trouble seeing this as a valid argument when applied to cached JavaScript within a mobile browser. The same security practices apply.

menckenjr 10y ago
They do, and it's for this reason that the really important stuff isn't in the web page at all - it's behind the company's API. The "business logic" that you can safely push out to a browser or hybrid app is somewhat limited, which means there is a hard upper limit on the real code sharing savings you can get with hybrid apps versus full native.