Recently, I had a brief look at the Froala WYSIWYG HTML Editor (v3.2.0) as there was a post about it on the Full Disclosure mailing list.
When targeting a HTML Editor, I guess one of the first things that everybody does is to check for XSS vulnerabilities. So I tried the usual XSS payloads (a great resource for XSS payloads is the XSS cheat sheet by PortSwigger) within the editor’s code view, but did not have much luck with the common payloads as they were filtered. However, using the HTML object tag, it was possible to trigger an XSS.
The following figure shows the payload used within the code browser (click on the image to enlarge it):
Afterwards, switching to normal view triggers the XSS in the context of the website, on which the editor is hosted:
(Unfortunately, I positioned my mouse over the port displayed in the alert box, but believe me, it is the same as the one that has been used to access the web page ;))
The vulnerability has been reported to Froala and they fixed it in version 3.2.2 of the editor. Moreover, CVE-2020-26523 was assigned to the issue.
To conclude this little story, it should be noted that – in general – there are many HTML tags that can serve as XSS attack vectors. From the perspective of a developer, all of these tags have to be considered within the prevention mechanisms against XSS vulnerabilities. From the perspective of a pentester, all of these tags should be tested for XSS vulnerabilities as, for example, filtering may not be correctly implemented for some tags.
2020-07-22 Contacted Froala via support web form
2020-07-22 Received response via mail with general information on XSS vulnerabilities
2020-07-23 Sent email with the details of the vulnerabilities and started 90 days disclosure deadline
2020-07-23 Received response that the issue has been forwarded to developers
2020-09-23 Asked for an update on the issue via email
2020-09-23 Received response that issue was fixed in 3.2.2
2020-10-21 Disclosure deadline ends
2020-11-18 Publication of blogpost