Patch de sécurité Magento SUPEE-6482, Qu'est-ce qui est patché?

Aujourd'hui 04.08.2015, un nouveau correctif de sécurité a été publié, certains collègues et moi vérifions le correctif, et il est toujours agréable d'avoir une discussion sur ce qui a changé, est-ce que quelqu'un sait quelles sont les attaques possibles qui pourraient affecter la boutique non corrigée? Quel est le pire qui pourrait arriver?

Mise à jour: je voulais juste ajouter l'e-mail que magento a envoyé aujourd'hui pour terminer la publication.

Le correctif de sécurité réel ( SUPEE-6482 ) affecte uniquement les deux fichiers suivants et est un correctif API.

app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
app/code/core/Mage/Catalog/Model/Product/Api/V2.php

L'installation complète de 1.9.2.1 est une toute autre affaire. Je différencierais le code source entre 1.9.2.0 et 1.9.2.1 pour comprendre les deux autres éléments qui ont été corrigés.

Les notes de version sont destinées au programme d'installation complet, vous devez vérifier le correctif pour voir s'il comprend réellement tous les éléments notés dans les notes de version.

Implications de l'exécution d'un serveur non corrigé:

1. Script intersite utilisant des en-têtes non validés => Empoisonnement du cache
2. Inclusion de fichiers chargés automatiquement dans l'API SOAP de Magento => Chargement automatique de code à distance
3. XSS dans Gift Registry Search => Vol de cookie et usurpation d'identité de l'utilisateur
4. Vulnérabilité SSRF dans le fichier WSDL => Fuite d'informations sur le serveur interne et inclusion de fichiers distants

REMARQUE: Fichiers corrigés dans l'archive d'installation complète qui ne sont pas corrigés avec le correctif, hmm?

diff -r magento-1920/app/code/core/Mage/Core/Controller/Request/Http.php magento-1921/app/code/core/Mage/Core/Controller/Request/Http.php
300a301
>         $host = $_SERVER['HTTP_HOST'];
302,303c303,304
<             $host = explode(':', $_SERVER['HTTP_HOST']);
<             return $host[0];
---
>             $hostParts = explode(':', $_SERVER['HTTP_HOST']);
>             $host =  $hostParts[0];
305c306,313
<         return $_SERVER['HTTP_HOST'];
---
> 
>         if (strpos($host, ',') !== false || strpos($host, ';') !== false) {
>             $response = new Zend_Controller_Response_Http();
>             $response->setHttpResponseCode(400)->sendHeaders();
>             exit();
>         }
> 
>         return $host;

diff -r magento-1920/app/design/frontend/base/default/template/page/js/cookie.phtml magento-1921/app/design/frontend/base/default/template/page/js/cookie.phtml
37,38c37,38
< Mage.Cookies.path     = '<?php echo $this->getPath()?>';
< Mage.Cookies.domain   = '<?php echo $this->getDomain()?>';
---
> Mage.Cookies.path     = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getPath()) ?>';
> Mage.Cookies.domain   = '<?php echo Mage::helper('core')->jsQuoteEscape($this->getDomain()) ?>';

Je tiens à regarder les changements en détail et les effets secondaires à prévoir.

Dans la version pour EE 1.13.1.0, les fichiers suivants ont changé:

2015-08-05 07:14:25 UTC | SUPEE-6482_EE_1.13.1.0 | EE_1.13.1.0 | v2 | 7e38036f94f250514fcc11d066a43c9bdb6a3723 | Tue Jul 28 14:29:35 2015 +0300 | v1.13.1.0..HEAD
patching file app/code/core/Enterprise/PageCache/Model/Processor.php
patching file app/code/core/Mage/Api/Model/Server/Adapter/Soap.php
patching file app/code/core/Mage/Catalog/Model/Product/Api/V2.php
patching file app/code/core/Mage/Core/Controller/Request/Http.php
Hunk #1 succeeded at 294 (offset 7 lines).
patching file app/design/frontend/base/default/template/page/js/cookie.phtml
patching file app/design/frontend/enterprise/default/template/giftregistry/search/form.phtml

• Dans Adapter/Soap.php, le codage url est ajouté aux données d'authentification. Cela ne devrait avoir aucun effet secondaire négatif. Il garantit que le résultat wsdlUrlest valide. Sans ce changement, on pourrait influencer l'URL
• Product/Api/V2.php: Voici quelques vérifications si les données transmises sont un objet. Cela ne devrait pas se produire dans des circonstances normales.
• dans Request/Http.phpet PageCache/Model/Processor.phpun chèque est ajouté lors de l' obtention de l'ORGANISATEUR HTTP. Cela semble couvrir les injections d'en-tête mentionnées. La vérification ne s'applique que s'il y a un ;ou ,dans l'hôte HTTP, donc cela ne devrait pas être critique dans les systèmes réels / sans effet secondaire négatif.
• dans l' cookie.phtmléchappement est ajouté. Donc, cela doit être transféré vers votre thème si vous écrasez ce fichier
• similaire pour giftregistry/search/form.phtml

Pour résumer, je dirais que l'application du patch ne devrait pas avoir d'effets secondaires négatifs. N'oubliez pas de transmettre les modifications à vos .phtmlfichiers.

Chose étrange, le patch EE contient des modifications sur les fichiers suivants:

app/code/core/Mage/Core/Controller/Request/Http.php
app/design/frontend/base/default/template/page/js/cookie.phtml

Quand ce n'est pas le cas pour une version équivalente.

Je suppose qu'il manque quelque chose sur cette SUPEE-6482version CE, et une V2 pourrait bientôt sortir.

Correctif de publication de Magento SUPEE-6482 pour corriger le problème ci-dessous dans l'édition CE et EE

Pour Magento Community Edition:

• Inclusion de fichiers chargés automatiquement dans l'API SOAP de Magento
• Vulnérabilité SSRF dans le fichier WSDL

Pour Magento Enterprise Edition

• Inclusion de fichiers chargés automatiquement dans l'API SOAP de Magento
• Vulnérabilité SSRF dans le fichier WSDL
• Script intersite utilisant des en-têtes non validés

XSS dans la recherche du registre des cadeaux

Faire du changement en classe

• Mage_Api_Model_Server_Adapter_Soap

• Mage_Catalog_Model_Product_Api_V2

Changements à Mage_Api_Model_Server_Adapter_Soap

             : $urlModel->getUrl('*/*/*');

         if ( $withAuth ) {
-            $phpAuthUser = $this->getController()->getRequest()->getServer('PHP_AUTH_USER', false);
-            $phpAuthPw = $this->getController()->getRequest()->getServer('PHP_AUTH_PW', false);
-            $scheme = $this->getController()->getRequest()->getScheme();
+            $phpAuthUser = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_USER', false));
+            $phpAuthPw = rawurlencode($this->getController()->getRequest()->getServer('PHP_AUTH_PW', false));
+            $scheme = rawurlencode($this->getController()->getRequest()->getScheme());

             if ($phpAuthUser && $phpAuthPw) {
                 $wsdlUrl = sprintf("%s://%s:%s@%s", $scheme, $phpAuthUser, $phpAuthPw,

changement à Mage_Catalog_Model_Product_Api_V2

     public function create($type, $set, $sku, $productData, $store = null)
     {
-        if (!$type || !$set || !$sku) {
+        if (!$type || !$set || !$sku || !is_object($productData)) {
             $this->_fault('data_invalid');
         }

@@ -243,6 +243,9 @@ class Mage_Catalog_Model_Product_Api_V2 extends Mage_Catalog_Model_Product_Api
      */
     protected function _prepareDataForSave ($product, $productData)
     {
+        if (!is_object($productData)) {
+            $this->_fault('data_invalid');
+        }
         if (property_exists($productData, 'website_ids') && is_array($productData->website_ids)) {
             $product->setWebsiteIds($productData->website_ids);
         }

Voir plus à: http://www.amitbera.com/magento-security-patch-supee-6482/

Veuillez lire la documentation de Magento sur cette version, la réponse est là: http://merch.docs.magento.com/ce/user_guide/Magento_Community_Edition_User_Guide.html#magento/release-notes-ce-1.9.2.1.html

Ce correctif, comme les autres correctifs récents, contient de nombreux correctifs de copie, de licence et de faute de frappe. Il présente également quelques fautes de frappe de ce que j'ai vu.

La partie de correctif de sécurité réelle semble traiter la désinfection des entrées utilisateur pour 4 attaques potentielles différentes.