Closed Bug 180983 Opened 22 years ago Closed 22 years ago

Mail send cookies while opening TAG elements (LINK/CSS)

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 22994
Milestone:
mozilla1.4beta

People

(Reporter: afucs, Assigned: darin.moz)

References

Details

(Whiteboard: [need info])

Attachments

(1 file)

email message source that can set cookies
1.48 KB, text/plain
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.2b) Gecko/20021016 I was testing some HTML Mail features and I did notice that Mozilla Mail does send Cookies even if Disable cookies in Mail & News is selected: My Mozilla settings are: - Enable cookies for the originating web site only - Disable cookies in Mail & Newsgroups I'm not sure if this bug should be seen as a duplicate bug of any of the following bugs: - 22994 - 63525 - 146122 - 160315 Also note that I'm submiting this bug as a bug because I was not able to reproduce a similar result with Outlook and Outlook Express. Using theses products I was able to open the <LINK HREF> document but not to "see" the cookie stored in Internet Explorer. Reproducible: Always Steps to Reproduce: 1. Visit URL to set the cookie 2. Open email with <LINK> or <IMG> tags. Actual Results: The logfile registered the cookie set on the browser as being sent by the mail & news program. I'm sending the sources of every file involved on this "bug" --start info.php--- <? $notid = "aaaaaa"; setcookie('sgi', $notid, time()+(7700)); ?> bla bla bla --end info.php--- --start mail_source.html--- To: afucs@cfsec.com.br Subject: test MIME-Version: 1.0 Content-type: text/html; charset=iso-8859-1 From: do-not-cross <dnc@cfsec.com.br> <html> <head> <link href=http://10.0.0.1/~afucs/teste/1234 rel="stylesheet" type="text/css"> </head> <body> <p class="padrao">teste com trace no link teste teste teste</p> </body> </html> --end mail_source.html--- --start logfile--- 200.165.217.65 - - [19/Nov/2002:20:30:21 -0200] "GET /~afucs/teste/1234 HTTP/1.1" 302 316 sgi=aaaaaa --end logfile---
To cookies. Darin, any idea what's up here?
Assignee: ben → morse
Status: UNCONFIRMED → NEW
Component: Preferences → Cookies
Ever confirmed: true
QA Contact: sairuh → tever
this happens because there is no documentURI associated with the channel created by the CSS loader. see nsIHttpChannelInternal. cookies depends on the documentURI in order to implement third party cookie blocking as well as cookie blocking from mailnews. if the documentURI is NULL, i think the cookie module defaults to allowing cookies. basically, the documentURI solution is a real hack, and will continuously result in similar problems. we really need a better solution for determining the original document URI (the toplevel URI the user loaded). upping severity to major.
Severity: normal → major
OS: MacOS X → All
Hardware: Macintosh → All
Note that I could try to fix this for CSS by getting the document the CSS is loading for and using its uri. But this would not be the toplevel uri; it would be the uri of the document. So: <iframe src="data:text/html,<link rel='stylesheet' href='something'>"> would still be a problem....
Please ignore reference to the IMG tag on the original post. Seems to be a netscape 4.? exclusivity.
Summary: Mail send cookies while opening TAG elements (LINK/CSS and IMG) → Mail send cookies while opening TAG elements (LINK/CSS)
Hmm.. Images seem to pass along the URI of the document the imageframe's content node is in, which is not what the documentURI is really supposed to be... or is it?
the documentURI should be the imap:// URL (or whatever toplevel mailnews URL) ... sounds like cookie blocking for images in mailnews is also broken then. i mean, it works fine if the image is embedded in the toplevel document, but as soon as it is part of a frame, cookies won't be blocked. we SO need a better way of determining the topmost document URI. perhaps now is time to think about walking the docshell heirarchy instead?!?
That may be the way to go... keep going up till we hit a chrome docshell, then return the one right below that.... I assume the channel creator would be doing the walking, right? Since the channel does not know about docshells? So we could create a helper function that takes something like a document or whatever and returns the documentURI to set on the channel. Then we can fix the callers and improve the helper at our leisure?
what would be even better is if we could completely eliminate the document URI and just use some other information to allow cookies to determine the toplevel docshell (the topmost _active_ docshell that is... link clicks in a frame might mean that the topmost docshell is not the right "first-party" URL). load groups could be this state info, but sadly not all channels get assigned load groups. you see, there's also the problem that not all channels implement nsIHttpChannelInternal (in fact, only HTTP channels implement this interface). as a result, <meta HTTP-EQUIV="set-cookie" CONTENT="..."> is not prevented from setting cookies iirc. so, actually it is possible for SPAM to set and get cookies irrespective of cookie blocking prefs :-)
Severity: major → critical
nevermind the <script> document.cookie = "ZZZZZX=tired"; </script> in the message source. that isn't important since javascript is usually disabled for mailnews. the <meta> tag is what does the magic.
Should this be marked security-sensitive?
It's a privacy issue, not a security one... So in my opinion, no. We should like fix it or something instead.
-> me
Assignee: morse → darin
Target Milestone: --- → mozilla1.3beta
Depends on: 187974
-> 1.4
Status: NEW → ASSIGNED
Target Milestone: mozilla1.3beta → mozilla1.4alpha
Could a note be added to the release notes? This is a fairly big privacy gap in the Mail/News, imho. :)
This sounds like a real testing problem. I like the sound of #8, especially if the calling module would just say who it is (chat, im, mail, whatever) explicitly. So, is it possible that there are other cookie holes in MailNews blocking? MailNewsQA probably needs to find some way of running a set of cookie validation tests that use most layout entrypoints.
Flags: blocking1.4a?
Keywords: nsbeta1
QA Contact: tever → cookieqa
punting to next milestone. going to require some architectural changes to get it right.
Severity: critical → major
Flags: blocking1.4a?
Target Milestone: mozilla1.4alpha → mozilla1.4beta
adt: darin, is this a regression from Netscape 7.0?
Whiteboard: [need info]
cavin might own a related bug, or a dup.
Flags: blocking1.4b? → blocking1.4b+
samir: we've always had this bug.
blocking1.4b+ on bug 22994 which darin says this is a dupe of.
Flags: blocking1.4b+
marking as duplicate *** This bug has been marked as a duplicate of 22994 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: