Open Bug 245361 Opened 16 years ago Updated 2 years ago

improve nsMsgContentPolicy.cpp to be more airtight

Categories

(MailNews Core :: Security, defect)

x86
Windows XP
defect
Not set

Tracking

(blocking-thunderbird3.1 -)

Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: sspitzer, Unassigned)

References

Details

Attachments

(1 file)

improve nsMsgContentPolicy.cpp to be more airtight

While we need to plug all the image holes (make sure all image loads will first
check our ::ShouldLoad()), we also need to make sure all other remote loads
(like style sheets, for example) also call our ::ShouldLoad().

Our nsMsgContentPolicy.cpp (and probably the one in browser) needs to be made
more air tight.

I think I logged a bug about this, but a clever spammer could do this to us:

<img
src="news://news.mozilla.org:119/c9j55m%24pi36%40ripley.netscape.com?part=1.1.2">
right now we block ftp, http and https images, but might be other protocols (in
addition to nntp / news / snews) that could slip through.
Compare bug 55237 and esp. bug 120373.
also see (The patch in) bug 240070. We could just share this code between
seamonkey and thunderbird :)
Blocks: 216133
Also... it is claimed by gurus of AdBlock that implementation of this extension
for Thunderbird is blocked by this bug.

See: http://aasted.org/adblock/viewtopic.php?t=669#3816
RSS reading without Adblock is realy annoying. I think this bug should be
corrected in Thunderbird 1.0 !!!
upsy-daisy. s/realy/really/g
(In reply to comment #5)
> RSS reading without Adblock is realy annoying. I think this bug should be
> corrected in Thunderbird 1.0 !!!

Yes, it is!  ... but, unfortunately, we missed that target

I would like to be able to vote for this bug, so I hope someone picks it up soon.
(In reply to comment #7)
> (In reply to comment #5)
> > RSS reading without Adblock is realy annoying. I think this bug should be
> > corrected in Thunderbird 1.0 !!!
> 
> Yes, it is!  ... but, unfortunately, we missed that target
> 
> I would like to be able to vote for this bug, so I hope someone picks it up soon.

Here here!  I really would like to be able to block all those ads that show up
when I read my RSS feeds.
Blocks: 289312
*** Bug 262611 has been marked as a duplicate of this bug. ***
*** Bug 361679 has been marked as a duplicate of this bug. ***
downloading does not just happen when subscribing to the full article but also in the summary, e.g. slashdot uses 1x1 GIF webbugs to track the reading.

some people have a static IP, which makes this a privacy-issue. is it possible give it a higher priority because this webbug thing is probably not expected (opposed to avoiding the ads which is rather nice to have).

proof:
look at the code of http://rss.slashdot.org/Slashdot/slashdot and download one of the image links in there:

$ wget http://rss.slashdot.org/~r/Slashdot/slashdot/~4/53259924
--21:39:33--  http://rss.slashdot.org/~r/Slashdot/slashdot/~4/53259924
           => `53259924'
Auflösen des Hostnamen »rss.slashdot.org«.... 66.150.96.117, 66.150.96.111
Verbindungsaufbau zu rss.slashdot.org|66.150.96.117|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 43 [image/gif]

100%[=================================================================================>] 43            --.--K/s

21:39:33 (3.42 MB/s) - »53259924« gespeichert [43/43]

$ file 53259924
53259924: GIF image data, version 89a, 1 x 1


I managed to block web bugs in RSS successfully with Adblock Plus so this is certainly not an issue with ShouldLoad() not being called, maybe a problem with the internal logic of nsMsgContentPolicy.cpp.
slashdot has just started to include picture-ads in some of the summaries. that's definitely not what i would expect when i checked "no images in the messages".

for examples see:
http://rss.slashdot.org/Slashdot/slashdot
I can confirm this, the RSS feed can load images even with "block loading remote images" checked, Adblock Plus blocks them easily however. Looking at nsMsgContentPolicy source code I found:

  // (2) special case RSS urls, always allow them to load remote images since the user explicitly
  //     subscribed to the feed.

So this is a feature, yet probably a bad one. IMO RSS feeds shouldn't be allowed to load anything but the actual post when this option is checked (not even this when the user chose to see the article's summary), I can't exactly see why they should be an exception from the rule.
QA Contact: general
Nominating wanted-thunderbird3.
Assignee: mscott → nobody
Flags: wanted-thunderbird3?
this bug should be clarified, re rss.  if a user selects to view the Summary, then the current mail message body options of HTML, Simple HTML, or Plaintext should apply *and* they should be separate from the mail preference (bug 253853).  loading of remote images for rss Summary, to operate as it does for mail messages, would require building a whitelist mechanism; this is currently done by using the addressbook.  this method wouldn't be desirable for rss web sites.

if a user selects to view the rss item's Web Page, then full HTML should load, exactly as if the page were opened in a browser.  it's not for Tb to build in an ad blocker for web pages.  an excellent extension exists for that.

in any event, web bugs for email are far worse as they can confirm an email was received.  this issue doesn't exist in rss. 
alta88, View | Message Body | Simple HTML is a mechanism independent of and applied before nsMsgContentPolicy. This bug is about the latter only.
if it's strictly about the module and not the function, yes of course.  but there are other ways to block <img src=../> or other remote loads in rss Summary and/or Web Page.  i'm sure you're familiar with mozSanitizingHTMLSerializer, part of mime handling and Message Body As view options.  so removing the <img> tag from the pref [i]mailnews.display.html_sanitizer.allowed_tags[/i] (and selecting Simple HTML) would take care of it before it even got to nsMsgContentPolicy.

blocking-thunderbird3.1: --- → ?
Version: unspecified → Trunk
Our current 3.1 blocking criteria are:

a) make the upgrade experience from TB2 very painful for a large number of users

or 

b) be a new, reproducible, severe quality issue (eg dataloss, frequent crashes)

This doesn't appear to match either of those, so marking blocking-.
blocking-thunderbird3.1: ? → -
Flags: wanted-thunderbird3?
Component: General → Security
Product: Thunderbird → MailNews Core
You need to log in before you can comment on or make changes to this bug.