Closed Mia0a-hi closed 7 months ago
Hi @Mia0a-hi, Both of these area is intended for users to be able to enter HTML content. By themselves, I wouldn't consider these as XSS vulnerabilities.
Just a note on reporting, you appeared to announce and query reporting a vulnerability:
and then you proceeded to post in public anyway. We have a security page with details for reporting. Please give a project some reasonable time to respond to a single point of outreach, instead of blasting every communication avenue before posting the issue anyway.
Hi @Mia0a-hi, Both of these area is intended for users to be able to enter HTML content. By themselves, I wouldn't consider these as XSS vulnerabilities.
Reporting
Just a note on reporting, you appeared to announce and query reporting a vulnerability:
- Via 3 threads on our Discord
- Attempted to PM me on Discord
- Via email to me twice
and then you proceeded to post in public anyway. We have a security page with details for reporting. Please give a project some reasonable time to respond to a single point of outreach, instead of blasting every communication avenue before posting the issue anyway.
I'm sorry to see the report you mentioned. I may want to submit this vulnerability as soon as possible. In terms of vulnerabilities, it may be a normal requirement in (Custom HTML Head Content), but it is a vulnerability in the text editing function point.
but it is a vulnerability in the text editing function point.
But we expect HTML to potentially be in this input. In the WYSIWYG editor there's also a direct HTML input, although with a little more editor-side filtering than the markdown editor (same back-end filtering though). Then there's also the API which takes HTML.
At some level, if a user is given permission to edit there's a level of trust there that they won't add malicious content.
but it is a vulnerability in the text editing function point.
But we expect HTML to potentially be in this input. In the WYSIWYG editor there's also a direct HTML input, although with a little more editor-side filtering than the markdown editor (same back-end filtering though). Then there's also the API which takes HTML.
At some level, if a user is given permission to edit there's a level of trust there that they won't add malicious content.
I understand what you mean. You think about it from the perspective of a developer or a product designer. But considering the overall direction of the application, this thing is indeed a loophole. Maybe there will be account borrowing within the security perimeter? User credentials leaked? Public account multi-user situation. Thanks.
Okay, I'm going to proceed to close this off as I don't see this moving much further forward. To be clear I am happy to address XSS issues, as I have done in the past, but I'm just not considering the use of HTML content in the described areas as an XSS issue, since that's expected at some level. I would consider is a XSS if it was content we specifically are preventing and/or is a bypass of our existing controls. Thanks for taking the time to report this though.
Okay, I'm going to proceed to close this off as I don't see this moving much further forward. To be clear I am happy to address XSS issues, as I have done in the past, but I'm just not considering the use of HTML content in the described areas as an XSS issue, since that's expected at some level. I would consider is a XSS if it was content we specifically are preventing and/or is a bypass of our existing controls. Thanks for taking the time to report this though.
No problem, brother. hope the project will get stronger and stronger.
Describe the Bug
An attacker can exploit this vulnerability to inject malicious client-side code on the website
Steps to Reproduce
bugs
![2](https://github.com/BookStackApp/BookStack/assets/40627909/dfe9e6cd-5d19-4c02-8648-38c0ecd0dbfb)
Expected Behaviour
to filter
Screenshots or Additional Context
1
Browser Details
all
Exact BookStack Version
v23.10.4