Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
1.6 M1
-
Unit
-
High
-
Unknown
-
N/A
-
Description
I have managed to trigger stored XSS in v13.2 of XWiki in default configuration. This appears to affect any field using the WYSIWYG editor. I originally found it in v11 but tested the newest version and it works there too. Any user (or guest depending on security settings) can store JavaScript within WYSIWYG fields that they have permission to edit.
To achieve stored XSS, one can:
- Edit a field that uses the WYSIWYG editor
- click the "source" button
- Enter the HTML macro {{html}}
- Enter HTML containing an XSS payload (see proof of concept below)
- Close the HTML macro with {{/html}}
- Click "Save and View"
Test proof-of concept:
{{html}}<img src=a onerror="javascript:prompt(1)"/>{{/html}}
This string displays a JavaScript prompt box with the number 1 in it, though could run malicious JavaScript inside the user's session in an attempt to perform actions as them or steal tokens.
When quickly checking, I could trigger this on
- User profile page - About and Address fields
- Blog page / blog summary
- Annotation (CTRL+M)
- The source editor for XWiki pages
- The FAQ page
- (There are no-doubt more that I didn't try)
Screenshot of executing payload attached. Let me know if you need more details or videos or if the above will suffice
Attachments
Issue Links
- depends on
-
XRENDERING-675 Add events to raw content filtering in macros
- Closed
- is duplicated by
-
XWIKI-18776 Stored Cross Site Scripting
- Closed
- is related to
-
XWIKI-9118 XSS in restricted context via html macro
- Closed
-
XWIKI-18049 Improve the html escaping mechanism for XSS protection
- Closed