Qualsiasi commento o consiglio su OWASP-2013 numero 10 principale A9

19

In questa iterazione dell'elenco delle vulnerabilità di sicurezza delle applicazioni Top 10 OWASP ( link ), una nuova categoria È stato introdotto "A9 Utilizzo di componenti con vulnerabilità note". Ciò sembra richiedere l'analisi di tutte le librerie e il codice importato in qualsiasi applicazione per garantire la conformità.

Ho un certo numero di clienti che, a causa dei loro requisiti di controllo PCI-DSS, usano OWASP top 10 per garantire la sicurezza delle proprie piattaforme software per quelle parti della loro base di codice scritte per elaborare i pagamenti con carta di credito. Con questa nuova serie di requisiti sembrerebbe che dovrebbero trovare / elencare tutte le loro librerie importate (moduli Perl da CPAN in un'istanza e librerie Java in un'altra) e analizzarle riga per riga - probabilmente un milione di righe di il codice di qualcun altro !.

Questo non può essere pratico o, probabilmente, molto utile! OWASP può seriamente suggerire che le organizzazioni che scrivono le proprie applicazioni, importando le librerie comuni, devono rivedere tutto il codice della libreria di terze parti?

Qualcun altro ha riscontrato questo problema e come pensi che io possa affrontare questo problema?

    
posta David Scholefield 22.09.2013 - 20:17
fonte

3 risposte

27

In una revisione formale della sicurezza di un'applicazione, tutte le librerie dovrebbero essere controllate per i difetti di sicurezza. Tuttavia, questo non è il punto di OWASP-2013 A9. Il nucleo di OWASP-2013 A9 riguarda l'adozione di politiche per garantire che un'applicazione non venga compromessa a causa di negligenza. OWASP afferma quanto segue:

  1. Identifica tutti i componenti e le versioni che stai utilizzando, incluso tutte le dipendenze. (ad esempio, il plugin delle versioni).
  2. Monitora la sicurezza di questi componenti nei database pubblici, mailing list di progetto e mailing list di sicurezza e tenerli aggiornati     fino ad oggi.
  3. Stabilire le politiche di sicurezza che governano l'uso dei componenti, come ad esempio richiedendo alcune pratiche di sviluppo del software, passando la sicurezza     test e licenze accettabili.
  4. Laddove appropriato, considera l'aggiunta di wrapper di sicurezza in giro componenti per disabilitare le funzionalità inutilizzate e / o proteggere debole o     aspetti vulnerabili del componente.

Il numero 2 è il più importante. Se si dipende da una libreria o piattaforma, questi componenti devono essere aggiornati regolarmente. All'interno ci dovrebbe essere un ciclo per rivedere tutti i componenti e le versioni e assicurarsi che questi siano completamente aggiornati. Un ciclo mensile per rivedere questi componenti sarebbe l'ideale.

Nel numero breve 4 è necessaria una strong convalida dell'input alle librerie non attendibili . Se una libreria non è stata completamente testata per i difetti di sicurezza, i dati passati a questa libreria devono essere convalidati. È una pratica di sicurezza molto buona per fare questo per tutti gli input. Un esempio di questo è l'utilizzo di una routine di validazione ESAPI OWASP per tutti gli input. Quindi, se si tratta di un indirizzo email, dovrebbe corrispondere a un'espressione regolare per gli indirizzi email.

    
risposta data 22.09.2013 - 20:30
fonte
4

Dal punto di vista di un auditor, non mi aspetto che tu passi attraverso ogni singola riga di codice delle librerie usate SE la libreria è comunemente usata e controllata. Se utilizzi un "codice casuale trovato su Internet" per un sistema di transazioni, mi aspetto che tu abbia avuto una recensione sul codice.

Ora per le librerie più usate e controllate vorrei semplicemente rivedere la versione della libreria e vedere se ci sono vulnerabilità note. Dovresti aggiornare regolarmente le tue librerie con almeno ogni singolo aggiornamento di sicurezza.

Se non è disponibile alcun aggiornamento per la protezione del problema, richiederei un piano di azione per:

  • controlla se lo sfruttamento è avvenuto (a volte un aggiornamento per la sicurezza può riguardare un componente che non viene utilizzato)
  • mitigazione del rischio (disabilitazione del componente o modifica di WAV / IPS)
risposta data 22.09.2013 - 22:50
fonte
0

Rook ha fornito un'ottima risposta alla tua domanda - e anche se è certamente più facile monitorare i componenti utilizzando database pubblici e altri mezzi o rivedere il codice per tutti i componenti, è ancora un'impresa importante. Perché? Poiché le applicazioni sono ora costituite principalmente da componenti, la ricerca mostra che un'applicazione media ora comprende l'80% o più componenti open source. E non si tratta solo dei componenti che si aggiungono alla propria applicazione, ma include anche tutti gli altri componenti dipendenti. Dato il volume, la varietà e la cadenza di rilascio (molti progetti sono aggiornati 4 volte all'anno), è necessaria una qualche forma di automazione.

Le tecnologie di sicurezza delle applicazioni esistenti come DAST e SAST sono progettate per un problema diverso: sono incentrate sul codice personalizzato che unisce i componenti. È necessario un approccio diverso per tenere il passo: un approccio che governa l'intero ciclo di vita, rispetto alle scansioni puntuali che vengono consegnate in ritardo nel ciclo di sviluppo.

Sono disponibili 2 white paper che forniscono ulteriori informazioni su OWASP A9 e sui nuovi requisiti dei componenti PCI 3.0. Inoltre, è disponibile anche un webinar su questo argomento che include informazioni da Crosskey, una società di servizi finanziari.

link

Grazie, Mark Troester Sonatype @mtroester

    
risposta data 26.11.2013 - 03:16
fonte

Leggi altre domande sui tag