Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Is Javascript on a mobile browser more secure than Javascript on other types of systems? For instance, if I have a site that includes some client-side (Javascript) encryption code, with the intention that it only runs inside a Safari browser on the iPhone (standalone or embedded in an app) or Chrome on an Android device, what are some possible vulnerabilities? Is client-side Javascript encryption as terrible an idea in the mobile space as the desktop space?

Caveats:

  • Making an app isn't an option. This question is specifically about the security of the mobile browser environment. I do realize that the built-in APIs would be a far better idea.
  • Assume that the server hosting the code remains secure, or that the person is running the code locally/offline.

Here's what I've thought of so far:

  • Hijacking of the actual transmission (solvable via HTTPS, except MITM)
  • Same-origin (solvable via hosting on a dedicated subdomain)

All other attacks (e.g. exploiting a flaw in the iPhone browser) would seem to involve one of these two. Given the general negative attitude toward Javascript-based encryption, I must be missing something. What am I missing?

share|improve this question
    
Any Javascript code that can run in those mobile browsers would ran in a desktop browser and generate the exact same results. That is the wonder of javascript. Many of the exploits used to jailbreak iOS have used Javascript. Android doesn't need an exploit beause you can install any android package you want on it. –  Ramhound Apr 30 '13 at 17:03
    
I'm not sure if it helps, but if you mean the abscence of a view source, you can debug a webpage in the Mobile Safari with the 'remote' option of the inspector. –  11684 Apr 30 '13 at 18:51

1 Answer 1

A jailbroken iPhone or "rooted" Android device is not qualitatively distinguishable from a desktop system. From the server side, you cannot know whether the device is rooted or not; or even if it really is the device you believe it is to be. Whatever issues Javascript-based crypto can have on "desktop" systems also apply to mobile platforms. Of course, any individual browser (not platform) can have more or less troublesome features in that respect, but browsers are actually fairly uniform across platforms (Safari on iOS shares a lot of code with Safari on MacOS X or Windows, for instance).

This does not mean that Javascript cryptography is inherently doomed; only that you have to work within the constraints of that language and its environment (the browser), which are somewhat adverse to tasks for which cryptography is deemed necessary. In particular:

  • Javascript code runs on the client, and cannot be protected from the prying eyes of the user, if he is intent on reverse-engineering it (code obfuscation can only get you so far, i.e. not very far). If you embed secrets in the Javascript code, your only actual protection is prayer.

  • Javascript has very little access to the platform facilities, in particular storage space.

  • Since Javascript code is not stored locally (it can be cached but caching duration cannot be reliably enforced from the server), it must be redistributed anew from the server. Since unprotected data sent over the Internet can get altered, this distribution must go through some HTTPS, and inherently trusts the server for not playing foul games. Presence of HTTPS and trust in the server remove most reasons why cryptography should be done on the client side.

    (If you don't trust the server, then you cannot logically use Javascript code sent by that server. The problem of trusting the server is real -- but Javascript is not the solution for it.)

  • For bulk computational tasks (e.g. cryptographie), Javascript performance sucks big time.

There is nothing in mobile devices that would significantly modify these constraints, as compared to the situation on desktop systems.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.