Over to the XML component. Do flash or java provide ways to issue TRACE requests? If so, wouldn't that be a bug with those plugins? I believe that our plugin API gives plugins the ability to issue HTTP requests using our stack, but a plugin could easily use its own HTTP stack, so limiting what a plugin can do wouldn't be worth it.
(In reply to comment #1) > Over to the XML component. > > Do flash or java provide ways to issue TRACE requests? I do not know. I'm not a specialist in either Mozilla or those plugins. > If so, wouldn't that be > a bug with those plugins? I believe that our plugin API gives plugins the > ability to issue HTTP requests using our stack, but a plugin could easily use > its own HTTP stack, so limiting what a plugin can do wouldn't be worth it. I believe the opposite. Using browser's HTTP stack gives more power than using its own HTTP stack: depending on the browser's implementation, it may use secret credential stored in the browser, or it may share the keep-alive connections and proxy connections with other browser-initiated request(*1). This cannot be achieved by plugin's own HTTP implementation. The reported problem does not arise for any components which uses its own HTTP implementation, unless users told the same secret explicitly to such components. So, allowing its HTTP stack for other's use should be careful in general. Having an interface which allows arbitrary requests to be sent is equivalent to having an interface which allows every secret passwords to be read by them. Having own "sanity check" before using own secret credential will be a good, "more secure" idea. (*1) If Mozilla differentiate between internally/externally generated request and do not perform such a thing for external requests, it is no problem. I don't know about such internal issue.
You make a good point about re-using the same HTTP stack. It is indeed the case that Mozilla does not differentiate external vs internal HTTP requests, so they would all potentially be pipelined together, for example. But, plugins do actually have access to Mozilla's password cache. There is an API for that explicitly to allow the Java plugin to act like it is using Mozilla's HTTP stack when in fact it is not.
(In reply to comment #3) > But, plugins do > actually have access to Mozilla's password cache. There is an API for that > explicitly to allow the Java plugin to act like it is using Mozilla's HTTP stack > when in fact it is not. Oops... Is it a good design? I might become wanting to send a featurewish bug report about changing this interface :-P # Is there a API for getting cookies, too? Anyway, this answers to my first concern, in very unexpected way :-) Now this is not the issue for plugin (modulo cookies), I agree. Fixing it at XMLHTTP layer will be fine. # How about issues in bug 302263? Does the problems regarding # Content-length and Transfer-encoding reappear for plugins? ## Host might not be a problem in this case.
there is an API for cookies too, yes. Additionally, plugins _can_ use mozilla's networking stack if they so desire.
(In reply to comment #5) > there is an API for cookies too, yes. Additionally, plugins _can_ use mozilla's > networking stack if they so desire. OK. Self Addition to #4: I feel that possible plugin-based request-splitting issue (which I have written in #4) is less critical (at least) now. (Because there are no known vulnerable plugins) Please keep it aside now. # Does someone know whether Macromedia flash has an ability to # pass arbitrary-chosen HTTP headers to Mozilla?
Created attachment 190884 [details] [diff] [review] v1 patch
The standard plugin API only supports Get and post. The plugin could make it's own raw calls of course, but not using our networking engine. We added scriptability to plugins, but that should be sandboxed to the containing web page and again not allow raw access to the network engine. Java has a special OJI interface with more stuff exposed, but applets shouldn't have raw access to anything.
Comment on attachment 190884 [details] [diff] [review] v1 patch sr=dveditz
(In reply to comment #8) > The standard plugin API only supports Get and post. The plugin could make it's > own raw calls of course, but not using our networking engine. plugins can get the service manager (http://lxr.mozilla.org/seamonkey/source/modules/plugin/base/public/npapi.h#419) and from that the necko services. plugins can use mozilla's networking engine just fine.
(In reply to comment #10) > plugins can get the service manager [...] and from that the necko services. > plugins can use mozilla's networking engine just fine. True, but then they've stepped outside the NPAPI into functionality that won't work on other browsers like Opera or Safari so there's a fair incentive not to do that. And a plugin author would be insane if they passed that raw ability through to the media content. If they allow content to send TRACE they've gone out of their way to do so, it's their flaw.
Comment on attachment 190884 [details] [diff] [review] v1 patch r=jst
a bunch of test cases dumped into https://bugzilla.mozilla.org/show_bug.cgi?id=297078
Comment on attachment 190884 [details] [diff] [review] v1 patch a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.
I did test this and it passed on ff 1.0.8 on all platforms. example: mfTest: bug 302489: Test https://bugzilla.mozilla.org/show_bug.cgi?id=302489: XMLHTTP TRACE method can reveal proxy passwords to web sites Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060221 Firefox/1.5 Passed. (Pass: 1, Fail: 0) mfTest: bug 302489: ASSERT: Passed : XMLHttpRequest prevented from sending TRACE requests mfTest: bug 302489: INFORM: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: http://test.mozilla.com/tests/mozilla.org/security/302489-01.html :: test :: line 69" data: no]