Multiple Security/Privacy Issues in Canvas (Malicious Website can access internal Obsidian URI)


In summary: a website card that loads a malicious website into a Canvas view can corrupt arbitrary vault documents, leak some privacy information, and spawn new internal URI calls and some external processes.

Details: The new canvas feature allows remote websites to trigger internal obsidian URIs like open/new/search etc. both directly and through the x-success parameter. These URIs can be triggered by the website calling a meta refresh directive i.e<meta http-equiv="refresh" content="0;URL='obsidian://new? … etc.

In the first order this allows any websites dropped into Canvas to add/delete/modify any file in the loaded vault. Creation of files is limited to .md files, but editing includes .canvas files. Because open and new URIs auto-open files in Obsidian this allows a single corrupted website to effectively chain spawn multiple malicious URI processes.

Because Canvas website cards can call OS-level URIs like ms-excel (in addition to e.g. https) this means that a malicious website loaded into a canvas context can effectively force-open a number of different applications on the system (and depending on the OS configuration this could lead to exploiting further vulnerabilities and/or arbitrary code execution depending on the mapped applications)

As an aside: the above issue also allows a malicious website to corrupt and/or overwrite any other file type e.g. image files using the overwrite URI parameter.

Accessible URIs are not limited the documented open and new, but also non-public ones like show-plugin - and while I haven’t checked this, I assume the same would be true for any URIs exposed by community plugins also.

There is also a mild privacy issue in that because the x-successcallback is only called for valid files a malicious website dropped into a canvas could use that callback to map out valid and existing files.

Less impactful, the obsidian://new URI allows the creation of arbitrary folders outside of the vault hierarchy e.g. by setting file=../../../../new/folder/structure (though stops short of allow arbitrary file creation)

The sole mitigation is that exploitation requires that a user actively load a malicious website card into a Canvas (but it is worth noting that because each website card is refreshed on loading this means that honest websites that become corrupted are also a possible attack vector).



Thanks, we’ll look into it.

This will be addressed in v1.1.9.

1 Like

Embedded website will be restricted to only to navigate within http/https links.

A check will be added for this.

Both pushed in 1.1.9

1 Like

I get the security concerns, obviously, unfortunately the fix for this in 1.1.9 seems to have killed a key feature I’ve been using the canvas for the past couple weeks. Which is rendering local html files in the canvas via the webpage card (I’ve been using file:///… as the URL pointing to the local html files). So basically all my canvases are full of blank cards now. I assume the restriction to only http/https is the culprit. Is there any chance for a middle ground here to whitelist htm/html file types or something, or an option hidden somewhere to turn off the security feature?

I opened a feature request for that. Follow it.

Note that we also never supported embedding external attachments in regular notes.

1 Like