search

andryou / scriptsafe

a browser extension to bring security and privacy to chrome, firefox, and opera
https://www.andryou.com/scriptsafe
509 stars 79 forks source link

UA-spoofing with CloudFlare; loading css fails. (UA-spoofing for css-GETs not working?) #89

Open John-Doe-Smith opened 8 years ago

John-Doe-Smith commented 8 years ago

Hello.

(Chrome/51.0.2704.103) UA spoofing seems to cause some problems with CloudFlare. Problems occur when trying to load css styles for a CF-protected page "https://www.random.org" from "https://www.random.org/css/style.css". When accessing "https://www.random.org/css/style.css" manually, there are no problems and the css displays as a page of text, as expected. But when "https://www.random.org" tries to internally GET "https://www.random.org/css/style.css", console logs 403 for the GET.

The 'network' tab in dev tools records the header for the css GET as using req header with NOT spoofed user-agent. Some of the other files' (these all seem to be blocked js-files) req headers are with non-spoofed UA too, but they have that "Provisional headers are shown" with them; the css GET does not have that. Other files do have spoofed UA, as expected.

I assume CF uses UA to compute a part of those "clearance" cookies. This is because the CF "security-check" screen pops back up to block access when changing UA spoofing ON/OFF. If the non-spoofed UA is really sent out, the discrepancy might trigger the problem. Just a guess, though.

ps. It would actually seem that all css-GETs are done with no UA spoofing. Only CF "cares" that those match; thus the initial problem.

andryou commented 7 years ago

v1.0.8.5 has officially been released. Could you please retest (once you verify that ScriptSafe v1.0.8.5 is installed) and let me know if the issue is still present? Thanks!