Sounds like we should close of port 631. Past that, this is a duplicate of various bugs we already have on file. > and clear them without restarting the whole browser. With the Mozilla application suite, you can: Tools > Password Manager > Log Out. This will log out all HTTP authentication sessions.
Webpages don't normally need to include local resources. If one does, the user should be asked for confirmation.
"local"? that's just another HTTP server...
(In reply to comment #3) > "local"? that's just another HTTP server... Bah, you know that's not what the user thinks should happen. Companies set up elaborate firewalls to prevent connections to internal servers, only to see browsers poke a big hole in it by allowing any externally-loaded page to reference any internal URL. Sure, the same-origin policy prevents the external page from gathering any data this way, but any internal server that accepts commands via GET (plenty of them in spite of HTTP specs that warn against it) is vulnerable. Obviously the attacker would need to know about the internal servers (or guess at common local services as in this case) but a "disgruntled ex-employee" would have that kind of knowledge. Prior to Thunderbird's blocking of remote connections, evil mail to former colleagues is all it would have taken; I believe Mozilla Suite mail is still vulnerable by default. There are no blocks in the browser.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This was covered on Slashdot last December: http://it.slashdot.org/article.pl?sid=02/12/20/0140249&tid=172 ...and is IMHO a CUPS bug, not a Firefox bug. CUPS should be doing Referer checking; this is a CGI Security 101. Just ask any Web-based game designer. There's not much we can do about it, since the CUPS CGI configuration could be on a server other than localhost (e.g. configuring across the network), or on a different port. And it applies to any CGI script, not just CUPS.
Removing confidential flag as reporters request
(In reply to comment #5) > This was covered on Slashdot last December: > http://it.slashdot.org/article.pl?sid=02/12/20/0140249&tid=172 > ...and is IMHO a CUPS bug, not a Firefox bug. CUPS should be doing Referer > checking; this is a CGI Security 101. Just ask any Web-based game designer. CUPS should be using POST, not GET, to modify the state of resources.
You can do POST with an HTML form which has a submit() method. No need for XMLHttpRequest, and no same-origin check.
(In reply to comment #10) > You can do POST with an HTML form which has a submit() method. No need for > XMLHttpRequest, and no same-origin check. In-ter-esting. In HTTP, unsafe methods should require user interaction; this isn't a hard-and-fast requirement (unfortunately), but the principle is there (e.g., cautions against automatic redirection in section 10.3). Do you have a demonstration of this (e.g., site A content automatically POSTing to site B without user interaction), and have you filed a bug against it? Cheers,
data:text/html,<body onload="document.forms.submit()"><form action="POST" action="whatever">... This is widely used on the web and supported by all browsers. I also think it's perfectly acceptable behavior, but I do believe there's a bug about having this situation warn the user. Feel free to search for it. That's not related to this bug, however.
Daniel & Boris, Do we still have this problem? We use the same printing backend as Firefox and I think there is the printing code has undergone some rewrites since this bug was opened.
Assignee: general → nobody
Component: General → Printing: Output
Product: SeaMonkey → Core
QA Contact: general → printing
This has nothing to do with our print subsystem. Please read the bug. This should _maybe_ depend on the "don't allow access to internal IPs" bug, but even that might not help if localhost is not an internal IP... of course in that case anyone on the web could reconfigure your printers.
Component: Printing: Output → General
QA Contact: printing → general
Summary: websites can steal your printer output (etc) → websites can steal your printer output (etc) by exploiting the wide-open web server CUPS sets up on localhost which allows GET requests to reconfigure CUPS
And again, should we add port 631 to the blacklist? That seems to be commonly used for IPP, so arguably we should.... Daniel?
Component: General → Networking
QA Contact: general → networking
Whiteboard: DUPME? → DUPEME?
we've gone this far allowing 631 and I think have shown this is no worse than the general problems with remote content accessing local services.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.