BI Launchpad and CMC in SAP Business Objects Business Intelligence Platform, versions 4.1, 4.2, does not sufficiently encode user-controlled inputs, resulting in Cross-Site Scripting (XSS) vulnerability. Exploit is possible only when the bttoken in victim’s session is active.

CVE-2020-6220

LibreHealth EHR Base 2.0.0 allows gacl/admin/acl_admin.php acl_id XSS.

Tags give the ability to mark specific points in history as being important

CVE-2022-31493: Tags · LibreHealth / LibreHealth EHR / LibreHealth EHR Base · GitLab

A Denial of Service flaw was discovered in Elasticsearch. Using this vulnerability, an unauthenticated attacker could forcibly shut down an Elasticsearch node with a specifically formatted network request.

CVE-2022-23712: Security issues

A Stored Cross-Site Scripting vulnerability in Jira integration in GitLab EE affecting all versions from 13.11 prior to 14.9.5, 14.10 prior to 14.10.4, and 15.0 prior to 15.0.1 allows an attacker to execute arbitrary JavaScript code in GitLab on a victim's behalf via specially crafted Jira Issues

CVE-2022-1940

FUDforum 3.1.2 is vulnerable to Stored XSS via Forum Name field in Forum Manager Feature.

**What is XSS**  
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

Affected Version- 3.1.2

Demo installation: https://localhost/Fudforum-3.1.2/

**Reproduce bug:**  
Step 1 : Login with admin account and go to the Admin Control Panel.  
Step 2: In Categories & Forums, use Forum Manager to add new Forum to Private Forums.  
Step 3: Inject XSS payload to Forum Name field and complete Add Forum  
XSS payload : a<img src=x onerror=alert('xss')>  
Step 4: Go back to http://localhost/FUDforum-3.1.2/index.php  
Or Go to http://localhost/FUDforum-3.1.2/adm/admgroups.php?&SQ=1da883e1cc4e8df02d59bcf5fc8edf54  
\-> XSS bug trigger

**Impact of XSS:**

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.  
Initiate interactions with other application users, including malicious attacks, that will appear to originate from the initial victim user.  
With the help of XSS a hacker or attacker can perform social engineering on users by redirecting them from real website to fake one. hacker can steal their cookies and download a malware on their system, and there are many more attacking scenarios a skilled attacker can perform with xss.

CVE-2022-30861: Cross Site Scripting · Issue #24 · fudforum/FUDforum

FlatCore-CMS 2.0.9 has a cross-site scripting (XSS) vulnerability in pages.edit.php through meta tags and content sections.

**Describe the bug**  
Meta etiketlere ve içeriğe yazılan xss yükünü filtrelememek

https://owasp.org/www-community/attacks/xss/

**To Reproduce**  
Steps to reproduce the behavior:  
1-) press create new page from home page

2-) Enter the meta tags and content e xss payload

3-) go to admin panel and press go to home page button and xss pop-up

**Expected behavior**  
A clear and concise description of what you expected to happen.

**Screenshots**  
If applicable, add screenshots to help explain your problem.

**Additional context**  
POC : https://www.youtube.com/watch?v=wmQf0B3Sa6c

CVE-2021-42245: Create Page XSS · Issue #69 · flatCore/flatCore-CMS

FacturaScripts 2022.08 and prior is vulnerable to cross-site scripting. A patch is available on the `master` branch of the repository and anticipated to be part of version 2022.09.

**Cross-site Scripting in FacturaScripts**

Moderate severity GitHub Reviewed Published Jun 4, 2022 • Updated Jun 6, 2022

GHSA-r7jw-mg27-j839: Cross-site Scripting in FacturaScripts

XXL-Job v2.3.0 was discovered to contain a stored cross-site scripting (XSS) vulnerability via /xxl-job-admin/jobinfo.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2022-29770: There is a stored XSS vulnerability in the task management of xxl-job · Issue #2836 · xuxueli/xxl-job

Xecurify's miniOrange Premium, Standard, and Enterprise Drupal SAML SP modules possess an authentication and authorization bypass vulnerability. An attacker with access to a HTTP-request intercepting method is able to bypass authentication and authorization by removing the SAML Assertion Signature - impersonating existing users and existing roles, including administrative users/roles. This vulnerability is not mitigated by configuring the module to enforce signatures or certificate checks. Xecurify recommends updating miniOrange modules to their most recent versions. This vulnerability is present in paid versions of the miniOrange Drupal SAML SP product affecting Drupal 7, 8, and 9.

**arf-sec**

Personal Blog on Security Topics

Project maintained by rafarmerjr1 Hosted on GitHub Pages — Theme by mattgraham

**miniOrange Authentication Bypass via SAML Manipulation - CVE-2022-26493**

**Known Versions Affected**

Drupal 9

Drupal 8

Drupal 7

miniOrange Premium < 30.5

miniOrange Premium < 30.5

miniOrange Premium < 30.2

This vulnerability was discovered using Drupal 9.3.4 and 9.3.6, in miniOrange Premium versions 8.x-30.3 and 8.x-30.4. It has been confirmed to affect the Drupal SAML SP modules provided by miniOrange utilizing Okta. Other authentication schemas and content management systems may also be affected.

miniOrange Enterprise and Standard versions may be affected but were not tested. Xecurify has released patches for all variants of miniOrange since the discovery of this vulnerability: Standard, Premium, and Enterprise. It is advised to upgrade to the newest available version of miniOrange, regardless of free or paid subscription service, as it is possible this vulnerability is present in multiple product and release versions of the miniOrange Drupal SAML SP module.

This vulnerability has not been identified in the free versions of miniOrange.

**Vulnerability**

This module has an authentication and authorization bypass vulnerability. Any individual with access to a HTTP request intercepting method is able to bypass authentication and authorization - impersonating existing users and any existing role. All that is required is for the attacker to know (or guess) a valid username.

Due to the SAML SP module’s failure to verify _the existence_ of a signature, any applications using the affected versions of miniOrange are effectively without authentication or authorization controls. Enabling certificate or signature checking in affected versions of miniOrange will not mitigate the vulnerability.

**Explanation**

miniOrange versions 8.x-30.3 and 8.x-30.4 do not properly check for the existence of a valid signature in SAML authentication communications. Manipulating the contents of the SAML response from an Identity Provider (IDP) will affect the signature - rendering the SAML communication invalid. This occurs because the miniOrange SAML module can be configured to check the signature provided in SAML communications. If the signature displays indications of modification, the authentication request is denied.

However, removal of this signature will bypass the signature check entirely. As a result, an attacker may simply remove the signature in the SAML assertion from an IDP, modify the username and/or role, and forward the packet on to the web server. The web server will interpret this manipulated package as a valid communication from the IDP, and allow the attacker to access the application with whatever user account and role he chooses.

SAML (Security Assertion Markup Language) is an authentication standard that is used to transmit authentication data between two parties. In the case of this vulnerability - and in many authentication schemas - SAML allows a web application to be hosted indepently of the authorization service. SAML works by facilitating communcation between the web application servers and the authentication servers.

**Simple Example**

Let’s look at a simplified example:

A web application possesses a login button that redirects the user to an external authentication source. As the user is redirected, a token or session cookie is often attached to their request. The username and password provided by the user are never sent to the web application - but to the Identity Provider (IDP) authentication service. This service will validate the user’s credentials and - if present - conduct a two-factor authentication step. Once authenticated, the IDP will bundle up information about the user such as username, user role, status of authentication attempt (successful or failed) in a SAML Assertion response. This assertion is signed to validate that (a) the IDP and only the IDP generated the data and (b) that the integrity of the data has not been compromised.

This SAML Assertion is then forwarded from the IDP to the web application. The web application will read this response (and signature) to confirm that the authentication was successful, obtain the correct username for the user, and apply the correct user role.

In a functioning SAML schemas - any manipulation to the data in-trasit results in a small but significant change to the signature. The signature contained in the SAML response is compared with what the web application possesses. Any differences between the two will result in the authentication attempt failing. In the versions of MiniOrange discussed in this write-up, this functionality did not fail, and signature changes were correctly detected.

However, the versions of MiniOrange investigated did not properly check for **the existance** of the signature. If the signature was removed, the signature check failed open. This leaves the affected versions of MiniOrange vulnerable to SAML manipulation attacks. Furthermore, enabling signature checking and SAML signing makes no difference in the vulnerability.

**SAML Manipulation**

During the authentication process, an attacker can modify the contents of a SAML assertion to impersonate users or obtain unauthorized role access. This is accomplished by intercepting the SAML response from the IDP, modifying it in-transit, and forwarding it to the web application. In the vulnerability discussed here, **SAML replay attacks** were also possible. As such, once a single SAML Assertion is obtained by an attacker, whether through Man-In-The-Middle attacks, Cross-site Scripting, etc. - it can be reused repeatedly. If an attacker is able to intercept or obtain a SAML assertion for an application, the application authentication and authorization logic can be bypassed. During testing, credential checks and two-factor authentication were both bypassed. Likewise, I was able to assume any valid role within the application.

When modifying a SAML Assertion, we can capture the traffic in an HTTP Proxy like Burp Suite and view the SAML data. In order to bypass authentication in these versions of MiniOrange, an attacker only needs to know (or guess) an existing, valid username. This can be accomplished through fuzzing different common usernames such as WPAdmin, Admin, Drupal\_admin, or through directly targeting known usernames. Once identified in the SAML Assertion, the username only needs to be replaced with the targeted username.

SAML Assertions are encoded. Encoding is not encryption however, and it is trivial to decode. Once decoded, we can locate and modify the username. Here, I changed my user account to an admin account within the SAML Assertion:

If an attacker does not know or does not want to guess an existing username they can modify the user role. An existing user may be malicious or an attacker may have valid credentials and want to elevate their privileges. To demonstrate, I modified my user role to “Admin”:

After modifying the username and/or the user role, an attacker may remove the signature and forward the packet on to its final destination at the web application server. We will be met with a response like this one - indicating a successful authentication and a redirect to the webpage - now as an authenticated user:

**Discussion**

This authentication bypass was confirmed through testing to affect MiniOrange Premium versions 8.x-30.3 and 8.x-30.4. The vulnerability was disclosed to the vendor and to the Drupal security team on March 1st, 2022. The MiniOrange team at Xecurify released a patch the same week. Their disclosure statement can be found here.

A similar vulnerability was discovered by another researcher - Cristian Guistini - in late 2021. The vulnerability disclosed by Guistini affected the free version of MiniOrange, version 8.x.2.22, which was available through the Drupal plugin marketplace. His write-up can be found here. This vulnerability was assigned SA-CONTRIB-2021-036 by Drupal, as the affected software was available for download through Drupal.

The bug Guistini discovered was identified to be related to poor enforcement of x509 Certificate values and SAML assertion signatures. Unfortunately, in the vulnerability I disclosed in early March and discuss here - the selection of these options makes no difference. The signature existence check is bypassed regardless of user configuration in the premium versions of MiniOrange noted here.

The Premium, Standard, and Enterprise versions of MiniOrange are only available for download from Xecurity for paying customers. The vulnerability described in this write-up was not assigned a Drupal Security Advisory, as it is only available through Xecurify, and not through the Drupal marketplace.

Xecurify advises users to update to at least the following versions:

Drupal 9

Drupal 8

Drupal 7

MiniOrange Standard 20.3

MiniOrange Standard 20.3

MiniOrange Standard 20.2

MiniOrange Premium 30.5

MiniOrange Premium 30.5

MiniOrange Premium 30.2

MiniOrange Enterprise 40.4

MiniOrange Enterprise 40.4

MiniOrange Enterprise 40.2

According to Xecurify’s advisory:

“If you are using an out-dated/vulnerable version of the SAML SP module, you can download the latest version by signing in to your miniOrange dashboard using the registered credentials”.

CVE-2022-26493: Auth Bypass via SAML Attacks

Contao version 4.13.2 suffers from a cross site scripting vulnerability.

    # Exploit Title: Contao 4.13.2 - Cross-Site Scripting (XSS)# Google Dork: NA# Date: 04/28/2022# Exploit Author: Chetanya Sharma @AggressiveUser# Vendor Homepage: https://contao.org/en/# Software Link: https://github.com/contao/contao/releases/tag/4.13.2# Version: [ 4.13.2 ] # Tested on: [KALI OS]# CVE : CVE-2022-1588# References: - https://huntr.dev/bounties/df46e285-1b7f-403c-8f6c-8819e42deb80/- https://github.com/contao/contao/security/advisories/GHSA-m8x6-6r63-qvj2- https://contao.org/en/security-advisories/cross-site-scripting-via-canonical-url.html---------------Steps to reproduce:Navigate to the below URLURL: https://localhost/contao/"><svg//onload=alert(112233)>

Tag

#xss