Drupal Disputed CVE Five Year Tempest - Open Source Security Shortfall?

Per quanto posso dire, si tratta di una segnalazione di bug falsi. Penso che il team Drupal abbia il 100% del diritto di licenziare e contestare questo "bug report". Nessuna delle presunte "vulnerabilità" mi sembra vulnerabilità. Solo affermare che qualcosa è una vulnerabilità non significa necessariamente renderlo tale.

Il giornalista adduce una serie di problemi:

1. Allegation: se l'attaccante apprende il token CSRF, può sconfiggere la difesa CSRF. Bene, duh. È così che funzionano i token CSRF. Non è una vulnerabilità. Quando utilizziamo i token CSRF, progettiamo il sistema per evitare di rivelare il token all'attaccante. Se il reporter ha trovato un modo in cui un utente malintenzionato potrebbe apprendere il token CSRF, potremmo discuterne, ma così com'è, il reporter non ha nulla.

2. Allegagione: il metodo di logout non è protetto da un token CSRF, quindi un utente malintenzionato potrebbe registrare un amministratore. Questo reclamo non sembra essere contestato sui fatti, quindi lo farò supponiamo sia corretto Tuttavia, non vi sono evidenti conseguenze per la sicurezza o il pericolo di essere in grado di disconnettere forzatamente un amministratore. Esistono anche altri modi per disconnettere forzatamente un utente, in ogni applicazione Web mai creata, ad esempio, superando i limiti di capacità sul browser cookie jar .

3. Allegation: Drupal non controlla costantemente l'intestazione del referer su tutte le richieste. Questo non è un difetto di sicurezza. L'intestazione Referer non deve essere utilizzata a fini di sicurezza, in quanto gli autori di attacchi possono falsificarla o forzarla per ometterla. Il giornalista non sostiene alcun danno causato da questa proprietà di Drupal.

4. Allegazione: Drupal non distingue i metodi POST e GET. Questo è probabilmente un caso di scarsa pratica di implementazione, ma non vi sono conseguenze sulla sicurezza identificate dal reporter e nessun danno evidente.

Vedi anche la risposta ufficiale del gruppo Drupal .

Fondamentalmente, penso che il rapporto originale dovrebbe essere ignorato e trattato come non valido, per non attribuire una vulnerabilità di sicurezza valida. Non vedo alcun deficit, fondamentale o meno, nella sicurezza dell'open source. In realtà, penso che sia merito del merito della squadra di Drupal quanto attentamente abbiano risposto alle accuse.

La sicurezza è sempre un compromesso. Per aumentare la sicurezza, di solito devi sacrificare convenienza, prestazioni o altri costi. In questo caso, il team di Drupal sta sostenendo che il vantaggio di sicurezza incrementale è così irrilevante da non giustificare il costo di implementazione.

Dalla lettura del rapporto sull'exploit, sembra che ci siano alcuni "exploit" segnalati. Uno indica che se una persona attacca da una posizione man-in-the-middle o da un processo sul proprio computer della vittima, può sfruttare quella posizione per eseguire un attacco XSRF. Si può sostenere che un tale attaccante deve avere così tanto accesso per montare un attacco del genere che non sta guadagnando nulla che non ha già.

Un altro attacco elencato dice che l'attaccante può creare un modulo di disconnessione che, se inviato dalla vittima, disconnetterà la vittima. Il team drupal sostiene che, poiché la vittima in realtà deve compilare un modulo di disconnessione (che richiede un'azione deliberata) e perché il "carico utile" dell'attacco è semplicemente disconnettere la vittima, e poiché la risoluzione di questo problema interromperà la maggior parte dei temi esistenti, quindi il vantaggio di sicurezza ottenuto non garantisce il disordine che avrebbe causato la correzione.

Infine, il report dice che mentre i moduli hanno il controllo XSRF appropriato, l'interfaccia NON esegue il controllo Referrer HTTP su tutti i moduli. E quindi, se l'attaccante fosse in qualche modo in grado di catturare il token XSRF, avrebbe potuto usarlo per montare un attacco XSRF da un altro dominio. Il team drupal sostiene che l'intero punto del token XSRF è quello di prevenire questo tipo di attacco anche senza controlli Referrer. Sostengono che l'aggiunta di un controllo Referrer in realtà non aggiunge più sicurezza, ma che riduce le prestazioni e la compatibilità del browser. Pertanto, sostengono, questo è un non-problema e non vale la pena indirizzarsi.