Security/ProcessIsolation/ThreatModel: Difference between revisions
(Created page with '= High Level Threat Model for Process Isolation = We need to be able to clearly understand and communicate the benefits and limitations of process isolation to users, the press ...') |
|||
Line 5: | Line 5: | ||
= Major Threat Categories = | = Major Threat Categories = | ||
In order to | In order to avoid getting bogged down by enumerating potential benefits and risks on a per-API basis, we will organize threats around broad categories, then use a few representative APIs as litmus tests of some of the implementation implications. | ||
== System Compromise == | == System Compromise == | ||
Line 14: | Line 14: | ||
Ability to steal data from the local or network filesystem. A subset of the System Compromise category. | Ability to steal data from the local or network filesystem. A subset of the System Compromise category. | ||
== Cross-domain Compromise == | |||
Code originating from one FQDN can execute code (native or JavaScript) in the context of another FQDN domain without permission. This includes code from HTTP://a.com being able to execute code within HTTPS://a.com | |||
== Cross-domain Data Theft == | |||
Code originating from one FQDN can read data from another FQDN without permission. | |||
Types of assets at risk: | |||
* HTML | |||
* JavaScript | |||
* CSS? | |||
* images | |||
* audio/video | |||
== Session ID theft or fixation == | == Session ID theft or fixation == | ||
An attacker could read or set session information | An attacker could read or set session information. | ||
Types of information at risk: | |||
* cookies | |||
* local data store | |||
* URL arguments | |||
== User interface compromise == | == User interface compromise == | ||
The user interface could be compromised to trick the user into making an incorrect trust decision or directly disclose credentials or other sensitive information | The user interface could be compromised to trick the user into making an incorrect trust decision or directly disclose credentials or other sensitive information | ||
= Attack Vectors = | |||
Another major consideration is how the attack itself could be be delivered. In the browser, almost every component or API should be considered part of the attack surface. But for particular types of attacks (such as cross-domain attacks) its worth enumerating a set of specific assets that should be considered when evaluating the implications of cross-domain security threats, for example. | |||
Attack vectors can be thought of in two ways: | |||
* to enumerate what things could be used to attack the browser in the first place | |||
* once compromised, what assets does a process have access to for launching further attacks | |||
A very partial list of assets that could be considered attack vectors... please expand upon! | |||
* HTML | |||
* Stylesheets | |||
* .js | |||
* Images | |||
* Audio/video | |||
* Plugins | |||
* HTTP requests and responses (headers, body) | |||
* Cookies | |||
* |
Revision as of 22:27, 7 April 2009
High Level Threat Model for Process Isolation
We need to be able to clearly understand and communicate the benefits and limitations of process isolation to users, the press and security researchers. In order to do so we need to identify which threats process could actually mitigate, and then consider the implementation implications of doing so.
Major Threat Categories
In order to avoid getting bogged down by enumerating potential benefits and risks on a per-API basis, we will organize threats around broad categories, then use a few representative APIs as litmus tests of some of the implementation implications.
System Compromise
Compromise the underlying system and achieve malicious code execution with full user privileges.
System Data Theft
Ability to steal data from the local or network filesystem. A subset of the System Compromise category.
Cross-domain Compromise
Code originating from one FQDN can execute code (native or JavaScript) in the context of another FQDN domain without permission. This includes code from HTTP://a.com being able to execute code within HTTPS://a.com
Cross-domain Data Theft
Code originating from one FQDN can read data from another FQDN without permission.
Types of assets at risk:
- HTML
- JavaScript
- CSS?
- images
- audio/video
Session ID theft or fixation
An attacker could read or set session information. Types of information at risk:
- cookies
- local data store
- URL arguments
User interface compromise
The user interface could be compromised to trick the user into making an incorrect trust decision or directly disclose credentials or other sensitive information
Attack Vectors
Another major consideration is how the attack itself could be be delivered. In the browser, almost every component or API should be considered part of the attack surface. But for particular types of attacks (such as cross-domain attacks) its worth enumerating a set of specific assets that should be considered when evaluating the implications of cross-domain security threats, for example.
Attack vectors can be thought of in two ways:
- to enumerate what things could be used to attack the browser in the first place
- once compromised, what assets does a process have access to for launching further attacks
A very partial list of assets that could be considered attack vectors... please expand upon!
- HTML
- Stylesheets
- .js
- Images
- Audio/video
- Plugins
- HTTP requests and responses (headers, body)
- Cookies