Hello,
So I've run across a possible security hole and want to get some input. I've noticed that it is possible to alter the html pages and rhoconfig.txt file in a Javascript application in a deployed application. The problem that this creates is that even though we could lock down a directory so that a user cannot alter the files they could potentially create a new app with our data models and gain access to the information that should be encrypted.
Without knowing exactly how the encryption works maybe I didn't test this theory in the best way and if so hopefully someone can assure us this case can't happen. Here is what I did. I ran our app on my development PC and downloaded a bunch of customer info to our application. I then tried to open the files and received a message saying that the db file was not a sqlite 3 file format and it couldn't be opened. Great that's what we expect. However, I built an older version of our application that is sitting as an entirely different project and installed it on a remote device. I then copied the db containing customer info on to said device and tried opening up the application. Sure enough I was able to see all the customer info but still couldn't open the sqlite file through the file system. The only thing that might be questionable is that the old application is very close to our current one but I figured that they were both built from separate projects so that should suffice. Should this be possible?
edit: I decided to just be sure that if I created another application with just the data models that I would produce the same results and I have.
Thanks
Chris
2 Replies
What platform?
Why is the user able to access the DB file at all?
I'll admit I'm most familiar with iOS. Distributed apps and their sandboxes are encrypted if you enable it in the provisioning profile. Users won't be able to get at the files. Development build is different and then, yes, you can. (I do this often during development, both from a real device and from iOS simulators with a bit of help from SimPholders. It is very handy to open the database file with a desktop tool! I use DB Browser for SQLite...)
Another vulnerability on most platforms is the IP port used by the server, but this can be plugged at least on iOS. (Would love to see the solution applied now to other platforms!) During test, most set it to fixed 8080, and then in production let it pick a random port. This is scant protection! The port is easily found, and then a desktop browser can be used to connect from a desktop browser. (Note that remote debugging should be disabled in production, and so it's not QUITE as severe as it might be!)
So, a user with some knowledge of the URL structure would be able to load pages in a desktop browser (or e.g. cUrl command-line), examine them, examine Javascript, execute arbitrary Javascript, send arbitrary requests to the server, etc. etc. etc.
On iOS, in rhoconfig.txt I use this. It doesn't expose a port at all. This option currently not available for other platforms.
# If true, an old libCURL-based Net request will be used.# This option can be enabled for regression testing or if custom proxy support is required.# Default is TRUE but, to support per-app VPN (ex. MobileIron) this option should be set to FALSE.# It is useful to set this to false in some cases for debugging, because cUrl is more chatty# in the log than the new Network code.ios_net_curl = 0# If true, request to local server will be applied directly, bypassing socket intercommunication,# no network requests are involved. If false, a legacy client-server intercommunication will be made# for local requests. Default is FALSE but, to support per-app VPN (ex. MobileIron) this option# should be set to TRUE.## Note: you will not be able to test pages by pointing a desktop browser to port 8080 if this# is set to true. I can't remember when I last did that, since we have Web Inspector.ios_direct_local_requests = 1
Note that these particular settings MUST be 1 or 0 - true/false or "true"/"false" will NOT work correctly!
No I dont think the objective of encryption is to prevent anyone from copying the db files to another app or PC. In fact, you cannot prevent copying any files from your app elsewhere, especially on a rooted device.
However, if you are to give me your encrypted db files, without knowing the structure of it, I'd not be able to do anything to or with it.