In Vendure versions 0.1.0-alpha.2 to 1.5.1 are affected by Stored XSS vulnerability, where an attacker having catalog permission can upload a SVG file that contains malicious JavaScript into the “Assets” tab. The uploaded file will affect administrators as well as regular users.

@@ -212,6 +212,7 @@ export class AssetServerPlugin implements NestModule, OnApplicationBootstrap {

mimeType \= (await fromBuffer(file))?.mime || 'application/octet-stream';

}

res.contentType(mimeType);

res.setHeader('content-security-policy', \`default-src 'self'\`);

res.send(file);

} catch (e) {

const err \= new Error('File not found');

@@ -251,6 +252,7 @@ export class AssetServerPlugin implements NestModule, OnApplicationBootstrap {

Logger.debug(\`Saved cached asset: ${cachedFileName}\`, loggerCtx);

}

res.set('Content-Type', \`image/${(await image.metadata()).format}\`);

res.setHeader('content-security-policy', \`default-src 'self'\`);

res.send(imageBuffer);

return;

} catch (e) {

CVE-2022-23065: fix(asset-server-plugin): Fix svg XSS vulnerability · vendure-ecommerce/vendure@69a4486

The RSS extension before 2022-04-29 for MediaWiki allows XSS via an rss element (if the feed is in $wgRSSUrlWhitelist and $wgRSSAllowLinkTag is true).

**

XSS in Extension:RSS when $wgRSSAllowLinkTag = true;

Closed, ResolvedPublicSecurity



**

*   Edit Task
*   Edit Related Tasks...
*   Edit Related Objects...

*   Mute Notifications
*   Protect as security issue
*   Award Token
*   Flag For Later

This is a WMF deployed extension, however $wgRSSAllowLinkTag is false on cluster, so it is not vulnerable in the configuration used by WMF.

RSS extension implementation of strip markers suffers from a similar problem as MW core's used to before T110143 was fixed. When $wgRSSAllowLinkTag is set to true, you can use this to escape from an attribute.

As an example:

*   Set $wgRSSAllowLinkTag = true;

Create an rss feed as follows:

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
        \>

<channel>
        <title>Test</title>
<item>
                <title>First item</title>
                <link>https://example.com</link>
                    
                                        <description><!\[CDATA\[<a title="tabindex=1 autofocus onmouseover=alert(1) onfocus=blur() onblur=alert(document.domain)//"> Should autotrigger on chrome, and trigger on hover on firefox</a> \]\]></description>
</item>
</channel>
</rss>

*   Be sure the above RSS feed is added to $wgRSSUrlWhitelist
*   Create a template named Template:RSS containing only

<div title="{{{description}}}"></div>

*   Use the following tag on a page <rss templatename=RSS>http://address.of.rss.feed.from.above</rss>

This should make an XSS that autotriggers on chrome, and triggers on hoover in firefox.

Best solution, is to probably copy what MW core does for strip markers with them including "'

Author Affiliation

Wikimedia Communities

*   Mentions

**Event Timeline**

Comment Actions

Its related to the custom strip marker scheme, i'm not sure if that's what is being referred to in the other task. The code path involved here is the one using the Sanitizer, not the one with a custom escaping function.

The actual escapeTemplateParameter isn't really a security boundry most of the time except when used with insertStripItem, since the results get parsed later in most cases.

Comment Actions

Proposed patch

Extension doesn't seem to have a maintainer to CC on this task. I assume I should not just throw on gerrit since its WMF deployed, even if this code path is not enabled on cluster.

Comment Actions

> Extension doesn't seem to have a maintainer to CC on this task. I assume I should not just throw on gerrit since its WMF deployed, even if this code path is not enabled on cluster.

Since ext:RSS isn't bundled, it would go out with the next supplemental release, which is tracked at T305209. I've added it there for now. Since this isn't currently vulnerable within Wikimedia production (and likely wouldn't ever be) I'd consider it low risk pushing it through gerrit. I think the only concern would be if other mediawiki operators were left uninformed or vulnerable for some time period, but IME we've tended not to care about that as much in the past and have just tried to merge security bug fixes quickly, make tasks public and send out the supplemental release each quarter, as best efforts.

Content licensed under Creative Commons Attribution-ShareAlike 3.0 (CC-BY-SA) unless otherwise noted; code licensed under GNU General Public License (GPL) or other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL

CVE-2022-29969: ⚓ T307028 XSS in Extension:RSS when $wgRSSAllowLinkTag = true;

A Dom-based Cross-site scripting (XSS) vulnerability at registration account in Cyclos 4 PRO.14.7 and before allows remote attackers to inject arbitrary web script or HTML via the groupId parameter.

Cách đây một năm, trong khi tham gia một chương trình Bug bounty ở Whitehub, target mà chương trình mình tham gia sử dụng một Banking Software có tên là Cyclos. Sau khi xem sơ lược các chức năng chính, mình nhận thấy tại chức năng đăng ký tài khoản khi giá trị tham số groupId không tồn tại thì xuất hiện thông báo lỗi đính kèm giá trị groupId mà ta nhập vào.

CVE-2021-31673: Cyclos 4.14.7 - Dom-based Cross-Site Scripting (CVE-2021-31673)

**Author:** Tin Pham aka TF1T of VietSunshine Cyber Security Services

**Vendor Homepage:** https://www.cyclos.org/

**Version:** Cyclos 4.14.7 (and prior)

**Description:** A Dom-based Cross-site scripting (XSS) vulnerability at registration account in Cyclos 4 PRO.14.7 and before allows remote attackers to inject arbitrary web script or HTML via the groupId parameter.

**Steps to reproduce:** An attacker sends a draft URL _\[IP\]/#users.users.public-registration!groupId=1%27%22%3E%3Cimg%20src=x%20onerror=alert(document.domain)%3E_ to victim. When a victim opens the URL, XSS will be triggered.

**

Thông tin bên lề về lỗ hổng

**

Cách đây một năm, trong khi tham gia một chương trình Bug bounty ở Whitehub, target mà chương trình mình tham gia sử dụng một Banking Software có tên là Cyclos. Sau khi xem sơ lược các chức năng chính, mình nhận thấy tại chức năng đăng ký tài khoản khi giá trị tham số groupId không tồn tại thì xuất hiện thông báo lỗi đính kèm giá trị groupId mà ta nhập vào.

Vì thông báo lỗi có đính kèm giá trị mà ta nhập vào, rất có thể vị trí này tồn tại lỗ hổng XSS. Kiểm tra bằng cách chèn payload: <img src=xxx onerror=alert(document.domain)> vào tham số **groupId**

Xác nhận lỗ hổng Dom-based XSS

Để tìm source và sink của các lỗ hổng Dom-based XSS, ta sẽ chèn debugger vào payload và debug trên trình duyệt Chrome, xem thanh Call Stack, ta tìm được source và sink như sau:

**source:** location.hash tại cyclos.gwt-0.js1

if (a == null || a.length == 0) {

**sink:** innerHTML tại cyclos.gwt-0.js1

Và sau 1 năm chờ đợi mình có đã CVE đầu tiên. Cảm ơn các bạn đã đọc bài viết.

Cyclos 4 PRO 4.14.7 and before does not validate user input at error inform, which allows remote unauthenticated attacker to execute javascript code via undefine enum constant.

Cyclos 4.14.7 - Dom-based Cross-Site Scripting in undefined enum (CVE-2021-31674)

**Exploit Author:** Tin Pham aka TF1T of VietSunshine Cyber Security Services

**Vendor Homepage:** https://www.cyclos.org/

**Affected Version(s):** Cyclos 4.14.7 (and prior)

**Description:** Cyclos 4 PRO 4.14.7 and before does not validate user input at error inform, which allows remote unauthenticated attacker to execute javascript code via undefined enum.

**Steps to reproduce:** An attacker sends a draft URL _\[IP\]/#users.users.public-registrationxxx%3Cimg%20src=x%20onerror=%22\[\]\['\\146\\151\\154\\164\\145\\162'\]\['\\143\\157\\156\\163\\164\\162\\165\\143\\164\\157\\162'\]('\\162\\145\\164\\165\\162\\156\\40\\164\\150\\151\\163')()\['\\141\\154\\145\\162\\164'\](1)%22%3E_ to victim. When a victim opens the URL, XSS will be triggered.

**

Note

**

Khi nhập vào một enum không tồn tại, thông báo lỗi sẽ xuất hiện kèm theo giá trị nhập vào, tuy nhiên các giá trị này sẽ đi qua function uppercase()

Như chúng ta đã biết nếu cụm alert() bị viết hoa (ALERT()) thì sẽ không có popup xảy ra

Do đó ta có thể sử dụng function alert() dạng JSFUCK rồi encode dạng octet để payload được ngắn lại. Final payload: <img src=x onerror="[]['\146\151\154\164\145\162']['\143\157\156\163\164\162\165\143\164\157\162']('\162\145\164\165\162\156\40\164\150\151\163')()['\141\154\145\162\164'](1)">

CVE-2021-31674: Cyclos 4.14.7 - Dom-based Cross-Site Scripting in undefined enum (CVE-2021-31674)

The package s-cart/s-cart before 6.9; the package s-cart/core before 6.9 are vulnerable to Cross-site Scripting (XSS) which can lead to cookie stealing of any victim that visits the affected URL so the attacker can gain unauthorized access to that user's account through the stolen cookie.

A cross-site scripting attack occurs when the attacker tricks a legitimate web-based application or site to accept a request as originating from a trusted source.

This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.

Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.

Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as &lt; and > can be coded as &gt; in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.

The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.

**Types of attacks**

There are a few methods by which XSS can be manipulated:

Type

Origin

Description

**Stored**

Server

The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link.

**Reflected**

Server

The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser.

**DOM-based**

Client

The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data.

**Mutated**

The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters.

**Affected environments**

The following environments are susceptible to an XSS attack:

*   Web servers
*   Application servers
*   Web application environments

**How to prevent**

This section describes the top best practices designed to specifically protect your code:

*   Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
*   Convert special characters such as ?, &, /, <, > and spaces to their respective HTML or URL encoded equivalents.
*   Give users the option to disable client-side scripts.
*   Redirect invalid requests.
*   Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
*   Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
*   Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.

CVE-2022-21149: Cross-site Scripting (XSS) in s-cart/core | CVE-2022-21149 | Snyk

All versions of package materialize-css are vulnerable to Cross-site Scripting (XSS) due to improper escape of user input (such as &lt;not-a-tag /&gt;) that is being parsed as HTML/JavaScript, and inserted into the Document Object Model (DOM). This vulnerability can be exploited when the user-input is provided to the autocomplete component.

CVE-2022-25349: Cross-site Scripting (XSS) in materialize-css | CVE-2022-25349 | Snyk

Cross-site Scripting (XSS) in GitHub repository livehelperchat/livehelperchat prior to 3.99v. Attacker can execute malicious javascript on application.

**An attacker can execute malicious javascript in Live Helper Chat**

Low severity GitHub Reviewed Published Apr 30, 2022 • Updated May 3, 2022

GHSA-9hgc-wpc5-v8p9: An attacker can execute malicious javascript in Live Helper Chat

A cross-site scripting (XSS) vulnerability exists in the "contact us" plugin for Subrion CMS <= 4.2.1 version via "List of subjects".

**Cross-site scripting (XSS) vulnerability exists in the "contact us" plugin for Subrion CMS**

Moderate severity GitHub Reviewed Published Apr 30, 2022 • Updated May 4, 2022

GHSA-jv64-2m3x-6v4q: Cross-site scripting (XSS) vulnerability exists in the "contact us" plugin for Subrion CMS

Woodpecker before 0.15.1 allows XSS via build logs because web/src/components/repo/build/BuildLog.vue lacks escaping.

**Woodpecker allows cross-site scripting (XSS) via build logs**

Moderate severity GitHub Reviewed Published Apr 30, 2022 • Updated May 3, 2022

Tag

#xss