Cross-site Scripting (XSS) - Stored in bookstackapp/bookstack


Reported on

Mar 5th 2022


Iframe tags don't have a sandbox attribute, this makes an attacker able to execute malicious javascript via an iframe and perform phishing attacks. The sandbox attribute will block script execution and prevents the content to navigate its top-level browsing context which will stop this type of attack.

Proof of Concept

Tested on firefox.

<!-- phishing.html | change page content to <iframe src="">-->
<script>alert("Your session has expired, Please enter your credential again")</script>
<script> = ""; </script




This vulnerability is capable of phishing and stealing users' data.

We are processing your report and will contact the bookstackapp/bookstack team within 24 hours. 2 years ago
We have contacted a member of the bookstackapp/bookstack team and are waiting to hear back 2 years ago
Dan Brown
2 years ago


Thanks for reporting this @416e6e61. Just before I approve this I just want to confirm that my thinking is correct and that my solution would be suitable:

  • The primary issue here is the ability to redirect the parent page.
  • This redirect is blocked by browsers by default in cross-origin context (Where this would be dangerous) but a user could simply add sandbox="allow-top-navigation allow-scripts" to work around this right now so we're still vulnerable.

Within BookStack iframes are used for interactive content, so we'd generally need to still allow scripts (And possibly other interactive content). Therefore, I'm instead thinking we could take the following approach:

  • Add a configurable CSP frame-src header rule to limit the sources that iframes can load.
  • This will effectively act as a a whitelist for iframe sources.
  • By default, we'd set this to a limited range of well-known media sources (Youtube, vimeo etc..)

Is the above correct and would you consider the solution proposed to be one that suitably negates the risk of the vulnerability?

2 years ago


Thanks for the fast response, as you said configuring CSP and only allowing media sources should be a good solution for this, and I can confirm it.

Dan Brown validated this vulnerability 2 years ago
Anna has been awarded the disclosure bounty
The fix bounty is now up for grabs
Dan Brown
2 years ago


Patch with about whitelist approach now released. Relevant links:

Thanks again @416e6e61 for reporting!

Dan Brown marked this as fixed in v22.02.3 with commit 856fca 2 years ago
Dan Brown has been awarded the fix bounty
This vulnerability will not receive a CVE
to join this conversation