#xss

Think payment iframes are secure by design? Think again. Sophisticated attackers have quietly evolved malicious overlay techniques to exploit checkout pages and steal credit card data by bypassing the very security policies designed to stop them. Download the complete iframe security guide here.  TL;DR: iframe Security Exposed Payment iframes are being actively exploited by attackers using

A stored cross-site scripting (XSS) vulnerability in the Admin Log Viewer of S-Cart <=10.0.3 allows a remote authenticated attacker to inject arbitrary web script or HTML via a crafted User-Agent header. The script is executed in an administrator's browser when they view the security log page, which could lead to session hijacking or other malicious actions.

An authenticated stored cross-site scripting (XSS) vulnerability exists in multiple WSO2 products due to improper validation of user-supplied input during API document upload in the Publisher portal. A user with publisher privileges can upload a crafted API document containing malicious JavaScript, which is later rendered in the browser when accessed by other users. A successful attack could result in redirection to malicious websites, unauthorized UI modifications, or exfiltration of browser-accessible data. However, session-related sensitive cookies are protected by the httpOnly flag, preventing session hijacking.

# Summary A reflected cross-site scripting (XSS) vulnerability exists under certain conditions, using a specially crafter url to view a user profile # Description DNN’s URL/path handling and template rendering can allow specially crafted input to be reflected into a user profile that are returned to the browser. In these cases, the application does not sufficiently neutralize or encode characters that are meaningful in HTML, so an attacker can cause a victim’s browser to interpret attacker-controlled content as part of the page’s HTML.

# Summary Users that can edit modules could set a title that includes scripts. # Description Some users (administrators and content editors) can set html in module titles and that could include javascript which could be used for XSS based attacks. With the addition of more roles being able to set module titles, this is not strictly limited to administrators. However since HTML in module titles could be a valid use case, we have added a setting for this functionality in the Security module in the Persona Bar.

# Summary The Prompt module allows execution of commands that can return raw HTML. Malicious input, even if sanitized for display elsewhere, can be executed when processed through certain commands, leading to potential script execution (XSS). # Description The application sanitizes most user-submitted data before displaying it in entry forms. However, the Prompt module is capable of running commands whose output is treated as HTML. This creates a vulnerability where a malicious user can craft input containing embedded scripts or harmful markup. If such malicious content is later processed by a Prompt command and returned as HTML, it bypasses the standard sanitation mechanisms. Simply executing a specific command through the Prompt module could render this untrusted data and cause unintended script execution in the browser specially in the context of a super-user.

## Summary Users can use special syntax to inject javascript code in their profile biography field. Although there was sanitization in place, it did not cover all possible scenarios ## Description When embedding information in the `Biography` field, even if that field is not rich-text, users could inject javascript code that would run in the context of the website and to any other user that can view the profile including administrators and/or superusers.

### Summary The lack of sanitization of URLs protocols in the `createLink.openLink` function enables the execution of arbitrary JavaScript code within the context of the parent page. ### Details https://github.com/FrontFin/mesh-web-sdk/blob/cf013b85ab95d64c63cbe46d6cb14695474924e7/packages/link/src/Link.ts#L441 The `createLink.openLink` function takes base64 encoded links, decodes them, and then sets the resulting string as the `src` attribute of an `iframe`. It’s important to note that the protocol part is not validated, so a payload, which is a valid URL, such as `javascript:alert(document.domain)//`, can be provided to the function. ### PoC 1. Extract [poc-mesh-web-sdk.zip](https://github.com/user-attachments/files/22223079/poc-mesh-web-sdk.zip) 2. Run `yarn install` and then `yarn start` 3. Paste this payload inside the input box: `amF2YXNjcmlwdDphbGVydCh3aW5kb3cucGFyZW50LmRvY3VtZW50LmJvZHkuZ2V0RWxlbWVudHNCeVRhZ05hbWUoImgyIikuaXRlbSgwKVsiaW5uZXJIVE1MIl0pLy8=` 4. Click on the _Ope...

Stored cross-site scripting (XSS) vulnerability in the notifications widget in Liferay Portal 7.4.0 through 7.4.3.112, and Liferay DXP 2023.Q4.0 through 2023.Q4.8, 2023.Q3.1 through 2023.Q3.10, and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a publication’s “Name” text field.

Affected versions of this crate did not correctly strip namespace-incompatible tags in certain situations, causing it to incorrectly account for differences between HTML, SVG, and MathML. This vulnerability only has an effect when the `svg` or `math` tag is allowed, because it relies on a tag being parsed as html during the cleaning process, but serialized in a way that causes in to be parsed as xml by the browser. Additionally, the application using this library must allow a tag that is parsed as raw text in HTML. These [elements] are: * title * textarea * xmp * iframe * noembed * noframes * plaintext * noscript * style * script Applications that do not explicitly allow any of these tags should not be affected, since none are allowed by default. [elements]: https://github.com/servo/html5ever/blob/57eb334c0ffccc6f88d563419f0fbeef6ff5741c/html5ever/src/tree_builder/rules.rs