La mia frustrazione è sempre alta perché è appena successo di nuovo. Se hai letto la mia precedente analisi intitolata CVE-2022–29622: (In)vulnerability Analysis , potresti sospettare a cosa mi riferisco. Stessa storia, vittima diversa. Tuttavia, le date sono importanti in questo caso. La mia precedente analisi di invulnerabilità è del 2022, oggi analizzerò un altro problema del 2018.

Potresti chiedere: "Perché hai a che fare con qualcosa del 2018?" Ottima domanda! Perché di recente ho abilitato Dependency Track per estrarre informazioni sulla vulnerabilità dall'OSS Index di Sonatype.

Oggi mentre stavo sfogliando SCA per vedere se avevamo componenti vulnerabili e, in tal caso, dare la priorità al lavoro di riparazione. Mi sono imbattuto in qualcosa di molto sorprendente. Koa.JS ha una vulnerabilità critica?! Dopo il mio solito "#FFS, tutta la mia settimana ha bisogno di essere riorganizzata", ho pensato: "Fai un respiro profondo e dai un'occhiata a cosa si tratta. Ricordi cos'è successo l'ultima volta…”

E così ho fatto. Prima di tutto, il titolo chiarisce che il "problema" è stato riscontrato nel 2018. Ora, perché dovrei avere una vulnerabilità in una libreria che è ancora mantenuta e continuo ad aggiornare all'ultima versione? A questo punto è entrata in gioco la parte investigativa del mio cervello.

Cosa sappiamo/vediamo a questo punto?

1. Presumibilmente c'era una vulnerabilità in Koa nel 2018 con una gravità critica assegnata
2. Secondo Sonatype OSS Index e Dependency Track il problema mi riguarda nel 2022 durante l'esecuzione dell'ultima versione di Koa

• Quali versioni della libreria Koa.JS sono state interessate dalla "vulnerabilità"
• Se la "vulnerabilità" è presente nell'ultimo Koa.JS

Analisi del problema

Vediamo cos'è/era la “vulnerabilità”. Consentitemi di collegare rapidamente il problema correlato n. 1250 da GitHub qui. Mi limiterò a copiare e incollare l'esempio (PoC?) di seguito in modo da poterlo analizzare.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

"Come sviluppatore di un'applicazione web o di un servizio web, posso reindirizzare il tuo browser dove voglio se visiti il ​​mio sito web."

Questo è ciò che significa il codice sopra. Nel PoC di cui sopra non viene presentato alcun vettore di attacco per consentire a un attore malintenzionato di sfruttare qualcosa.

Se volessi fornire un "PoC" adeguato per questa non vulnerabilità (sì, l'ho appena detto), sarebbe simile a questo:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

Parlando di una vulnerabilità XSS, se tutto ciò che ho inserito come valore del vectorparametro è stato visualizzato in un contesto HTML in modo non sicuro, l'applicazione che ho implementato sarebbe vulnerabile al Cross Site Scripting. (Maggiori informazioni su questo più avanti)

Zoomando su come Sonatype lo ha presentato e analizzandolo un po' più a fondo:

"Reindirizzamento aperto che porta allo scripting tra siti"? Prima di tutto, non c'era alcun reindirizzamento aperto. È aperto solo se lo apri e la differenza tra i due PoC (l'originale e il mio) lo mostra chiaramente. Nel primo non c'era alcun vettore di attacco, quindi non c'era un reindirizzamento aperto. Il mio PoC aveva un vettore di attacco, nessun filtro, quindi c'era un reindirizzamento aperto. Ma, come puoi vedere, se c'era o meno un reindirizzamento aperto dipendeva da me, lo sviluppatore e non da Koa.JS. Ancora meglio, se c'era o meno un reindirizzamento dipendeva anche da me. Se ho incluso l'input fornito dall'utente come/nell'URL di reindirizzamento in modo non sicuro dipendeva anche da me. Di quale vulnerabilità Koa.JS stiamo parlando allora? Tecnicamente, non c'era una vulnerabilità e qualcuno le assegnava comunque la gravità Critica. Non esattamente professionale.

Ad ogni modo, “sfruttiamo” detta “vulnerabilità” messa in atto dall'apposito PoC. Si prega di notare che ho dovuto cambiare la porta di servizio da 3000 a 4444 poiché avevo già qualcosa in ascolto sulla porta 3000.

Possiamo vedere che l' Locationintestazione della risposta ha il valore javascript:alert(1). Quindi, il browser reindirizza a...

Eh, sono al sicuro! Non è stata visualizzata alcuna finestra di avviso. Sì, potrei inserire https://google.comcome valore del vectorparametro di ricerca ed essere reindirizzato a Google, quindi la mia applicazione (PoC) è vulnerabile al reindirizzamento aperto, ma non a causa di Koa, ma perché ho passato dati utente non filtrati a ctx.redirect. Non è qualcosa che mi preoccupa, non lo farei mai.

Una cosa importante da notare dai commenti al problema su GitHub è la seguente:

Il problema deriva dal fatto che Koa stampa un collegamento ipertestuale HTML nel corpo della risposta di reindirizzamento e che può innescare un attacco di scripting cross-site.

Ah, questo ha un po' più senso! Vediamo se è ancora così.

No, non è più così. Non c'è nessun corpo di risposta. Immagino di poter concludere che questa "vulnerabilità" non mi riguarda. Posso semplicemente contrassegnarlo come falso positivo in Dependency Track.

Analisi del contesto

Propongo che "l'analisi del contesto" venga adottata da tutti i professionisti della sicurezza ed eseguita prima di segnalare i "problemi". Lascia che questo sia un altro esempio e ti mostri come è fatto. (Consiglio comunque di leggere CVE-2022–29622: (In)vulnerability Analysis anche se spiega molto meglio l'importanza del contesto.)

1. Koa.JS out-of-the-box non ti reindirizza da nessuna parte. Pertanto, c'è e non c'era "Open Redirect" come affermato da Sonatype OSS Index.
2. Sulla base del "PoC" fornito su GitHub, c'era un'opportunità per uno sviluppatore di fare qualcosa di stupido che potesse portare a XSS. Ma, vedi # 1 sopra. Koa.JS non ha eseguito alcun reindirizzamento da solo. Vedi n. 2 sotto.
3. Uno sviluppatore deve aver implementato la propria applicazione in modo non sicuro affinché la "vulnerabilità" segnalata sia presente. Questo significa praticamente che Koa.JS, anche se avrebbe potuto fare di meglio, non puoi definirlo vulnerabile. È contestualmente inappropriato. La vulnerabilità in questione potrebbe essere presente solo in un'applicazione Web implementata in modo non sicuro .

Lasciate che vi faccia un esempio di come gestire al meglio situazioni come questa. Guarda questo problema che ho inviato a Swagger Parser e come è stato comunicato. Analizziamo il report del problema:

1. Il titolo dice "Comportamento risolutore insicuro". Non sto parlando di LFI (Local File Inclusion) nel titolo. Questo perché mentre c'è un potenziale per l'inclusione di file locali SE FACCIO UN CASINO, spetta davvero a me come sviluppatore sapere con cosa sto lavorando e come ci sto lavorando. Il comportamento predefinito era (forse lo è ancora) insicuro. Ma la biblioteca da sola, senza il mio coinvolgimento, non farà nulla.
2. Quindi, indico chiaramente di quale versione della libreria sto parlando. Rendo il contesto ancora più chiaro elencando le condizioni in cui il comportamento predefinito insicuro della libreria influenzerebbe un'applicazione. Ciò rende abbastanza chiaro che la libreria stessa non è vulnerabile, ma ha un comportamento insicuro che può essere migliorato per aiutare gli sviluppatori.
3. Quindi, ora che il contesto è impostato, fornisco un PoC funzionante, uno snippet di codice vulnerabile (che ho scritto come PoC, non fa parte di Swagger Parser!) e il risultato reale dello sfruttamento di un'app/servizio vulnerabile che utilizza il biblioteca in modo insicuro.
4. Ho svolto alcune indagini e ho scoperto che come sviluppatore posso effettivamente configurare la libreria in modo da mitigare il problema. (in una certa misura) l'ho condiviso con gli sviluppatori. Se non altro, almeno possono aggiornare la documentazione per aumentare la consapevolezza.
5. Ho fornito ulteriore contesto, analisi e un esempio di come le cose potrebbero essere migliorate.

Conclusione

Prima di tutto, Sonatype dovrebbe fare di meglio con l'OSS Index e assicurarsi che le informazioni sulla versione siano disponibili per ogni vulnerabilità nel database. Questo è il minimo indispensabile. (Punti bonus per la rimozione completa di questa specifica voce dal database.)

Sospetto che Dependency Track soffra di FOMO, quindi è disposto a segnalare problemi basati esclusivamente sulla corrispondenza del nome del componente se il numero di versione non è disponibile. Capisco in una certa misura che non rischierebbero di perdere una vulnerabilità critica. Il problema con questo comportamento (falsi positivi) è che non incoraggia l'adozione di Software Composition Analysis. Spaventerà gli sviluppatori come i falsi positivi dell'analisi statica del codice. Controproducente.

Contesto! Il maledetto contesto, gente! Propongo:

1. "Analisi del contesto" che deve essere adottata da tutti i professionisti della sicurezza ed eseguita prima di segnalare "problemi"
2. Distinguere il “comportamento insicuro” dalla “vulnerabilità”
3. Comprendere la differenza tra una libreria software e un'applicazione/servizio