3 ms·

Not OP, but disabling xhr is not possible and disabling it wouldn’t achieve much. The modern browser has many apis with which to make remote calls such as fetch

Not OP, but disabling xhr is not possible and disabling it wouldn’t achieve much. The modern browser has many apis with which to make remote calls such as fetch, web sockets, and web rct. They can also fall back to classic methods like jsonp, crafty css skullduggery, and iframes. The reason why this css thing is not a major problem is that the js could retrieve this data just as easily using one of the other methods I listed. JS retrieving data from an external API is generally not a problem unless its used for tracking purposes or as part of an cross site scripting attack. At worst, this gives online tracking companies yet another tool in their toolbox. I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. I can’t really see it being used for cross site attacks unless some whackadoodle site decided to try and send secreted authenticated data via CSS payloads.

brigandish 6y ago
> disabling xhr is not possible uMatrix can do it, I'm sure there are others > fetch fetch is a Javascript API and covered by uMatrix's XHR setting[1]. > web rct That can be disabled[2] and is also covered by uMatrix's XHR setting. > iframes Can be blocked in several ways, including the aformentioned uMatrix. > At worst, this gives online tracking companies yet another tool in their toolbox At worst CSS in the browser has had a CVE[3] and OWASP has some attacks[4] that seem old, but you know which of these have been fixed by all the browser vendors you use, right? Perhaps you've read this paper[5] on scriptless attacks and you know that all of these have been mitigated? > The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website. Even better, you have the faith that there will never be a repeat of these kind of things and that no attackers will bother to go down this route in future. What part does faith have when deciding upon the risks of running things downloaded from untrusted sources? Still, the anti-tracking is good enough reason for me. > I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. Let's hope so. [1] https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-type-cells https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-... [2] https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ [3] https://cve.circl.lu/cve/CVE-2011-0132 https://cve.circl.lu/cve/CVE-2011-0132 [4] https://owasp.org/www-community/xss-filter-evasion-cheatsheet https://owasp.org/www-community/xss-filter-evasion-cheatshee... [5] https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlich...

brigandish 6y ago

> disabling xhr is not possible uMatrix can do it, I'm sure there are others > fetch fetch is a Javascript API and covered by uMatrix's XHR setting[1]. > web rct That can be disabled[2] and is also covered by uMatrix's XHR setting. > iframes Can be blocked in several ways, including the aformentioned uMatrix. > At worst, this gives online tracking companies yet another tool in their toolbox At worst CSS in the browser has had a CVE[3] and OWASP has some attacks[4] that seem old, but you know which of these have been fixed by all the browser vendors you use, right? Perhaps you've read this paper[5] on scriptless attacks and you know that all of these have been mitigated? > The surprising result is that an attacker can also abuse Cascading Style Sheets (CSS) in combination with other Web techniques like plain HTML, inactive SVG images or font files. Through several case studies, we introduce the so called scriptless attacks and demonstrate that an adversary might not need to execute code to preserve his ability to extract sensitive information from well protected websites. More precisely, we show that an attacker can use seemingly benign features to build side channel attacks that measure and exfiltrate almost arbitrary data displayed on a given website. Even better, you have the faith that there will never be a repeat of these kind of things and that no attackers will bother to go down this route in future. What part does faith have when deciding upon the risks of running things downloaded from untrusted sources? Still, the anti-tracking is good enough reason for me. > I am sure the boffins down at ublock are already working on detecting and mitigating this behaviour. Let's hope so. [1] https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-type-cells https://github.com/gorhill/uMatrix/wiki/The-popup-panel#the-... [2] https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ https://www.ivacy.com/internet-privacy/disable-webrtc-leak/ [3] https://cve.circl.lu/cve/CVE-2011-0132 https://cve.circl.lu/cve/CVE-2011-0132 [4] https://owasp.org/www-community/xss-filter-evasion-cheatsheet https://owasp.org/www-community/xss-filter-evasion-cheatshee... [5] https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2012/08/16/scriptlessAttacks-ccs2012.pdf https://www.nds.ruhr-uni-bochum.de/media/emma/veroeffentlich...