Doesn't work in mobile.twitter.com on firefox for Android likely due to CSP img-src restriction
changhaitravis opened this issue · comments
I've been using the firefox plugin for at least a month now on my Android phone, and it works spectacularly for the most part. However, the only website I've encountered where it seems to pretty consistently not work is mobile.twitter.com . I just ran the WebIDE debugger to see what was going on and it looks like CSP may be the culprit.
Here's the CSP entry on mobile.twitter.com for the "img-src" excerpt.
img-src 'self' blob: data: https://*.cdn.twitter.com https://ton.twitter.com https://*.twimg.com https://www.google-analytics.com https://www.periscope.tv https://www.pscp.tv https://media.riffsy.com https://*.giphy.com https://*.pscp.tv;
if the Content-Security-Policy: header exists and a img-src
entry exists in the site's response header, then add the current proxy address's host in as a <host-source> entry. According to the below.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/img-src
It'll involve intercepting and modifying the response headers... will this prevent distribution on firefox add-ons marketplace when reviewed?
I may try coding this up and file a pull request sometime after testing locally.
Hi!
It should already change csp header to include proxy host (see https://github.com/ayastreb/bandwidth-hero/blob/master/src/background.js#L127 and https://github.com/ayastreb/bandwidth-hero/blob/master/src/background/patchContentSecurity.js).
If you can find a solution, I'd love to see a PR!
That makes sense, because I don't think I was able to reproduce this on firefox for desktop (linux)
update: Confirmed that it works fine on desktop firefox
I've mainly tested on web-ext. Wanted to put it through its paces a little more, however apparently I need a signed build or something.
Basically I was messing with CSP itself until I noticed that on Android mobile.twitter.com was firing off Fetch requests, while on Desktop (linux) it was firing off more conventional Xhr requests. The Xhr requests did not have CSP headers, however the Fetch requests did... this could just be an oversight on Twitter's part, or a feature of the Fetch API, or both.
Looks like I forgot to handle another type of CSP header used on gawker sites (kotaku) and https://unwrappedlife.com/
"Upgrade-Insecure-Requests"
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Upgrade-Insecure-Requests
https://www.samsung.com/us/mobile/galaxy-s10/ on this page, it's running into the 'default-src' CSP header, even when connected via HTTPS proxy
UPDATE, the samsung site placed its CSP in the main document as a meta tag on the CSP header, this case would be tougher to fix without causing other issues/more work.
Tried fixing meta tag header CSP by DOM manipulating response body in firefox. Failed miserably, won't fix. Better to detect if meta csp is in use and add site to blacklist