@gimmic <big><big>W</big></big>ell I've poured over TONS of code this weekend, and needed a bit of time to gather my brain cells. Here's a few things that I've learned about XMLHttpRequest <ul> <li><a href='https://addons.mozilla.org/en-US/firefox/addon/966'>Tamper Data</a> add-on reports raw data and ignores other extensions (that's a big no no by the way).  </li> <li><a href='https://addons.mozilla.org/en-US/firefox/addon/3829'>Live HTTP Headers</a> add-on correctly reports the headers in cooperation with other add-ons.  </li> <li>Firefox 2.X also caches header requests... so they will also only show up once in the logs.  </li> <li><a href='https://addons.mozilla.org/firefox/addon/748'>Greasemonkey</a> is "sorta" responsible for not allowing the Referer header atom value to be set, but then again, sorta not!  </li> <li>Any call to XMLHttpRequest in the <a href='http://en.wikipedia.org/wiki/Chrome_Mozilla'>chrome namespace</a> (Firefox add-ons use this for those that don't know this) is considered "unprivileged" to modify the Referer header atom value UNLESS there is an event listener that modifies the raw data via the http channel OR there is a component add-on (I think that's XBL, still a bit noob to some of this) that is added to an existing add-on. Firefox currently has two sections, that I can find, in their trunk code (and existing releases too) that PURPOSELY BLOCKS OR CLEARS the Referer header atom value from being set in the chrome namespace.  </li> <li>Any XMLHttpRequest call made via <a href='http://wiki.github.com/Martii/greasemonkey/unsafewindow'>unsafeWindow</a> (e.g. the native DOM object created from a web server) is considered to be "privileged" enough to set the Referer header atom value.  </li> </ul> These last two points seem backwards... MOST security threats, in my circles, come from commercial entities NOT from scripters... but I know that's not always the case. Currently Firefox is not following the <a href=http://www.w3.org/TR/2007/WD-XMLHttpRequest-20071026/#xmlhttprequest'>W3C recommendations on XMLHttpRequest</a> by not allowing the Referer header atom value to be set in the chrome namespace using setRequestHeader. W3C Working Draft (e.g. a whitepaper or RFC) 26 October 2007 clip from Section 2, setRequestHeader method, Item 6 <ul><li><big><big>«</big></big>6. For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers: <ul> <li> Accept-Charset <li> Accept-Encoding <li> Connection <li> Content-Length <li> Content-Transfer-Encoding <li> Date <li> Expect <li> Host <li> Keep-Alive <li> Referer <li> TE <li> Trailer <li> Transfer-Encoding <li> Upgrade <li> Via </ul> <big><big>»</big></big></li></ul> I may annotate/cite this post further later... but I've been busy putting what I've learned in the last 36 hours into motion and I'm a bit dain bread from all of this. 8D Other related links</a> <a href='http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/77c94cc17c6b2669'>http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/77c94cc17c6b2669</a> <a href='http://wiki.github.com/Martii/greasemonkey/gm_xmlhttprequest'>GM_xmlhttpRequest</a> @gimmic <big><big>W</big></big>ell I've poured over TONS of code this weekend, and needed a bit of time to gather my brain cells. Here's a few things that I've learned about XMLHttpRequest <ul><li><a href="https://addons.mozilla.org/en-US/firefox/addon/966">Tamper Data</a> add-on reports raw data and ignores other extensions (that's a big no no by the way).  </li><li><a href="https://addons.mozilla.org/en-US/firefox/addon/3829">Live HTTP Headers</a> add-on correctly reports the headers in cooperation with other add-ons.  </li><li>Firefox 2.X also caches header requests... so they will also only show up once in the logs.  </li><li><a href="https://addons.mozilla.org/firefox/addon/748">Greasemonkey</a> is "sorta" responsible for not allowing the Referer header atom value to be set, but then again, sorta not!  </li><li>Any call to XMLHttpRequest in the <a href="http://en.wikipedia.org/wiki/Chrome_Mozilla">chrome namespace</a> (Firefox add-ons use this for those that don't know this) is considered "unprivileged" to modify the Referer header atom value UNLESS there is an event listener that modifies the raw data via the http channel OR there is a component add-on (I think that's XBL, still a bit noob to some of this) that is added to an existing add-on. Firefox currently has two sections, that I can find, in their trunk code (and existing releases too) that PURPOSELY BLOCKS OR CLEARS the Referer header atom value from being set in the chrome namespace.  </li><li>Any XMLHttpRequest call made via <a href="http://wiki.github.com/Martii/greasemonkey/unsafewindow">unsafeWindow</a> (e.g. the native DOM object created from a web server) is considered to be "privileged" enough to set the Referer header atom value.  </li></ul> These last two points seem backwards... MOST security threats, in my circles, come from commercial entities NOT from scripters... but I know that's not always the case. Currently Firefox is not following the <a href="http://www.w3.org/TR/2007/WD-XMLHttpRequest-20071026/#xmlhttprequest">W3C recommendations on XMLHttpRequest</a> by not allowing the Referer header atom value to be set in the chrome namespace using setRequestHeader. W3C Working Draft (e.g. a whitepaper or RFC) 26 October 2007 clip from Section 2, setRequestHeader method, Item 6 <ul><li><big><big>«</big></big>6. For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers: <ul><li> Accept-Charset </li><li> Accept-Encoding </li><li> Connection </li><li> Content-Length </li><li> Content-Transfer-Encoding </li><li> Date </li><li> Expect </li><li> Host </li><li> Keep-Alive </li><li>Referer</li><li> TE </li><li> Trailer </li><li> Transfer-Encoding </li><li> Upgrade </li><li> Via </li></ul><big><big>»</big></big></li></ul> I may annotate/cite this post further later... but I've been busy putting what I've learned in the last 36 hours into motion and I'm a bit dain bread from all of this. 8D Other related links <a href="http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/77c94cc17c6b2669">http://groups.google.com/group/greasemonkey-dev/browse_thread/thread/77c94cc17c6b2669</a> <a href="http://wiki.github.com/Martii/greasemonkey/gm_xmlhttprequest">GM_xmlhttpRequest</a>

2007-12-04T11:04:29Z

Forum

5312

1302

2009-10-13T07:06:16Z

37004