Steps: 1. Install a web application 2. Find the webapp.json file for that application a. Windows - It's in the origin directory under %APPDATA% b. Mac - /Library/Application Support/<origin> 3. Alter the webapp.json's origin to point to a different origin that you want the app to start on 4. Launch the application Expected: Not sure exactly what the correct behavior is, but I don't think I should be able to tamper the origin of the installed app. Actual: Wherever the origin is set is where the app's origin starts on when the app launches. Additional Notes: This has already shown that this "hack" allows you to get to about:support and about:crashes. Is there any risk allowing this hole open?
Note - Also allows access to about:addons - which does allow you to enable and disable plugins. Sounds like menu escalation for the web runtime!
(In reply to Jason Smith [:jsmith] from comment #0) > Not sure exactly what the correct behavior is, but I don't think I should be > able to tamper the origin of the installed app. We can make it harder, but it's hard to make it impossible. Desktop OSes and their apps tend to put configuration information into text files, and users can do all kinds of damage to their OS and apps by modifying them. For which the mitigation strategy is to put such files into hidden folders (as is this one). Note that one can also change Firefox's "origin" (i.e. its default chrome URL) in a similar fashion (by setting a preference in the user's prefs.js file). The only difference is that webapp.json is in a known location, while prefs.js is inside a directory with a salted name. cc:ing dveditz in case he thinks this matters.
Dveditz - Is there any security risks with leaving this open? Or does it come with the fact that if you decided to mess with your own configuration, it's on your own fault for what may happen?
Note - This does allow menu escalation with the web runtime to gain access to menus you would normally not have access to (e.g. about:addons).
I can also get access to all of the preferences in firefox via in-content preferences - about:preferences.
I don't know what "menu escalation" is, but you can also get access to addons and preferences from the profile directory, which is alongside webapp.json in the app's data directory. If you have access to the app's data directory, then you already have full access to the app's profile directory, so there's nothing you can do to get more access to it.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #6) > I don't know what "menu escalation" is, but you can also get access to > addons and preferences from the profile directory, which is alongside > webapp.json in the app's data directory. > > If you have access to the app's data directory, then you already have full > access to the app's profile directory, so there's nothing you can do to get > more access to it. Menu escalation (bad wording on my part) - Access to menus and operations in the web runtime that you normally don't have access to. But yeah, that is true that if the user had the access to the profile directory in the first place, they could what they want to alter the web runtime (such as getting about:preferences to come up). My discussion with Dan concluded that this may fall in line with - if a user decided to go through the effort to screw up their machine, then it's their fault. %APPDATA% also on windows isn't really end-user focused (likely a typical average user wouldn't check this directory). Now, if leaving this open causes effects to other things outside of the user's machine that the user caused, then there may be a problem, but that's not known right now. But it might be worth assessing the risk (at least have someone from security comment here to understand any implications of leaving this open).