CVE-2022-23064 (published 2022-05-02T13:15Z)

In Snipe-IT, versions v3.0-alpha to v5.3.7 are vulnerable to Host Header Injection. By sending a specially crafted host header in the reset password request, it is possible to send password reset links to users which once clicked lead to an attacker controlled server and thus leading to password reset token leak. This leads to account take over.

Severity: MEDIUM
CVSS v2 base score: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 8.8, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-74
cwe_name: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
description: The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.
extended_description: Software or other automated logic has certain assumptions about what constitutes data and control respectively. It is the lack of verification of these assumptions for user-controlled input that leads to injection problems. Injection problems encompass a wide variety of issues -- all mitigated in very different ways and usually attempted in order to alter the control flow of the process. For this reason, the most effective way to discuss these weaknesses is to note the distinct features that classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed.
         

Fix information:
repo_url: https://github.com/snipe/snipe-it
commit_details: repo_url: https://github.com/snipe/snipe-it
author: Brady Wetherington
author_date: 2022-01-18 15:31:30-08:00
msg: Force UrlGenerator's Root URL to be the base of APP_URL unless overriden
(For v5)
repository: repo_url: https://github.com/snipe/snipe-it
repo_name: snipe/snipe-it
description: A free open source IT asset/license management system
repo_language: PHP
owner: snipe
file_changes: filename: .env.example
change_type: ModificationType.MODIFY
diff: @@ -145,6 +145,7 @@ APP_LOG_MAX_FILES=10
 APP_LOCKED=false
 APP_CIPHER=AES-256-CBC
 APP_FORCE_TLS=false
+APP_ALLOW_INSECURE_HOSTS=false
 GOOGLE_MAPS_API=
 LDAP_MEM_LIM=500M
 LDAP_TIME_LIM=600

programming_language: Shell
filename: AppServiceProvider.php
change_type: ModificationType.MODIFY
diff: @@ -43,6 +43,14 @@ class AppServiceProvider extends ServiceProvider
                 \Log::warning("'APP_FORCE_TLS' is set to true, but 'APP_URL' does not start with 'https://'. Will not force TLS on connections.");
             }
         }
+
+        // TODO - isn't it somehow 'gauche' to check the environment directly; shouldn't we be using config() somehow?
+        if ( ! env('APP_ALLOW_INSECURE_HOSTS')) {  // unless you set APP_ALLOW_INSECURE_HOSTS, you should PROHIBIT forging domain parts of URL via Host: headers
+            $url_parts = parse_url(config('app.url'));
+            $root_url = $url_parts['scheme'].'://'.$url_parts['host'].( isset($url_parts['port']) ? ':'.$url_parts['port'] : '');
+            \URL::forceRootUrl($root_url);
+        }
+
         Schema::defaultStringLength(191);
         Asset::observe(AssetObserver::class);
         Accessory::observe(AccessoryObserver::class);

programming_language: PHP