An issue in the component SuperUserSetuserModuleFrontController:init() of idnovate superuser before v2.4.2 allows attackers to bypass authentication via a crafted HTTP call.

**IMPORTANT NOTICE**: DO NOT REPORT VULNERABILITIES SOLELY TO THE AUTHOR OR MARKETPLACE.

We urge you to report any vulnerabilities directly to us. Our mission is to ensure the safety and security of the PrestaShop ecosystem. Unfortunately, many module developers may not always recognize or acknowledge the vulnerabilities in their code, whether due to lack of awareness, or inability to properly evaluate the associated risk, or other reasons.

Given the rise in professional cybercrime networks actively seeking out these vulnerabilities, it's crucial that any potential threats are promptly addressed and the community is informed. The most effective method to do this is by publishing a CVE, like the one provided below.

Should you discover any vulnerabilities, **please report them to us at: report\[@\]security-presta.org** or visit https://security-presta.org for more information.

Every vulnerability report helps make the community more secure, and we are profoundly grateful for any information shared with us.

The module “idnovate” for PrestaShop incorrectly restricts access to the “connect as” feature from >= 2.3.5 and < 2.4.2 lets an attacker connect as any customer account. Release 2.4.2 fixed this security issue.

**Summary**

*   **CVE ID**: CVE-2023-45899
*   **Published at**: 2023-10-26
*   **Advisory source**: Friends-Of-Presta.org
*   **Platform**: PrestaShop
*   **Product**: superuser
*   **Impacted release**: >= 2.3.5 and < 2.4.2 (2.4.2 fixed issue)
*   **Product author**: idnovate
*   **Weakness**: CWE-305 CWE-639
*   **Severity**: high (7.5)

**Description**

Before 2.4.2, an incorrect restriction of authentication SuperUserSetuserModuleFrontController:init() could be executed with a trivial http call and exploited to be connected as a customer.

**CVSS base metrics**

*   **Attack vector**: network
*   **Attack complexity**: low
*   **Privilege required**: none
*   **User interaction**: none
*   **Scope**: unchanged
*   **Confidentiality**: high
*   **Integrity**: none
*   **Availability**: none

**Vector string**: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

**Possible malicious usage**

*   Personal data leaks
*   Obtain customer access and potentially registered payment methods (if save credit cards enabled on a payment module)

**Patch**

    --- 2.4.1/modules/superuser/controllers/front/setuser.php
    +++ 2.4.2/modules/superuser/controllers/front/setuser.php
    @@ -31,16 +31,23 @@ class SuperUserSetuserModuleFrontControl
                     case 'getPw':
                         if (Tools::getValue('id')) {
                             $customer = new Customer((int)Tools::getValue('id'));
    +                        $superuser_shop = $customer->id_shop;
    +                        if (!$this->isBoLogged($superuser_shop)) {
    +                            die('[SUPERUSER]Not BO logged.');
    +                        }
    +                        if (Shop::isFeatureActive()) {
    +                            $superuser_shop = Tools::getValue('shop');
    +                        }
                             $params = array(
                                 'id_customer' => $customer->id,
                                 'secure_key' => $customer->passwd,
    -                            'superuser_shop' => $customer->id_shop,
    +                            'superuser_shop' => $superuser_shop,
                                 'use_last_cart' => '1',
                                 'superuser_token' => Tools::encrypt($customer->id.$customer->passwd),
                                 'time' => date('dmYhis')
                             );
                             $link = new Link();
    -                        $controller_superuser = version_compare(_PS_VERSION_, '1.5', '<') ? (Configuration::get('PS_SSL_ENABLED') ? 'https://' : 'http://').$_SERVER['HTTP_HOST'].__PS_BASE_URI__.'modules/superuser/setuser.php?'.http_build_query($params) : $this->context->link->getModuleLink('superuser', 'setuser', $params, true, null, $customer->id_shop);
    +                        $controller_superuser = version_compare(_PS_VERSION_, '1.5', '<') ? (Configuration::get('PS_SSL_ENABLED') ? 'https://' : 'http://').$_SERVER['HTTP_HOST'].__PS_BASE_URI__.'modules/superuser/setuser.php?'.http_build_query($params) : $this->context->link->getModuleLink('superuser', 'setuser', $params, true, null, $superuser_shop);
                             die($controller_superuser);
                         }
                         break;
    @@ -63,6 +70,10 @@ class SuperUserSetuserModuleFrontControl
                 $id_customer = $order->id_customer;
             }
             $customer = new Customer((int)$id_customer);
    +        $selected_customer_shop = new Shop((int)$customer->id_shop);
    +        if (!$this->isBoLogged($superuser_shop)) {
    +            Tools::redirect(_PS_BASE_URL_.__PS_BASE_URI__);
    +        }
             $customer_secure_key = $customer->passwd;
             if (Tools::getValue('superuser_shop')) {
                 $shop = new Shop((int)Tools::getValue('superuser_shop'));
    

**Other recommandations**

*   It’s recommended to upgrade to the latest version of the module **superuser**.

**Timeline**

Date

Action

2022-10-11

Vulnerability found during a audit by 202 ecommerce

2023-10-12

The author confirms the vulnerability

2023-10-13

The author publishes the release 2.4.2

2023-10-09

Request a CVE ID

2023-10-25

Publication of this advisory

**Links**

*   Author product page
*   National Vulnerability Database

**DISCLAIMER:** _The French Association Friends Of Presta (FOP) acts as an intermediary to help hosting this advisory. While we strive to ensure the information and advice provided are accurate, FOP cannot be held liable for any consequences arising from reported vulnerabilities or any subsequent actions taken._

CVE-2023-45899: [CVE-2023-45899] Improper Access Control in the superuser module edited by idnovate for PrestaShop

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.1.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

CVE-2023-5864: fix: added missing conversion to HTML entities · thorsten/phpMyFAQ@b3e5a05

Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

CVE-2023-5863

Cross-site Scripting (XSS) - Stored in GitHub repository microweber/microweber prior to 2.0.

@@ -1,18 +1,17 @@ <?php  
namespace MicroweberPackages\\Customer\\tests;  
use MicroweberPackages\\Core\\tests\\TestCase; use MicroweberPackages\\Checkout\\CheckoutManager; use MicroweberPackages\\Core\\tests\\TestCase; use MicroweberPackages\\Customer\\Models\\Address; use MicroweberPackages\\Customer\\Models\\Customer; use MicroweberPackages\\Utils\\Mail\\MailSender;  
/\*\* \* Run test \* @author Bobi Microweber \* @command php phpunit.phar --filter CheckoutTest \*/  
class CustomerCheckoutTest extends TestCase { public static $content\_id = 1; Expand All @@ -37,7 +36,7 @@ private function \_addProductToCart($title)  
$saved\_id = save\_content($params); $prices\_data = app()->shop\_manager\->get\_product\_prices($saved\_id, false); $this\->assertEquals($prices\_data\['Price'\],$productPrice); $this\->assertEquals($prices\_data\['Price'\], $productPrice);  
  
$get = get\_content\_by\_id($saved\_id); Expand All @@ -50,7 +49,7 @@ private function \_addProductToCart($title) 'price' => $productPrice, ); $cart\_add = update\_cart($add\_to\_cart);  
$this\->assertEquals(isset($cart\_add\['success'\]), true); $this\->assertEquals(isset($cart\_add\['product'\]), true); $this\->assertEquals($cart\_add\['product'\]\['price'\], $productPrice); Expand All @@ -59,7 +58,7 @@ private function \_addProductToCart($title) public function testCheckout() {  
\\Config::set('mail.transport', 'array'); \\Config::set('mail.transport', 'array');  
$this\->\_addProductToCart('Product 1'); $this\->\_addProductToCart('Product 2'); Expand Down Expand Up @@ -109,7 +108,54 @@ public function testCheckout() $this\->assertEquals($address\->state, $checkoutDetails\['state'\]);  
  
  
}  
public function testCheckoutCustomerWithXss() {  
$this\->\_addProductToCart('Product 1'); $this\->\_addProductToCart('Product 2'); $this\->\_addProductToCart('Product 3'); $this\->\_addProductToCart('Product 4'); $xss = '<style>@keyframes x{}</style><xss style="animation-name:x" onanimationend="alert(document.cookie)"></xss>'; $checkoutDetails = array(); $checkoutDetails\['email'\] = 'client\_' . uniqid() . '@microweber.com'; $checkoutDetails\['first\_name'\] = 'Client First Name<script>alert(1)</script>' . $xss; $checkoutDetails\['last\_name'\] = 'Microweber Last Name' . $xss; $checkoutDetails\['phone'\] = '08812345' . rand(100, 999) . $xss; $checkoutDetails\['address'\] = 'Business Park, Mladost 4' . $xss; $checkoutDetails\['address2'\] = 'Business Park, Mladost 6' . $xss; $checkoutDetails\['city'\] = 'Sofia' . $xss; $checkoutDetails\['state'\] = 'Sofia City' . $xss; $checkoutDetails\['country'\] = 'Bulgaria' . $xss; $checkoutDetails\['zip'\] = '1000' . $xss;  
  
$checkout = new CheckoutManager(); $checkoutStatus = $checkout\->checkout($checkoutDetails);  
$this\->assertArrayHasKey('success', $checkoutStatus); $this\->assertArrayHasKey('id', $checkoutStatus);  
  
// Find customer $customer = Customer::where('email', $checkoutDetails\['email'\])->first();  
$this\->assertEquals($customer\->email, $checkoutDetails\['email'\]); $this\->assertNotEquals($customer\->first\_name, $checkoutDetails\['first\_name'\]); $this\->assertNotEquals($customer\->last\_name, $checkoutDetails\['last\_name'\]); $this\->assertNotEquals($customer\->phone, $checkoutDetails\['phone'\]);  
// Find customer $address = Address::where('customer\_id', $customer\->id)->first();  
$this\->assertNotEquals($address\->phone, $checkoutDetails\['phone'\]); $this\->assertNotEquals($address\->address\_street\_1, $checkoutDetails\['address'\]); $this\->assertNotEquals($address\->address\_street\_2, $checkoutDetails\['address2'\]); $this\->assertNotEquals($address\->city, $checkoutDetails\['city'\]); $this\->assertNotEquals($address\->zip, $checkoutDetails\['zip'\]); $this\->assertNotEquals($address\->state, $checkoutDetails\['state'\]);  
  
} }

CVE-2023-5861: update · microweber/microweber@6ed7ebf

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.2.1.

CVE-2023-5866

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

CVE-2023-5867

Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

CVE-2023-5865

Cross Site Request Forgery (CSRF) vulnerability in DouHaocms v.3.3 allows a remote attacker to execute arbitrary code via the adminAction.class.php file.

CVE-2023-42323: douhaocms/README.md at main · mnbvcxz131421/douhaocms

FlyteAdmin is the control plane for Flyte responsible for managing entities and administering workflow executions. Prior to version 1.1.124, list endpoints on FlyteAdmin have a SQL vulnerability where a malicious user can send a REST request with custom SQL statements as list filters. The attacker needs to have access to the FlyteAdmin installation, typically either behind a VPN or authentication. Version 1.1.124 contains a patch for this issue.

**Contributor(s):** kingthorin  

**Overview**

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to affect the execution of predefined SQL commands.

**Threat Modeling**

*   SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all data on the system, destroy the data or make it otherwise unavailable, and become administrators of the database server.
*   SQL Injection is very common with PHP and ASP applications due to the prevalence of older functional interfaces. Due to the nature of programmatic interfaces available, J2EE and ASP.NET applications are less likely to have easily exploited SQL injections.
*   The severity of SQL Injection attacks is limited by the attacker’s skill and imagination, and to a lesser extent, defense in depth countermeasures, such as low privilege connections to the database server and so on. In general, consider SQL Injection a high impact severity.

**How to Avoid SQL Injection Vulnerabilities**

See the OWASP SQL Injection Prevention Cheat Sheet. See the OWASP Query Parameterization Cheat Sheet.

**How to Review Code for SQL Injection Vulnerabilities**

See the OWASP Code Review Guide article on how to Review Code for SQL Injection vulnerabilities.

**How to Test for SQL Injection Vulnerabilities**

See the OWASP Testing Guide for information on testing for SQL Injection vulnerabilities.

**How to Bypass Web Application Firewalls with SQLi**

See the OWASP Article on using SQL Injection to bypass a WAF

**Description**

SQL injection attack occurs when:

1.  An unintended data enters a program from an untrusted source.
2.  The data is used to dynamically construct a SQL query

The main consequences are:

*   **Confidentiality**: Since SQL databases generally hold sensitive data, loss of confidentiality is a frequent problem with SQL Injection vulnerabilities.
*   **Authentication**: If poor SQL commands are used to check user names and passwords, it may be possible to connect to a system as another user with no previous knowledge of the password.
*   **Authorization**: If authorization information is held in a SQL database, it may be possible to change this information through the successful exploitation of a SQL Injection vulnerability.
*   **Integrity**: Just as it may be possible to read sensitive information, it is also possible to make changes or even delete this information with a SQL Injection attack.

**Risk Factors**

The platform affected can be:

*   Language: SQL
*   Platform: Any (requires interaction with a SQL database)

SQL Injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.

Essentially, the attack is accomplished by placing a meta character into data input to then place SQL commands in the control plane, which did not exist there before. This flaw depends on the fact that SQL makes no real distinction between the control and data planes.

**Examples****Example 1**

In SQL: select id, firstname, lastname from authors

If one provided: Firstname: evil'ex and Lastname: Newman

the query string becomes:

select id, firstname, lastname from authors where firstname = 'evil'ex' and lastname ='newman'

which the database attempts to run as:

Incorrect syntax near il' as the database tried to execute evil.

A safe version of the above SQL statement could be coded in Java as:

    String firstname = req.getParameter("firstname");
    String lastname = req.getParameter("lastname");
    // FIXME: do your own validation to detect attacks
    String query = "SELECT id, firstname, lastname FROM authors WHERE firstname = ? and lastname = ?";
    PreparedStatement pstmt = connection.prepareStatement( query );
    pstmt.setString( 1, firstname );
    pstmt.setString( 2, lastname );
    try
    {
        ResultSet results = pstmt.execute( );
    }
    

**Example 2**

The following C# code dynamically constructs and executes a SQL query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

    ...
    string userName = ctx.getAuthenticatedUserName();
    string query = "SELECT * FROM items WHERE owner = '"
                    + userName + "' AND itemname = '"
                    + ItemName.Text + "'";
    sda = new SqlDataAdapter(query, conn);
    DataTable dt = new DataTable();
    sda.Fill(dt);
    ...
    

The query that this code intends to execute follows:

    SELECT * FROM items
    WHERE owner =
    AND itemname = ;
    

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR
'a'='a" for itemName, then the query becomes the following:

    SELECT * FROM items
    WHERE owner = 'wiley'
    AND itemname = 'name' OR 'a'='a';
    

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query only return items owned by the authenticated user; the query now returns all entries stored in the items table, regardless of their specified owner.

**Example 3**

This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name hacker enters the string "name'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:

    SELECT * FROM items
    WHERE owner = 'hacker'
    AND itemname = 'name';
    
    DELETE FROM items;
    
    --'
    

Many database servers, including Microsoft® SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error in Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, in databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed. In this case the comment character serves to remove the trailing single-quote left over from the modified query. In a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT \* FROM items WHERE 'a'='a", the following three valid statements will be created:

    SELECT * FROM items
    WHERE owner = 'hacker'
    AND itemname = 'name';
    
    DELETE FROM items;
    
    SELECT * FROM items WHERE 'a'='a';
    

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a deny list of potentially malicious values. An allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, deny listing is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers can:

*   Target fields that are not quoted
*   Find ways to bypass the need for certain escaped meta-characters
*   Use stored procedures to hide the injected meta-characters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. For example, the following PL/SQL procedure is vulnerable to the same SQL injection attack shown in the first example.

    procedure get_item (
        itm_cv IN OUT ItmCurTyp,
        usr in varchar2,
        itm in varchar2)
    is
        open itm_cv for ' SELECT * FROM items WHERE ' ||
                'owner = '''|| usr ||
                ' AND itemname = ''' || itm || '''';
    end get_item;
    

Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

*   SQL Injection Bypassing WAF
*   Blind SQL Injection
*   Code Injection
*   Double Encoding
*   ORM Injection

**References**

*   SQL Injection Knowledge Base - A reference guide for MySQL, MSSQL and Oracle SQL Injection attacks.
*   GreenSQL Open Source SQL Injection Filter - An Open Source database firewall used to protect databases from SQL injection attacks.
*   An Introduction to SQL Injection Attacks for Oracle Developers
    *   This also includes recommended defenses.

Category:Injection

CVE-2023-41891: SQL Injection | OWASP Foundation

baserCMS is a website development framework. Prior to version 4.8.0, there is a cross-site scripting vulnerability in the file upload feature of baserCMS. Version 4.8.0 contains a patch for this issue.

Expand Up

@@ -36,7 +36,7 @@

<?php if ($uploaderCategories): ?>

<?php echo $this\->BcForm\->input('UploaderFile.uploader\_category\_id', \['type' => 'select', 'options' => $uploaderCategories, 'empty' => \_\_d('baser', 'カテゴリ指定なし'), 'id' => 'UploaderFileUploaderCategoryId' . $listId, 'style' => 'width:100px'\]) ?>&nbsp;

<?php endif ?>

<span id\="SpanUploadFile<?php echo $listId ?>"\>

<span id\="SpanUploadFile<?php echo h($listId) ?>"\>

<?php echo $this\->BcForm\->input('UploaderFile.file', \['type' => 'file', 'id' => 'UploaderFileFile' . $listId, 'class' => 'uploader-file-file', 'div' => false\]) ?>

</span\>

</div\>

Expand All

@@ -58,7 +58,7 @@

<?php if ($uploaderCategories): ?>

<?php echo $this\->BcForm\->input('UploaderFile.uploader\_category\_id', \['type' => 'select', 'options' => $uploaderCategories, 'empty' => \_\_d('baser', 'カテゴリ指定なし'), 'id' => 'UploaderFileUploaderCategoryId' . $listId\]) ?>

<?php endif ?>

<span id\="SpanUploadFile<?php echo $listId ?>"\>

<span id\="SpanUploadFile<?php echo h($listId) ?>"\>

<?php echo $this\->BcForm\->input('UploaderFile.file', \['type' => 'file', 'id' => 'UploaderFileFile' . $listId, 'class' => 'uploader-file-file', 'div' => false\]) ?>

</span\>

</div\>

Expand Down

Tag

#php