371123 - XMLHttpRequest should trigger content policies

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Wladimir Palant]

Currently XMLHttpRequest allows web sites to make a request that cannot be stopped with content policies. This can be used for tracking or for loading ads without giving users a chance to interfere with content blockers (actually, there are already sites that do this).

To test this:
1. Install Adblock Plus from https://addons.mozilla.org/firefox/1865/
2. Restart your browser and press Ctrl+Shift+B to open the "list of blockable items" (all addresses sent through content policies for the current page)
3. Go to http://jibbering.com/2002/4/httprequest.html and click the first "Try the example" link. An alert box with the contents of http://jibbering.com/2002/4/test.txt will appear.

Observed results:
"List of blockable items" doesn't show http://jibbering.com/2002/4/test.txt even though the contents of this file have been loaded.

Expected results:
http://jibbering.com/2002/4/test.txt should appear in the list as it happens for every other request.

Comment 1

[Wladimir Palant]

Attachment: Proposed patch

This fixes the bug - URLs requested with XMLHttpRequest appear in the list in Adblock Plus and can be blocked.

Comment 2

[Boris Zbarsky [:bzbarsky]]

I'm not going to be able to review this in the foreseeable future.  Try someone else, please?

Comment 3

[Johnny Stenback (:jst)]

Comment on attachment 255894 [details] [diff] [review]
Proposed patch

+  rv = NS_CheckContentLoadPolicy(nsIContentPolicy::TYPE_OTHER,
+                                uri,
...

Nit of the day: Second line (and following) argument indentation is one short.

r=jst

P.S. If Heikki doesn't sr this (not sure how much he keeps track of his sr requests any more), [e-mail] probably can...

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 255894 [details] [diff] [review]
Proposed patch

I haven't been a super-reviewer for several years, so somebody else should take this. Per jst's advice asking Jonas.

Comment 5

[Nickolay_Ponomarev]

Checked in with the requested whitespace change. Note that it's easier to check in patches that are diffed from /mozilla and incorporate fixes for all of the review comments.

mozilla/content/base/src/nsXMLHttpRequest.cpp  1.175

Comment 6

[Wladimir Palant]

Comment on attachment 255894 [details] [diff] [review]
Proposed patch

The patch itself is pretty straightforward, no possible failure points AFAICT - it is just the content policy call as used everywhere else. However, strictly speaking this is an interface change, we trigger content policies where we didn't do it before. I still don't expect any content policies to fail since almost all of them ignore TYPE_OTHER, and the ones that don't have to handle calls for XBL requests already which have the same parameters. Advantage of taking this change on the branch: we will close this loophole now, before it becomes a popular trick to get around content policies.

If this is approved for the branch I will request approval in bug 375435 as well - basically the same reasoning.

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 255894 [details] [diff] [review]
Proposed patch

approved for 1.8.1.4, a=dveditz for release-drivers

Comment 8

[Wladimir Palant]

Attachment: Patch for 1.8 branch

Comment 9

[mozilla]

(In reply to comment #8)
> Created an attachment (id=261088) [details]
> Patch for 1.8 branch
> 

I am using Gran Paradiso 3.0a3.

A serious bug appeared in this release that prevents Unicode characters from being properly transferred via XMLHttpRequest. I think it may be related to the introduction of content filtering for extensions such as AdBlock Plus. The unicode transfer fails to properly with or without AdBlock Plus installed.

I cannot get FireBug 1.04 to work properly with 3.0a3 and XMLHttpRequests, so I cannot yet explicitly identify the problem area. Receiving unicode via XMLHttp works in prior versions of Gran Paradiso. My data contains Unicode and ASCII. The ASCII comes across fine while the Unicode simply disappears within the same one record.

Please advise as to the proper forum that this should be posted.

Thank you

Comment 10

[Wladimir Palant]

This patch landed after Gran Paradiso Alpha 3 release, so it cannot have anything to do with your problem. Please create a new bug for it and include the exact steps to reproduce.

Comment 11

[Josh Aas]

landed on 1.8 branch

Comment 12

[Carsten Book [:Tomcat]]

verified fixed 1.8.1.4 using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.4pre) Gecko/2007042805 BonEcho/2.0.0.4pre and the steps to reproduce from  comment #0.

http://jibbering.com/2002/4/test.txt is now in the List of blockable items -> adding verified keyword.