Closed Bug 180983 Opened 22 years ago Closed 21 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: 21 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: