#xss

Cross-site Scripting (XSS) - Generic in GitHub repository microweber/microweber prior to 1.3.3.

### Impact The [Livetable Macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/Livetable%20Macro) wasn't properly sanitizing column names, thus allowing the insertion of raw HTML code including JavaScript. This vulnerability was also exploitable via the [Documents Macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/Documents%20Macro) that is included since XWiki 3.5M1 and doesn't require script rights, this can be demonstrated with the syntax `{{documents id="example" count="5" actions="false" columns="doc.title, before<script>alert(1)</script>after"/}}`. Therefore, this can also be exploited by users without script right and in comments. With the interaction of a user with more rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content. ### Patches This has been patched in XWiki 14.9, 14.4.6, and 13.10.10. ### Workarounds It is possible to apply the...

### Impact There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights. ### Patches This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script right. ### Workarounds The only known workaround consists in applying [the following patch](https://github.com/xwiki/xwiki-platform/commit/fe65bc35d5672dd2505b7ac4ec42aec57d500fbb) and rebuilding and redeploying `xwiki-platform-skin-skinx`. ### References * https://jira.xwiki.org/browse/XWIKI-19514 * https://jira.xwiki.org/browse/XWIKI-9119 * https://jira.xwiki.org/browse/XWIKI-19583 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](http://jira.xwiki.org) * Email us at [Security ML](mailto:security@x...

### Impact The HTML macro does not systematically perform a proper neutralization of script-related html tags. As a result, any user able to use the html macro in XWiki, is able to introduce an XSS attack. This can be particularly dangerous since in a standard wiki, any user is able to use the html macro directly in their own user profile page. ### Patches The problem has been patched in XWiki 14.8RC1. The patch involve that the HTML macro are systematically cleaned up whenever the user does not have script right. ### Workarounds There's no workaround for this issue. ### References * https://jira.xwiki.org/browse/XWIKI-18568 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](https://jira.xwiki.org) * Email us at [security ML](mailto:[email protected])

### Impact The [RSS macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/RSS%20Macro) that is bundled in XWiki included the content of the feed items without any cleaning in the HTML output when the parameter `content` was set to `true`. This allowed arbitrary HTML and in particular also JavaScript injection and thus cross-site scripting (XSS) by specifying an RSS feed with malicious content. With the interaction of a user with programming rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content and sabotaging the wiki. The issue can be reproduced by inserting the following XWiki syntax in any wiki page like the user account: ``` {{rss feed="https://xssrss.blogspot.com/feeds/posts/default?alt=rss" content="true" /}} ``` If an alert is displayed when viewing the page, the wiki is vulnerable. ### Patches The issue has been patched in XWiki 14.6 RC1, the con...

### Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1, only escaped `<script>` and `<style>`-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like `<iframe>`. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). An example are anonymous comments in XWiki where the HTML macro filters HTML using restricted mode: ``` {{html}} <a href='' onclick='alert(1)'>XSS</a> {{/html}} ``` When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. ### Patches This problem has been patched in XWiki 14.6 RC1 with the introduction of a filter with allowed HTML elements and attributes th...

### Impact A user without script rights can introduce a stored XSS by using the Live Data macro, if the last author of the content of the page has script rights. For instance, by adding the LiveData below in the about section of the profile of a user created by an admin. ``` {{liveData id="movies" properties="title,description"}} { "data": { "count": 1, "entries": [ { "title": "Meet John Doe", "url": "https://www.imdb.com/title/tt0033891/", "description": "<img onerror='alert(1)' src='foo' />" } ] }, "meta": { "propertyDescriptors": [ { "id": "title", "name": "Title", "visible": true, "displayer": {"id": "link", "propertyHref": "url"} }, { "id": "description", "name": "Description", "visible": true, "displayer": "html" } ] } } {{/liveData}} ``` ### Patches This has been patched in XWiki 14.10, 14.4.7, and 13.10.11. ### Workarounds N...

### Impact It was possible to inject some code using the URL of authenticate endpoints, e.g.: ``` https://hostname/xwiki/authenticate/wiki/xwiki%22onload=%22alert(origin)%22/resetpassword ``` This vulnerability was present in recent versions of XWiki: - 13.10.8+ - 14.4.3+ - 14.6+ ### Patches This problem has been patched on XWiki 13.10.11, 14.4.7 and 14.10. ### Workarounds There is no easy workaround except to upgrade. ### References - https://jira.xwiki.org/browse/XWIKI-20335 - https://github.com/xwiki/xwiki-platform/commit/1943ea26c967ef868fb5f67c487d98d97cba0380 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](https://jira.xwiki.org) * Email us at [security mailing-list](mailto:[email protected])

Jenkins Quay.io trigger Plugin 0.1 and earlier does not limit URL schemes for repository homepage URLs submitted via Quay.io trigger webhooks. This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to submit crafted Quay.io trigger webhook payloads.

A missing permission check in Jenkins Thycotic Secret Server Plugin 1.0.2 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins.