Security/Features/Intranet CSRF Blocker
Status
| Intranet CSRF Blocker | |
| Stage | On hold |
| Status | In progress |
| Release target | ` |
| Health | ` |
| Status note | ` |
Team
| Product manager | Sid Stamm |
| Directly Responsible Individual | ` |
| Lead engineer | Steve Workman |
| Security lead | ` |
| Privacy lead | ` |
| Localization lead | ` |
| Accessibility lead | ` |
| QA lead | ` |
| UX lead | ` |
| Product marketing lead | ` |
| Operations lead | ` |
| Additional members | Brian Smith |
Open issues/risks
`
Stage 1: Definition
1. Feature overview
Intranet CSRF Blocker enables Firefox to be aware of the source of network loads for sub-document resources, such as images, iframes, XHR, etc., and to use this extra context to decide if the network load should be permitted. The goal of this feature is to prevent web pages on the public Internet from causing a user's browser to send requests to resources residing on a private network.
2. Users & use cases
RFC 1918 defines the set of CIDR blocks which are not publicly addressable from the Internet and which are generally used to address hosts found on private home or enterprise networks. Included in this range are: 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8.
Starting around 2006, security researchers, notably Jeremiah Grossman and Robert Hansen, began pointing out an architectural weakness in the Web that allowed (untrusted) websites on the public Internet to cause requests to be sent to hosts on these private networks, which would otherwise be protected by NAT. Malicious requests of this type can be used by an attacker for: port scanning internal networks, reconfiguring home routers, sending print jobs to network printers, and CSRF to applications that use network access as authentication.
For more background, see:
- "Hacking Intranet Websites from the Outside"
- "Hacking Intranet Websites from the Outside (Take 2)"
- "Drive-By Pharming"
- "Cross site printing"
3. Dependencies
See related bug 354493. Dependencies:
8 Total; 1 Open (12.5%); 7 Resolved (87.5%); 0 Verified (0%);
4. Requirements
`
Non-goals
The reverse case, where a web page on a private network sends requests for non-private resources, is common and is not considered an attack case that we are trying to prevent.
Stage 2: Design
5. Functional specification
`
6. User experience design
`
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
`
8 Total; 1 Open (12.5%); 7 Resolved (87.5%); 0 Verified (0%);
" contains strip markers and therefore it cannot be parsed sufficiently.Feature details
| Priority | P2 |
| Rank | 999 |
| Theme / Goal | Product Hardening |
| Roadmap | Security |
| Secondary roadmap | ` |
| Feature list | ` |
| Project | ` |
| Engineering team | Networking |
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
