Vulnerabilità CSRF Attack & Session Hijack

Question

Dalle note di rilascio 1.8CE Alpha:

Il negozio web Magento contiene ulteriori Cross Site Request Forgery (CSRF) protezioni, il che significa un impostore non può più impersonare una nuova cliente registrato e eseguire azioni per conto del cliente.

e

Nelle versioni precedenti, Magento era vulnerabile ad una fissazione di sessione attaccare durante il processo di registrazione. Dopo l'accesso al loro conto, ID di sessione di un utente registrato non è cambiata. Pertanto, se una conoscenza attaccante ha avuto di un ID di sessione non autorizzata e se questo utente con successo registri, l'attaccante è stato in grado di prendere in consegna il recentemente account registrato. Ora, l'ID di sessione cambia dopo il successo registrazione, rendendo l'uso non autorizzato di un account impossibile.

Se questo è nelle note di rilascio, e non vedo un punto di rilascio su versioni precedenti affrontare questo (sto cercando nel posto sbagliato?) - allora vuol dire che attuale pre-1.8 negozi sono potenzialmente aperti a questi vettori di attacco

Fonte: http://www.magentocommerce.com/knowledge-base / entry / ce-18-dopo-release-notes

Answer 1

In breve, sì. CE 1.7 è ancora vulnerabile a questi attacchi specifici, perché nessuno di rilascio di sicurezza è stato rilasciato, che contiene una patch.

Nel caso di questi ultimi uno, un attacco di fissazione sessione, il cambiamento è un aggiornamento nelle pratiche di sicurezza che Magento già usato per rimanere in linea con la sicurezza attuale best practice. Non qualcosa rischia di essere rilasciato a CE 1.7 se lo fanno rilasciare una patch con le correzioni CSRF.

La vera domanda è che cosa esattamente fossero queste vulnerabilità CSRF che sono stati fissati? Senza dubbio una buona cosa che non includono le specifiche nelle note di rilascio, quindi compromettendo ulteriormente tutte le versioni precedenti, ma sarebbe bello sapere per il bene di patching vecchie implementazioni.

UPDATE # 1: Dopo aver raggiunto fuori per Magento per sapere quando saranno rilasciano le patch per le vulnerabilità di cui sopra, ho ricevuto la seguente risposta:

Mi Lasciare un po 'di tempo alla ricerca questo ulteriore. Non sono sicuro se ci sono patch disponibili per questi due elementi, in quanto sono presenti nel nostro sistema, come miglioramenti di prodotto e non come gli insetti. Io aggiornerò quando ho più informazioni.

Vi posto di nuovo ulteriori dettagli qui come li ricevo, e cercherò di fare del mio meglio per ottenere le patch rilasciate in quanto sembra che non ci sono al momento tutte le patch esistenti.

UPDATE # 2: Dopo avanti e indietro con il team di supporto, sono stato in grado di ottenere una patch adeguata per Magento EE 1.12.0.2. No patch è stata rilasciata per Magento CE 1.7.0.2, e per quanto riguarda il tecnico che guardò dentro internamente per mi conosce, non ci sono piani per rilasciare una patch ufficiale per 1.7.x CE invece di risolvere i problemi solo nella prossima CE 1.8 versione stabile.

Per quanto riguarda il file di patch specifica EE, non posso post-it (o lo strumento di applicazione del cerotto) qui direttamente in quanto sarebbe più senz'altro essere in violazione di NDA tra Magento e me personalmente e l'azienda per cui lavoro. Il nome della patch in questione è: "PATCH_SUPEE-1513_EE_1.12.0.2_v1.sh" - Se si dispone della versione Enterprise o un client di usarlo, si dovrebbe essere in grado di richiedere questa patch da parte del team di supporto Magento insieme a una nota su le vulnerabilità CSRF, che si suppone di correzione.

Per CE 1.7.0.2 utenti, ho preso la libertà per generare un file di patch (in base alla patch fornita da Magento), che include solo i grossi pezzi di codice che alterano i file di codice 1.7.0.2 fondamentali Magento CE. In modo normale, che comprende i bit irrilevanti commento inserito e rettificati formattazione insieme alle modifiche di codice pertinenti. La creazione di questo necessario modificare manualmente la patch originale per applicarlo con la patch fornita strumento di applicazione, quindi utilizzando git per generare una patch in base alle modifiche applicate.

Il file di patch che ho creato può essere scaricato da questa sostanza: https://gist.github.com/davidalger/ 5938568

Per applicare la patch, primo cd nella root della vostra installazione di Magento ed eseguire il seguente comando: patch -p1 -i ./Magento_CE_1.7.0.2_v1-CSRF_Patch.diff

La patch specifica EE incluso chiave forma controlli di convalida per i controller specifici Enterprise, alterazioni file di modello di iphone impresa / default e impresa / per includere le chiavi di forma nelle forme in uso per le azioni di controllo rattoppate, e ulteriori funtionality piena pagina cache di adeguatamente conto per il passaggio di chiavi di forma avanti e indietro nelle pagine nella cache.

NOTA BENE: che ho non testato sia la patch EE fornito da Magento né la patch ho caricato il succo del discorso legato. La patch fornita nel succo di riferimento è fornito SENZA GARANZIA e può o non può risolvere completamente le vulnerabilità fa riferimento nelle CE 1.8 note di rilascio. Come un cerotto non testato, non v'è nemmeno garantito che funzioni in tutto o in parte. Cioè utilizzare a proprio rischio, e prendere la dovuta diligenza per prova prima della distribuzioneper un ambiente di produzione. Se trovate problemi con la patch, fatemelo sapere e io aggiornare esso.

Answer 2

Io non sono sicuro al 100% perché non ero in grado di riprodurre il problema, ma

che significa un impostore non è più possibile impersonare un cliente di nuova immatricolazione

mezzi che fino ad ora 'un impostore' potrebbe impersonare un cliente di nuova immatricolazione.
Spero che sia solo 'semantica' ma penso che significa che ciò che si teme che significa.