Security/CSP/Confidentiality
Status
| Confidentiality Directive (CSP) | |
| Stage | Shelved |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | ` |
{{#set:Feature name=Confidentiality Directive (CSP)
|Feature stage=Shelved |Feature status=` |Feature version=` |Feature health=OK |Feature status note=` }}
Team
| Product manager | Sid Stamm |
| Directly Responsible Individual | Devdatta Akhawe |
| Lead engineer | Devdatta Akhawe |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | ` |
{{#set:Feature product manager=Sid Stamm
|Feature feature manager=Devdatta Akhawe |Feature lead engineer=Devdatta Akhawe |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature additional members=` }}
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Data confinement is a fundamental security primitive unavailable on the web platform today. Applications handling sensitive data currently do not have any mitigation against data exfiltration attacks. The adoption of CSP and primitives like sandbox promise a world with robust defenses against code injection attacks; but no guarantees against data exfiltration attacks.
2. Users & use cases
From http://lcamtuf.coredump.cx/postxss/
"One of the most rudimentary goals of a successful XSS attack is the extraction of user-specific secrets from the vulnerable application. Historically, XSS exploits sought to obtain HTTP cookies associated with the authenticated user session; these tokens - a form of ambient authority - could be later replayed by the attacker to remotely impersonate the victim within the targeted site. The introduction of httponly cookies greatly limited this possibility - and prompted rogue parties to pursue finer-grained approaches."
This would, in particular, be really useful in scenarios where sensitive tokens are present in the document. A successful HTML injection can possibly exfiltrate these tokens. For example, exfiltration of a BrowserID URL to login compromises correctness, exfiltration of a unique identifier of the user compromises privacy and so on.
Another important use case is data vaults: Google Docs, Password Managers (e.g., LastPass), phpMyAdmin are all examples of web applications that handle sensitive data, where content exfiltration attacks might be dangerous. An injection vulnerability in Google Docs can exfiltrate sensitive docs; a injection vulnerability in phpMyAdmin can allow exfiltrate SQL databases; and exfiltration of data from password managers would be really bad.
3. Dependencies
`
4. Requirements
Even if an attacker achieves code injection, she should not be able to exfiltrate any data to an origin other than the ones in the whiltelist, save for the non-goals listed below.
Non-goals
Side Channels
Confidentiality invariants more fine-grained than origins. Thus, a website having an open redirect doesn't get much protection from this: they need to modify the open redirect to make whitelist/scrub the redirect of any data. While we might be able to block HTTP redirect cases, meta/javascript redirects will be difficult.
Stage 2: Design
5. Functional specification
We propose addition of a CSP directive 'confidentiality' which has a whitelist of origins to which a frame is allowed to leak data.
In the presence of such a directive, basic protections that are turned on are: all cross-origin JavaScript object access are disabled except for PostMessage (and, in the future, other HTML5 cross-origin messaging channels). All PostMessages delivered would be checked against the origin whitelist.
All network requests caused by the document will be interposed on, and would be allowed through only if the target URI is in the whitelist of origins.
The current plan is to disable all data: URI iframe/worker loads as soon as a confidentiality primitive is present.
One concern is to take care of all possible corner cases. For example, the document might modify window.history and the user's clicking back might leak data.
6. User experience design
n.a.
Stage 3: Planning
7. Implementation plan
`
8. Reviews
Security review
`
Privacy review
`
Localization review
`
Accessibility
`
Quality Assurance review
`
Operations review
`
Stage 4: Development
9. Implementation
`
Stage 5: Release
10. Landing criteria
` {{#set:Feature open issues and risks=` |Feature overview=Data confinement is a fundamental security primitive unavailable on the web platform today. Applications handling sensitive data currently do not have any mitigation against data exfiltration attacks. The adoption of CSP and primitives like sandbox promise a world with robust defenses against code injection attacks; but no guarantees against data exfiltration attacks. |Feature users and use cases=From http://lcamtuf.coredump.cx/postxss/
"One of the most rudimentary goals of a successful XSS attack is the extraction of user-specific secrets from the vulnerable application. Historically, XSS exploits sought to obtain HTTP cookies associated with the authenticated user session; these tokens - a form of ambient authority - could be later replayed by the attacker to remotely impersonate the victim within the targeted site. The introduction of httponly cookies greatly limited this possibility - and prompted rogue parties to pursue finer-grained approaches."
This would, in particular, be really useful in scenarios where sensitive tokens are present in the document. A successful HTML injection can possibly exfiltrate these tokens. For example, exfiltration of a BrowserID URL to login compromises correctness, exfiltration of a unique identifier of the user compromises privacy and so on.
Another important use case is data vaults: Google Docs, Password Managers (e.g., LastPass), phpMyAdmin are all examples of web applications that handle sensitive data, where content exfiltration attacks might be dangerous. An injection vulnerability in Google Docs can exfiltrate sensitive docs; a injection vulnerability in phpMyAdmin can allow exfiltrate SQL databases; and exfiltration of data from password managers would be really bad. |Feature dependencies=` |Feature requirements=Even if an attacker achieves code injection, she should not be able to exfiltrate any data to an origin other than the ones in the whiltelist, save for the non-goals listed below. |Feature non-goals=Side Channels
Confidentiality invariants more fine-grained than origins. Thus, a website having an open redirect doesn't get much protection from this: they need to modify the open redirect to make whitelist/scrub the redirect of any data. While we might be able to block HTTP redirect cases, meta/javascript redirects will be difficult.
|Feature functional spec=We propose addition of a CSP directive 'confidentiality' which has a whitelist of origins to which a frame is allowed to leak data.
In the presence of such a directive, basic protections that are turned on are: all cross-origin JavaScript object access are disabled except for PostMessage (and, in the future, other HTML5 cross-origin messaging channels). All PostMessages delivered would be checked against the origin whitelist.
All network requests caused by the document will be interposed on, and would be allowed through only if the target URI is in the whitelist of origins.
The current plan is to disable all data: URI iframe/worker loads as soon as a confidentiality primitive is present.
One concern is to take care of all possible corner cases. For example, the document might modify window.history and the user's clicking back might leak data. |Feature ux design=n.a. |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=` |Feature landing criteria=` }}
Feature details
| Priority | Unprioritized |
| Rank | 999 |
| Theme / Goal | Experience / Connect |
| Roadmap | Security |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | ` |
{{#set:Feature priority=Unprioritized
|Feature rank=999 |Feature theme=Experience / Connect |Feature roadmap=Security |Feature secondary roadmap=` |Feature list=` |Feature project=` |Feature engineering team=` }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}