Security/Reviews/B2GBrowser
From MozillaWiki
Please use "Edit with form" above to edit this page.
Item Reviewed
B2G Browser | |||||||||||||||||
Target |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); Background links:
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%); |
The given value "
ID | Summary | Priority | Status |
---|---|---|---|
754733 | [Security Review] B2G Gaia - Browser | P1 | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
Background links:
ID | Summary | Priority | Status |
---|---|---|---|
693515 | Browser API | P2 | RESOLVED |
1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);
- https://wiki.mozilla.org/Gaia/Browser" contains strip markers and therefore it cannot be parsed sufficiently.
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- Provide support so that a Browser can be implemented as a Web App
- Implemented as new type of iframe which provides limited cross-origin access so that a page embedding this iframe can act like a web browser.
- Being implemented with a minimal set of APIs to provide the intial browser
- No addons or plugins at the moment, no future plans.
- History:
- Session history, handled inside the app now - will be handled by API
- Global history, handled inside the app using indexdb
- not sure how to do link coloring
- New features to be aware of
- bubble the page up key up event to the browser
- getDimension
- Security change event "http/https state"
What solutions/approaches were considered other than the proposed solution?
`
Why was this solution chosen?
`
Any security threats already considered in the design and why?
Any security threats already considered in the design and why?
- Yes, see below.
Threat Brainstorming
- Threat vectors
- Untrusted content escaping the <iframe mozbrowser> element
- Javascript references to items not inside the iframe
- Process boundary is very strong here, can't reference things in different processes.
- Attacking local web apps through shared resources (are there any?)
- Causing the parent frame to navigate
- process boundary
- Obtaining the permissions of the parent frame, ie being able to act like a browser
- we haven't done this, but either (1) the parent will
- Impact is minimal is API is kept limited - not sure if this will be possible -- it's not if you want a decent browser.
- Javascript references to items not inside the iframe
- Normal Browser Security controls weakened or not present
- revisit when more complete
- URL Bar behavior? (need to expose SSL information)
- the API will expose whether the site is secure, but displaying it is up to the browser app.
- Frame related issues
- Must handle frame-busting code correctly bug 754997
- Modal dialogs in the browser frame must not block parent page bug 741587
- Untrusted web page content not segregated sufficiently from Web Apps
- Shared resources between untrusted content (i.e. page loaded in the mozbrowser) and the installed apps. Cookies?
- all of an app's top-level mozbrowser instances will get a separate cookie jar. [Currently it has one right? I assumed mulitple is for tabs? cookie jar per tab.. that seems wrong]
- Other Origin based resource access (local storage, Indexed DB) -- and separate indexed db, etc.
- DoS attacks against the phone (mitigated by seperate process, but what about spamming functions which result in IPDL messages back to the B2G process? Especially for messages that result in costly functions) -- I don't think multiple processes actually fixes this. A process can still DoS a device. Same for any app.
- Permissions (what prevents a page loaded at sms.gaiamobile.org from getting SMS permissions?) -- this is a general problem -- an app could load that origin, too!
- Shared resources between untrusted content (i.e. page loaded in the mozbrowser) and the installed apps. Cookies?
- Untrusted page might gain access to create an <iframe mozbrowser> -- if our permissions are broken our permissions are broken.
- Access to the local device (this is probably a b2g wide question)
- file:// etc
- loopback address/network address?
- Property "SecReview feature goal" (as page type) with input value "* Provide support so that a Browser can be implemented as a Web App
- Implemented as new type of iframe which provides limited cross-origin access so that a page embedding this iframe can act like a web browser.
- Being implemented with a minimal set of APIs to provide the intial browser
- No addons or plugins at the moment, no future plans.
- History:
- Session history, handled inside the app now - will be handled by API
- Global history, handled inside the app using indexdb
- not sure how to do link coloring
- New features to be aware of
- bubble the page up key up event to the browser
- getDimension
- Security change event "http/https state"" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview threats considered" (as page type) with input value "== Any security threats already considered in the design and why?==
- Yes, see below." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
- Property "SecReview threat brainstorming" (as page type) with input value "; Threat vectors:
- Untrusted content escaping the element
- Javascript references to items not inside the iframe
- Process boundary is very strong here, can't reference things in different processes.
- Attacking local web apps through shared resources (are there any?)
- Causing the parent frame to navigate
- process boundary
- Obtaining the permissions of the parent frame, ie being able to act like a browser
- we haven't done this, but either (1) the parent will
- Impact is minimal is API is kept limited - not sure if this will be possible -- it's not if you want a decent browser.
- Javascript references to items not inside the iframe
- Normal Browser Security controls weakened or not present
- revisit when more complete
- URL Bar behavior? (need to expose SSL information)
- the API will expose whether the site is secure, but displaying it is up to the browser app.
- Frame related issues
- Must handle frame-busting code correctly bug 754997
- Modal dialogs in the browser frame must not block parent page bug 741587
- Untrusted web page content not segregated sufficiently from Web Apps
- Shared resources between untrusted content (i.e. page loaded in the mozbrowser) and the installed apps. Cookies?
- all of an app's top-level mozbrowser instances will get a separate cookie jar. [Currently it has one right? I assumed mulitple is for tabs? cookie jar per tab.. that seems wrong]
- Other Origin based resource access (local storage, Indexed DB) -- and separate indexed db, etc.
- DoS attacks against the phone (mitigated by seperate process, but what about spamming functions which result in IPDL messages back to the B2G process? Especially for messages that result in costly functions) -- I don't think multiple processes actually fixes this. A process can still DoS a device. Same for any app.
- Permissions (what prevents a page loaded at sms.gaiamobile.org from getting SMS permissions?) -- this is a general problem -- an app could load that origin, too!
- Shared resources between untrusted content (i.e. page loaded in the mozbrowser) and the installed apps. Cookies?
- Untrusted page might gain access to create an -- if our permissions are broken our permissions are broken.
- Access to the local device (this is probably a b2g wide question)
- file:// etc
- loopback address/network address?" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
Action Item Status | In Progress |
Release Target | ` |
Action Items | |
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)
|