Magento : SUPE-6788, la nuova (mega) patch di Magento

Nuova patch di sicurezza per Magento, già la sesta per il 2015. Questa volta le vulnerabilità riscontrate sono diverse, al punto che il pacchetto interviene su una cinquantina di files. L'installazione va eseguita nel solito modo: occorre scaricare dal sito https://www.magentocommerce.com/download la patch 6788 specifica per la nostra versione di Magento, copiarla nella root del nostro server e lanciare da shell il comando (sh <nome patch.sh>).
Tuttavia è possibile ricevere un messaggio di errore come questo:
Hunk #1 FAILED at 207.
1 out of 1 hunk FAILED
can't find file to patch at input line 38

Questo errore blocca l'intera installazione, nessun file viene aggiornato. La causa è da ricercare nel fatto di aver eseguito modifiche al file .htaccess originale, che ora Magento non riesce quindi più ad aggiornare.
La soluzione è quella di procurarsi una copia della propria versione di Magento originale (sempre da qui  cliccare su "release archive"), estrarre il file .htaccess e -dopo aver rinominato il precedente, ad esempio in "___htaccess"- copiarlo nella root della nostra installazione.
A questo punto rilanciare la patch. Una volta terminata l'operazione, riprendere il file .htaccess della nostra installazione (quello che avevamo temporaneamente rinominato in ___htaccess). Dove troviamo la riga
#FileETag none

sostituiamo con
#FileETag none
###########################################
## Deny access to cron.php
    <Files cron.php>
 
############################################
## uncomment next lines to enable cron access with base HTTP authorization
## http://httpd.apache.org/docs/2.2/howto/auth.html
##
## Warning: .htpasswd file should be placed somewhere not accessible from the web.
## This is so that folks cannot download the password file.
## For example, if your documents are served out of /usr/local/apache/htdocs
## you might want to put the password file(s) in /usr/local/apache/.
 
#AuthName "Cron auth"
#AuthUserFile ../.htpasswd
#AuthType basic
#Require valid-user

############################################

Order allow,deny
Deny from all

</Files>
  
e rinominiamo di nuovo il file in .htaccess, cosi da sostituirlo al precedente (in modo da recuperare anche le modifiche fatte in precedenza>).

La patch da sola potrebbe comunque risultare insufficiente. Infatti template e moduli aggiuntivi possono sovrascrivere (dentro la directory /local/) i files di default di Magento; per cui, pur avendo il core aggiornato, il nostro sito potrebbe essere ancora vulnerabile.
Per sapere quali sono i file corretti dalla patch, apriamo il file "applied.patches.list" dentro la cartella app/etc.
A questo punto vediamo la lista dei files e verifichiamo che questi files non siano stati modificati da qualche altro file dentro la cartella /local, ovviamente con un percorso identico.
Ad esempio se la nostra patch ha modificato il file
app/code/core/Mage/Core/Controller/Varien/Router/Admin.php
verifichiamo di non avere nessun file con questo percorso
app/code/local/Mage/Core/Controller/Varien/Router/Admin.php

in questo caso, dovremmo replicare le modifiche apportate dalla patch anche nel file in /local (a questo proposito può risultare utile un editor di confronto come Meld).

Più che altro però questa problematica riguarda i files di template, in particolare la patch in questione sovrascrive il file
app/design/frontend/base/default/template/customer/form/register.phtml

aggiungendo questo campo hidden:
<input type="hidden" name="form_key" value="<?php echo Mage::getSingleton('core/session')->getFormKey() ?>" />
subito dopo gli altri hidden già presenti (<input type="hidden" name="error_url" value="<?php echo $this->getErrorUrl() ?>" /> ecc).

Aggiungiamo questa riga in tutti i /customer/form/register.phtml dei nostri template, anche quelli non usati (come rwd installato di default dalle ultime versioni di Magento)

Verifichiamo che il nostro Magento sia correttamente patchato lanciando una scansione dal sito https://www.magereport.com/