#xss

### 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.

A missing permission check in Jenkins Fogbugz Plugin 2.2.17 and earlier allows attackers with Item/Read permission to trigger builds of jobs specified in a 'jobname' request parameter.

A missing permission check in Jenkins Quay.io trigger Plugin 0.1 and earlier allows unauthenticated attackers to trigger builds of jobs corresponding to the attacker-specified repository.

Jenkins Image Tag Parameter Plugin 2.0 improperly introduces an option to opt out of SSL/TLS certificate validation when connecting to Docker registries, resulting in job configurations using Image Tag Parameters that were created before 2.0 having SSL/TLS certificate validation disabled by default.

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

Jenkins Report Portal Plugin 0.5 and earlier does not mask ReportPortal access tokens displayed on the configuration form, increasing the potential for attackers to observe and capture them.