Description of the issue:
Our script is being blocked by Brave suddenly. Our solution operates on proxy.cside.devjs.cside.dev and proxy.csidetm.com are both scripts meant to intercept client-side scripts for analysis against malicious client-side actions like data exfiltration, crypto mining, malware injection… We understand our script does not look like the usual chatbot script however it is legitimate and used by various sites to prevent malicious client-side executions. We noticed Brave blocked proxy.cside.dev however when turning off Brave Shield everything returns to normal working condition. Can you please update your records to allow our script to be fetched again? Simon Wijckmans CEO c/side Steps to Reproduce (add as many as necessary): 1. 2. 3.
Visit cside.dev or looskie.com and notice the scripts not fetching Actual Result (gifs and screenshots are welcome!):
Expected result:
Unblock our domains proxy.cside.devjs.cside.devproxy.csidetm.com and cs.security (future use) Reproduces how often:
100% of the time on js.cside.devproxy.cside.dev
Operating System and Brave Version(See the About Brave page in the main menu):
All Additional Information:
Reproduced on multiple devices
Hi, thanks for your response.
So I refer to proxy.cside.dev as that is where our client-side script rewrites other scripts to.
The initial blocking is happening on js.cside.dev/script.js
We do referrer header validation to serve the correct client-side script for our customer so its normal to receive a host-header validation error on trying to access proxy.cside.dev or proxy.csidetm.com.
If I understand your response correct: because js.cside.dev/script’js points to a CNAME record of Cloudfront it is considered the same as cloudfront.net/script.js - am I correct?
If that is the case that would cause severe false positives as any file named script.js hosted on cloudfront would face the same issue. That does not make a ton of sense.
Our customer hard coded that script into their site, that is not a solution I’m afraid. Let me put Cloudflare in front of it so that you can’t trace the CNAME down to Cloudfront and see if that fixes it.
Can you try on your end? Brave continues to resolve to the Cloudfront DNS record on the browser while a terminal dig is not showing Cloudfront on my end - not sure if there is some blocking cache or DNS cache I can’t clear.
Thanks for your help. If I may be a Karen for 2 seconds - thats a lazy rule by the threatfeed. They could have at least included the Cloudfront subdomain ID in that rule. Now no one on the entire internet can host a file named script.js on Cloudfront without it being blocked by Brave. That makes no sense, IMO that rule should be filtered out by Brave as being a low quality false positive prone rule.
Its not specific at all though, if it was a script hash based block it would actually block the script but nothing is stopping the bad actor from moving to script2.js without changing the payload. If a bad actor put a malicious payload on index.html you wouldn’t block every Cloudfront bucket with an index.html on it either, you’d check the script payload. I also don’t think it makes sense that Brave is tracing down the DNS chain for such wide rules.
I wish everyone knew the name ‘script.js’ was doomed to use on a Cloudfront container but that sounds unrealistic. There are no alerts for that anywhere and I think its unfair to expect web developers to search Github for every filename they come up with whether it can trigger a super broadly written rule.
