WebWriter opens all explorables in iframes, which provides some isolation between the explorable document and the editor. While the default iframe configuration is enough to avoid unintentional leakage of styles and scripts into the editor, intentional attacks using scripts remain a potential issue.
Scenarios:
An attacker creates a malicious explorable with a script that accesses WebWriter's Tauri API for file system access, script execution, etc. . They distribute this explorable as a trojan on a OER portal.
Mitigations:
[ ] Limit file system access to the app directory (and the currently opened file) - this is Tauri's default which is currently disabled because of the way local packages are implemented
[ ] Set permissions so that the the iframe is considered a different origin (Same Origin Policy), effectively preventing any script access between the iframe and the main (editor) document - this would require re-implementing the editor to use postMessage for setup and configuration OR this might be possible with the new csp property (https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/csp)
WebWriter opens all explorables in iframes, which provides some isolation between the explorable document and the editor. While the default iframe configuration is enough to avoid unintentional leakage of styles and scripts into the editor, intentional attacks using scripts remain a potential issue.
Scenarios:
Mitigations:
cspproperty (https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/csp)