I initially glossed over this believing it may be something trivial, but it really is a deeper XSS concern. It feels weird me to dismiss as wontfix a security

I initially glossed over this believing it may be something trivial, but it really is a deeper XSS concern. It feels weird me to dismiss as wontfix a security issue that gives the archived page far greater access to browser data than it has loaded at its original URL. > Last updated at Tue, 16 Jan 2024 16:26:37 GMT > tldr: For now, don't open .webarchive files, and check the Metasploit module, Apple Safari .webarchive File Format UXSS > Safari's webarchive format saves all the resources in a web page - images, scripts, stylesheets - into a single file. A flaw exists in the security model behind webarchives that allows us to execute script in the context of any domain (a Universal Cross-site Scripting bug). In order to exploit this vulnerability, an attacker must somehow deliver the webarchive file to the victim and have the victim manually open it ^1 (e.g. through email or a forced download), after ignoring a potential "this content was downloaded from a webpage" warning message ^2. Just look at the number of (relatively trivial) attack vectors identified by the author in this post: > Attack Vector #1: Steal the user's cookies. > Attack Vector #2: Steal CSRF tokens. > Attack Vector #3: Steal local files. > Attack Vector #4: Steal saved form passwords. > Attack Vector #5: Store poisoned javascript in the user's cache. https://www.rapid7.com/blog/post/2013/04/25/abusing-safaris-webarchive-file-format/ https://www.rapid7.com/blog/post/2013/04/25/abusing-safaris-...