Verifica se un'applicazione Web utilizza componenti vulnerabili noti

how can you check if a web application (as the attacker) has known vulnerabilities in it without already having exploited the application successfully?

Esistono vari modi per impronte digitali di un'applicazione Web senza accesso privilegiato.

Un modo comune per iniziare è identificare le versioni di librerie, framework e i rispettivi plugin usati. Questo può essere fatto ispezionando il codice sorgente, le intestazioni, i percorsi di indovinello dei file readme, ecc. Quindi verificherai se queste versioni sono aggiornate o se ci sono vulnerabilità pubblicate per loro sul web.

Ad esempio, prendi il blog di Facebook https://newsroom.fb.com/ . Guardando attraverso il codice sorgente, troverai rapidamente stringhe che indicano che stanno usando Wordpress, ad esempio:

<meta name="generator" content="WordPress.com" />

Sapendo che usano Wordpress potresti voler cercare plugin famosi che sono noti per essere vulnerabili. Ad esempio, sembra che stiano utilizzando il plug-in AMP , perché c'è un readme.txt in:

https://newsroom.fb.com/wp-content/plugins/amp/readme.txt

Questo readme rivela che usano l'ultima versione 0.5.1 , quindi il plugin sembra aggiornato.

Un altro esempio potrebbe essere https://stackoverflow.com in cui puoi scoprire quale versione di jQuery usa:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>

Sebbene 1.12.4 non sia l'ultima versione, non sembrano esserci difetti immediatamente sfruttabili.

Come puoi vedere, il controllo di un'applicazione per componenti vulnerabili noti non richiede necessariamente un accesso privilegiato poiché spesso vengono trapelate versioni e configurazioni.

Perché devi essere l'attaccante? OWASP Top 10 è pensato per gli sviluppatori di applicazioni e i loro team di controllo qualità.

Se stai cercando qualcosa per i pen-testers black-box, c'è la Guida ai test OWASP

Il modo più semplice per rilevare A9 utilizzando componenti con vulnerabilità note è uno strumento come Controllo dipendenza OWASP che si integra nell'ambiente di generazione del prodotto.

Oltre alla risposta eccellente di Arminius ci sono un paio di altri modi per guardare a questo.

Innanzitutto, se stai usando un componente con vulnerabilità note e viene esposto in qualche modo, allora è tutto ciò che ti serve, perché puoi testarlo e sfruttarlo direttamente. Alcuni esempi recenti importanti sono state le numerose vulnerabilità di analisi di ImageMagick che erano direttamente sfruttabili su siti che consentivano il caricamento arbitrario di file, e quindi hanno tentato di analizzare quei file con le versioni vulnerabili di ImageMagick. O le vulnerabilità dell'algoritmo "nessuno" che erano presenti in una serie di popolari librerie JWT.

Forse la cosa più importante però, ricorda che l'obiettivo principale per OWASP Top 10 non è in ogni caso il penetration tester. C'è una guida di prova OWASP per loro. La Top 10 è rivolta agli sviluppatori, per aiutarli a pensare in modo proattivo sui problemi che potrebbero avere le loro applicazioni. Si tratta di una guida molto più diretta quando vista da quella prospettiva, che è sapere quali dipendenze e componenti vengono utilizzati dall'applicazione, eseguire il lavoro di linea per assicurarsi che non abbiano vulnerabilità note e sostituire quelli che lo fanno, e in modalità di manutenzione, non dimenticare che cosa sta usando la tua applicazione in modo che quando vengono scoperte nuove vulnerabilità, puoi reagire a loro prima che ti mordino come uno dei bit di vulnerabilità di Apache Struts Equifax.