Security/Features/Intranet CSRF Blocker
|Intranet CSRF Blocker|
|Product manager||Sid Stamm|
|Directly Responsible Individual||`|
|Lead engineer||Steve Workman|
|Product marketing lead||`|
|Additional members||Brian Smith|
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"
See related bug 354493. Dependencies:
|584155||Add a scriptable SOCKS proxy server to allow testing of SOCKS client code||NEW|
|585191||Enable SOCKS proxy server in mochitests||NEW|
|255107||Prevent data: URLs from being used for XSS||NEW|
= $all-$resolved ?> Open; = $resolved ?> Resolved; = $all ?> Total (0% complete)
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
Quality Assurance review
Stage 4: Development
Stage 5: Release
10. Landing criteria
|Theme / Goal||Product Hardening|
Team status notes