Magento patch di sicurezza SUPEE-6482, Cos'è la patch?

Oggi 04.08.2015 è stata rilasciata una nuova patch di sicurezza, alcuni colleghi e io stavamo controllando la patch ed è sempre bello avere qualche discussione su cosa è cambiato, anche qualcuno sa quali sono i possibili attacchi che potrebbero influenzare e fare acquisti senza patch? Qual è il peggio che potrebbe succedere?

Aggiornamento: volevo solo aggiungere l'e-mail magento inviata oggi per completare il post.

La patch di sicurezza effettiva ( SUPEE-6482 ) riguarda solo i due file seguenti ed è una patch API.

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

L'installazione completa 1.9.2.1 è una questione completamente diversa. Differirei il codice sorgente tra 1.9.2.0 e 1.9.2.1 per capire gli altri due elementi che sono stati patchati.

Le note di rilascio sono per il programma di installazione completo, è necessario controllare la patch per vedere se include effettivamente tutti gli elementi indicati nelle note di rilascio.

Implicazioni sull'esecuzione di un server senza patch:

1. Scripting tra siti utilizzando intestazioni non convalidate => Avvelenamento da cache
2. Inclusione dei file caricati automaticamente nell'API SOAP Magento => Caricamento automatico del codice remoto
3. XSS in Ricerca registro regali => Furto di cookie e rappresentazione dell'utente
4. Vulnerabilità SSRF nel file WSDL => Perdita di informazioni sul server interno e inclusione del file remoto

NOTA: file corretti nell'archivio completo dell'installazione che non sono corretti con la patch, 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()) ?>';

Osservo i cambiamenti nei dettagli e quali effetti collaterali devono aspettarsi.

Nella versione per EE 1.13.1.0 sono cambiati i seguenti file:

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

• In Adapter/Soap.php, urlencoding viene aggiunto ai dati di autenticazione. Questo non dovrebbe avere effetti collaterali negativi. Assicura che il risultato wsdlUrlsia valido. Senza questa modifica, si potrebbe influenzare l'URL
• Product/Api/V2.php: Ecco alcuni controlli se i dati passati sono un oggetto. Ciò non dovrebbe accadere in circostanze normali.
• in Request/Http.phpe PageCache/Model/Processor.phpsi aggiunge un controllo quando ricevendo il HOST HTTP. Questo sembra coprire le iniezioni di intestazione menzionate. Il controllo si applica solo se è presente un ;o, nell'host HTTP, quindi questo dovrebbe essere acritico nei sistemi di vita reale / senza effetti collaterali negativi.
• nel cookie.phtml fuga viene aggiunto. Pertanto, se si sovrascrive quel file, questo deve essere trasferito sul tema
• simile per giftregistry/search/form.phtml

Per riassumere, direi che l'applicazione del cerotto non dovrebbe avere effetti collaterali negativi. Ricorda di inoltrare le modifiche ai tuoi .phtmlfile.

La cosa strana è che la patch EE contiene modifiche sui seguenti file:

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

Quando quello CE no, per una versione equivalente.

Presumo che manchi qualcosa in quella SUPEE-6482versione CE, e un V2 potrebbe essere rilasciato presto.

Patch di rilascio Magento SUPEE-6482 per la correzione del problema di seguito nell'edizione CE ed EE

Per Magento Community Edition:

• Inclusione di file caricata automaticamente nell'API SOAP Magento
• Vulnerabilità SSRF nel file WSDL

Per Magento Enterprise Edition

• Inclusione di file caricata automaticamente nell'API SOAP Magento
• Vulnerabilità SSRF nel file WSDL
• Scripting tra siti utilizzando intestazioni non convalidate

XSS nella ricerca del registro regali

Fare il cambiamento in classe

• Mage_Api_Model_Server_Adapter_Soap

• Mage_Catalog_Model_Product_Api_V2

Modifiche in 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,

cambia in 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);
         }

Vedi di più su: http://www.amitbera.com/magento-security-patch-supee-6482/

Leggi la documentazione di Magento in questa versione, la risposta è lì: http://merch.docs.magento.com/ce/user_guide/Magento_Community_Edition_User_Guide.html#magento/release-notes-ce-1.9.2.1.html

Questa patch, come altre patch recenti, contiene molte correzioni di copia, licenza e errore di battitura. Presenta anche alcuni errori di battitura da quello che ho visto.

La parte effettiva della patch di sicurezza sembra indirizzare la sanificazione dell'input dell'utente per 4 diversi potenziali attacchi.