http://hydrillabugs.koszko.org/http://hydrillabugs.koszko.org/favicon.ico?15861920342021-09-11T19:58:39ZHydrilla issue trackerHaketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3772021-09-11T19:58:39Zkoszkokoszko@koszko.org
<ul></ul><p>Jahoti, please, remind me. Why aren't we just making a synchronous AJAX call in the content script and redirecting it appropriately using webRequest?</p>
<p>Btw, I tested that redirecting to <code>data:</code> works under Ungoogled Chromium. I seem to be having problems getting anything to work under Mozilla but honestly, I experimented little</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3782021-09-11T19:58:46Zkoszkokoszko@koszko.org
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3802021-09-11T22:53:04Zjahoti
<ul></ul><blockquote>
<p>Jahoti, please, remind me. Why aren't we just making a synchronous AJAX call in the content script and redirecting it appropriately using webRequest?</p>
</blockquote>
<p>Primarily because you never mentioned it and I never thought of it :). If this works, it will make life much easier!</p>
<blockquote>
<p>Btw, I tested that redirecting to data: works under Ungoogled Chromium. I seem to be having problems getting anything to work under Mozilla but honestly, I experimented little</p>
</blockquote>
<p>I will continue the experimenting right now.</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3812021-09-12T01:00:49Zjahoti
<ul></ul><p>It turns out Firefox did once support redirection to <code>data:</code> URLs (prior to v60, it seems), before it was accidentally broken and forgotten about for long enough the devs decided it wasn't worth fixing: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1475832">https://bugzilla.mozilla.org/show_bug.cgi?id=1475832</a>. It's quite shocking how many useful old features have been left to rot by Mozilla.</p>
<p>That said, there are several options. Apart from the obvious approach of <code>data:</code> URLs for Chromium and <code>contentScripts.register</code> for Firefox, both browsers support <code>tabs.executeScript</code> (and Manifest V3 has the somewhat similar <code>scripting.executeScript</code>), and somebody has somehow written a <a href="https://github.com/fregante/content-scripts-register-polyfill" class="external"><code>contentScripts.register</code> polyfill</a> for Chromium.</p>
<p>This might also (not as a priority!) remove the need for bundled secrets on Chromium, in fact, as the secret can be stored in storage.</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3842021-09-13T06:25:15Zkoszkokoszko@koszko.org
<ul></ul><blockquote>
<p>That said, there are several options. Apart from the obvious approach of <code>data:</code> URLs for Chromium and <code>contentScripts.register</code> for Firefox, both browsers support <code>tabs.executeScript</code> (and Manifest V3 has the somewhat similar <code>scripting.executeScript</code>), and somebody has somehow written a <a href="https://github.com/fregante/content-scripts-register-polyfill" class="external"><code>contentScripts.register</code> polyfill</a> for Chromium.</p>
</blockquote>
<p>Actually, I thought about simply redirecting to an extension-packaged file. For basic functionality we only need 3 such files, with contents that tell the content script to either allow everything, block scripts or block scripts & sanitize <code><meta></code>s. For the third option we would need to find a way content script could deal without an immediately-accessible nonce... but this should be achievable. Although I am still suspecting it might be possible to smuggle arbitrary data somehow</p>
<p>As to <code>tabs.executeScript</code> (and the polyfill that depends on it), I don't thing it gives the <code>document_start</code> guarantees we need :/</p>
<blockquote>
<p>This might also (not as a priority!) remove the need for bundled secrets on Chromium, in fact, as the secret can be stored in storage.</p>
</blockquote>
<p>With this we're not going to need any secret at all :)</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=3912021-09-14T01:59:41Zjahoti
<ul></ul><blockquote>
<p>Actually, I thought about simply redirecting to an extension-packaged file. For basic functionality we only need 3 such files, with contents that tell the content script to either allow everything, block scripts or block scripts & sanitize <code><meta></code>s. For the third option we would need to find a way content script could deal without an immediately-accessible nonce... but this should be achievable. Although I am still suspecting it might be possible to smuggle arbitrary data somehow</p>
</blockquote>
<p>That's a good idea! Come to think of it, couldn't we use the query component of the file's URL to smuggle arbitrary data? In fact the actual contents of the file wouldn't even really matter then- the full path itself could provide all the necessary information.</p>
<blockquote>
<p>As to tabs.executeScript (and the polyfill that depends on it), I don't thing it gives the document_start guarantees we need :/</p>
</blockquote>
<p>Ah! I forgot about that.</p>
<blockquote>
<p>With this we're not going to need any secret at all :)</p>
</blockquote>
<p>Which means we won't need any dependencies either! (Not, of course, that it's a significant problem anyway)</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4302021-10-18T06:24:32Zjahoti
<ul></ul><p>Unfortunately, smuggling via redirection of requests seems to open up the risk of fingerprinting; I can't find a useful way to distinguish requests made by content script from requests made by pages :'(. </p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4312021-10-18T08:09:36Zkoszkokoszko@koszko.org
<ul></ul><p>jahoti wrote:</p>
<blockquote>
<p>Unfortunately, smuggling via redirection of requests seems to open up the risk of fingerprinting; I can't find a useful way to distinguish requests made by content script from requests made by pages :'(.</p>
</blockquote>
<p>I thought the "universal" way would be to keep track of what tabs and frames have already made such request and only redirect the first such request in frame's lifetime, blocking subsequent ones.</p>
<p>I did, however, hope there could be some simpler solution. When I tried it seemed that some fields of the <code>details</code> object were different in cases the AJAX call was made by content script. Or have you already found that this is not reliable enough?</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4322021-10-19T05:22:01Zjahoti
<ul></ul><blockquote>
<p>I did, however, hope there could be some simpler solution. When I tried it seemed that some fields of the details object were different in cases the AJAX call was made by content script. Or have you already found that this is not reliable enough?</p>
</blockquote>
<p>Not at all- the documentation, insofar as I can tell, doesn't mention such behavior. When there's time I'll test and see if there's any information available on what happens.</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4362021-11-19T17:08:07Zkoszkokoszko@koszko.org
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>koszko</i></li></ul><p>jahoti wrote:</p>
<blockquote>
<blockquote>
<p>I did, however, hope there could be some simpler solution. When I tried it seemed that some fields of the details object were different in cases the AJAX call was made by content script. Or have you already found that this is not reliable enough?</p>
</blockquote>
<p>Not at all- the documentation, insofar as I can tell, doesn't mention such behavior. When there's time I'll test and see if there's any information available on what happens.</p>
</blockquote>
<p>I have an even better idea!</p>
<p>When page makes an XmlHttpRequest to our special <code>(chrome-)extension://</code> URL, we need to block it to avoid fingerprinting. When content script makes the call, we need to somehow return information whether scripts on given page should be blocked and, if applicable, what the nonce is.<br>
We could block the call always when scripts are to be allowed and redirect it in other cases. This will block XmlHttpRequests a script-enabled page makes. When scripts are disallowed, page cannot do XmlHttpRequests, so fingerprinting will be impossible.</p>
<p>There's a loophole: the user might have a page opened with scripts allowed and then change settings to block scripts. Until the page gets reloaded, it will be able to fingerprint.<br>
We could try to make some workarounds here but I'd consider it lower priority - risk is low here and some particular circumstances must occur for fingerprinting to work - i.e. someone who surfs the web with scripts always disabled will not be vulnerable to this. Mozilla users won't be either because of randomization of extensions' ids</p>
<p><strong>EDIT: It won't work after all because the <code>details</code> object available in onBeforeRequest does not provide the full, unspoofable URL of the page that initiates the request...</strong></p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4372021-11-19T18:07:18Zkoszkokoszko@koszko.org
<ul></ul><p>You know what? I'd leave the fingerprinting issue for now. The vunlerability doesn't exist in Mozilla browsers and can be <a href="https://developer.chrome.com/docs/extensions/mv3/manifest/web_accessible_resources/#manifest-declaration" class="external">mitigated</a> in Manifest V3 under Chromium which we're going to support anyway. It might be more practical to release more quickly and just warn users of this</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4382021-11-20T17:32:30Zkoszkokoszko@koszko.org
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>The commit that removes smuggling via cookies and employs synchronous XHR for the job is now on the <code>koszko</code> branch. This temporarily breaks Mozilla port</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4492021-11-30T01:27:51Zjahoti
<ul></ul><blockquote>
<p>I'd leave the fingerprinting issue for now. The vunlerability doesn't exist in Mozilla browsers and can be mitigated in Manifest V3 under Chromium which we're going to support anyway.</p>
</blockquote>
<p>Dynamic content scripts can also be used in both cases, which may be necessary (seeing as Mozilla doesn't offer effective synchronous AJAX).</p>
Haketilo - Feature #92: Replace cookie smuggling with some safer approachhttp://hydrillabugs.koszko.org/issues/92?journal_id=4942022-02-18T11:35:16Zkoszkokoszko@koszko.org
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>In <code>master</code></p>