Closed Bug 1519633 Opened 4 years ago Closed 3 years ago

exposed local server information and local ips


(Core :: Security, defect)

Not set





(Reporter: forwarding4, Unassigned)



(1 file)

Attached image demo_output.png

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Visit this demonstration
or this http-link without Mixed Content

Test case:

  • local router favicon
  • FRITZ!Box image
  • XAMPP default favicon (windows)
  • Default SABnzbd installation favicon
  • Default NZBGet installation favicon

With more test cases it is possible to fingerprint the visitor based on running software, by loading local resources.

This works in Firefox, Chrome, ...

Actual results:

Output in my test case is:

Your router is available via
Your router is : FRITZ!Box
Your are running XAMPP with default configuration
NZBGet is running on port 6789.
NZBGet is running on port 6789.

Screenshot of my demo output is attached.

Expected results:

Resources should habe been blocked by default

Not sure what is your point here? is a private ip address, most of the time won't exist.
Could you explain more what is your point? Thanks

Flags: needinfo?(forwarding4)

(In reply to Sylvestre Ledru [:sylvestre] from comment #1)

Not sure what is your point here? is a private ip address, most of the time won't exist.
Could you explain more what is your point? Thanks

This can be used for browser fingerprinting (just an example).
Building and testing an exhaustive list exposes software used on the client system and network.
The motivation why a website may wants to know which software a user is currently using or connected to depends on the application and goal of the website.

It is not limited to That was just an example.

Flags: needinfo?(forwarding4)

Sure, there are a lot of ways to do fingerprinting.
However, I am not sure to see how your bug is actionable ?!

This would be actionable if you disallow linking to private address ranges (10/8,172.16/12,192.168/16) like it's already done with file:// urls on the protocol level.
I'm sure that this would create problems at larger organizations.

Component: Untriaged → Security
Product: Firefox → Core

Steven, could you help triage this bug? Thanks!

Flags: needinfo?(senglehardt)

Thank you for the report! This is a known issue discussed in Bug 959893. I think we can resolve this as a duplicate of that bug since there doesn't appear to be any new information here.

Tom, does that sound right?

Flags: needinfo?(senglehardt) → needinfo?(tom)

This isn't actually about the WebRTC local IP thing, this is about looking for specific resources on RFC 1918 IP addresses and using it to learn about the private machine/network. There is a draft spec to do something about that, but I don't think there's been much movement on it. But you are correct it is a dupe/example of why that work is valuable.

Closed: 3 years ago
Flags: needinfo?(tom)
Resolution: --- → DUPLICATE

I am aware of Bug 959893.
This Bug is not a technical dupe, since it is unrelated to WebRTC.
If you inspect the source code you can see that no WebRTC-code is used.

In terms of privacy there should be a browser setting, so that the browser user can choose to block this kind of leakage at will,
instead of using custom block workarounds.

You need to log in before you can comment on or make changes to this bug.