2 ms·

sidenote: be careful when opening a webarchive from a third party, if that improvable opportunity ever materializes: > In February 2013, a vulnerability with t

by hu3 2y ago

sidenote: be careful when opening a webarchive from a third party, if that improvable opportunity ever materializes: > In February 2013, a vulnerability with the webarchive format was discovered and reported by Joe Vennix, a Metasploit Project developer. The exploit allows an attacker to send a crafted webarchive to a user containing code to access cookies, local files, and other data. Apple's response to the report was that it will not fix the bug, most likely because it requires action on the users' part in opening the file. https://en.wikipedia.org/wiki/Webarchive#Vulnerability https://en.wikipedia.org/wiki/Webarchive#Vulnerability

tedmiston 2y ago
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-...
- nikisweeting 2y ago
  This category of issue is present with many types of web archives. Sanitizing archives during capture or retrieval while maintaining fidelity is a really hard problem.
deleted 2y ago
[deleted]

by hu3 2y ago

tedmiston 2y ago

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-...

nikisweeting 2y ago
This category of issue is present with many types of web archives. Sanitizing archives during capture or retrieval while maintaining fidelity is a really hard problem.

deleted 2y ago

[deleted]