You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
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:
csp
property (https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/csp)The text was updated successfully, but these errors were encountered: