Firefox will add a new drive-by-download protection
Mozilla will add a new security feature to Firefox in October that will make it harder for malicious web pages to initiate automatic downloads and plant malware-laced files on a user’s computer.
Called a drive-by download, this type of attack has been around for two decades and usually takes place when users visit a website that contains malicious code placed there by an attacker.
The role of the malicious code is to abuse legitimate features in browsers and web standards to initiate an automatic file download or download prompt, in the hopes of tricking the user into running a malicious file.
There are multiple forms of drive-by downloads, depending on the browser feature attackers decide to use.
Browsers like Chrome, Firefox, and Internet Explorer have, across the years, gradually deployed various forms of protections against automatic drive-by downloads, but 100% protection can’t be fully achieved because browser makers can’t fully block legitimate web features and also because of the shifting landscape of web attacks, with attackers always finding a new hole to poke at.
The latest round of protections that browser makers have decided to ship against drive-by downloads targets a technology called “sandboxed iframes,” which is often used to load ads and embeddable widgets (videos, music tracks, podcasts) on third-party sites.
The idea is that websites rarely initiate downloads via sandboxed iframes since most of these widgets are usually used to embed content.
Chrome was first to block downloads initiated from “sandboxed iframes” with the release of Chrome 73, in March 2019, and the option was removed completely in Chrome 83, in May 2020.
This week, Firefox announced similar plans. Starting with Firefox 82, scheduled for release next month, in October 2020, Firefox will block all file downloads that originate from a sandboxed iframe.
The only situations were downloads will be honored is if the website owner or the web widget provider has an “allow-download” flag on the iframe; however, most don’t since this is a security risk and a reason why they use sandboxed iframes in the first, rather than classic iframes.
Browsers are complex piles of code, and this is a small update in the grand scheme of things, but this is usually how you build a secure product, reacting to threats as they come, and making tiny adjustments here and there, over time.
A similar feature was proposed to the Safari WebKit team, but no plans have been laid out yet for its implementation.
READ MORE HERE