Non molto tempo fa, ho scritto di una vulnerabilità che ha colpito Koa.js nel 2018. Ero frustrato di dover affrontare un problema del 2018 mentre la data era il 2022 e stavo usando l'ultima versione di Koa. Sono passati 4 anni. È molto tempo. Sicuramente il problema non c'è più!? Ed era e non era allo stesso tempo. Ciò significa che avevo torto e ragione allo stesso tempo. Quindi, ecco un aggiornamento al post precedente per dirti come:

• Ho ingiustamente accusato Sonatype e Dependency Track di non operare con le informazioni sulla versione in casi specifici
• Posso avere ragione e torto allo stesso tempo su una vulnerabilità

L'indice OSS contiene informazioni sulla versione

Se hai letto il mio post precedente, probabilmente ricorderai che ho concluso che il problema non mi ha colpito. La buona notizia è che avevo ragione. La cattiva notizia è che ho accusato ingiustamente Sonatype di non avere i numeri di versione nei dati forniti da OSS Index per Dependency Track con cui lavorare. Si scopre che hanno le informazioni. Semplicemente non era visibile dove mi aspettavo che avrebbe dovuto essere visibile. Guarda lo screenshot qui sotto scattato il 22/11/2022.

È molto probabile che Dependency Track (DT) non funzioni esattamente con ciò che viene visualizzato nella pagina sopra, ma non mi interessava controllare come fossero i dati DT recuperati dall'indice OSS. DT ha appena mostrato un collegamento a OSS Index, dove ho potuto saperne di più. Ho cliccato e sono arrivato su questa pagina.
Oggi Sonatype mi ha fatto notare che i numeri di versione sono disponibili; Devo cercare altrove. In effetti, se accedi al tuo account e cerchi Koa o fai clic sul pulsante "Vedi dettagli per koa" nello screenshot sopra, puoi trovarlo. Guarda lo screenshot qui sotto.

Quindi mi sbagliavo. Sonatype ha le informazioni nel database. Il problema è con il livello di presentazione, quindi. Sarebbe meglio se avessero le versioni interessate elencate nella pagina in cui viene effettivamente discussa la vulnerabilità in modo che possiamo vedere e verificare se necessario.

Ho ingiustamente accusato Sonatype OSS Index di non avere le informazioni sulla versione. Ho anche accusato ingiustamente Dependency Track di essere disposto a segnalare esclusivamente in base al nome della dipendenza se le informazioni sulla versione non erano disponibili. (Devo ancora scoprire se quest'ultimo è vero o falso, non ho controllato.)

Non mollare ancora! Le cose più interessanti da discutere sono l'effettiva vulnerabilità e le (si spera) imminenti modifiche al rapporto di vulnerabilità in OSS Index. Partiamo dalla vulnerabilità.

Cross Site Scripting

Sonatype ha attribuito XSS a Koa sulla base del processo di pensiero sottostante.

Koa è l'entità che scrive l'URL della risposta HTML, non lo sviluppatore che utilizza Koa

È decisamente ragionevole aspettarsi che lo sviluppatore convalidi l'URL fornito, probabilmente rispetto a una lista consentita, per impedire un reindirizzamento aperto e non Koa poiché Koa non avrebbe idea di quali URL vorresti consentire o meno. Tuttavia, come sviluppatore, non penso che dovrei preoccuparmi di eseguire la sanificazione XSS per un URL che sto passando a un metodo redirect().

Koa sembra preoccuparsi di XSS in questo contesto poiché hanno già il codice lì per impedirlo, entità HTML che codifica l'URL quando lo scrivono nell'HTML

Sono d'accordo in una certa misura. Non sono d'accordo con quanto segue, per esempio.

Non penserei che dovrei preoccuparmi di eseguire la sanificazione XSS per un URL che sto passando a un metodo redirect ()

Se passi un URL valido e sicuro a un metodo di reindirizzamento fornito da te (lo sviluppatore), non devi preoccuparti di XSS (ovviamente). Se trasmetti in tutto o in parte dati forniti dall'utente, è qualcosa di cui devi sempre preoccuparti, che tu sia uno sviluppatore o un professionista della sicurezza. Tuttavia, non è inverosimile aspettarsi che Koa aiuti lo sviluppatore.

Lasciate che vi faccia un ottimo esempio che, si spera, aiuti a capire da dove vengo. Nell'esempio seguente, passo i dati forniti dall'utente al browser nel corpo della risposta. Lo faccio senza alcuna convalida, sanificazione o codifica.

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

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

• Pensa a cosa e come passo al browser nel corpo della risposta
• Considera (e probabilmente è meglio controllare esplicitamente!) il valore dell'intestazione Content-Type per la risposta
• Sappi che Koa, per impostazione predefinita, regola automaticamente il valore dell'intestazione Content-Type in base al valore passato a ctx.body. (Prova a passare, ad esempio aaa, e guarda come cambia)

Considerando l' ctx.bodyesempio "XSS" sopra, sembra che stessimo incolpando Koa per aver implementato misure specifiche per prevenire un disastro durante l'utilizzo di ctx.redirect(). Citando nuovamente Sonatype:

Koa sembra preoccuparsi di XSS in questo contesto poiché hanno già il codice lì.

Questo significa che se a Koa non interessasse XSS in questo contesto, allo stesso modo in cui non gliene importa (e non dovrebbe) occuparsene quando si tratta di ctx.body, nessuno l'avrebbe contrassegnata come una vulnerabilità XSS? È abbastanza divertente. Ho notato alcune somiglianze con la mia precedente analisi su Formidable documentata qui e qui .

Detto ciò che ho detto finora, sembra che ci sia un XSS... e non allo stesso tempo. Come è possibile? Semplice! È lì, ma non puoi sfruttarlo a meno che:

1. La vittima usa un vecchio browser web, AND
2. Esiste un reindirizzamento aperto implementato dallo sviluppatore utilizzando ctx.redirect()AND di Koa
3. Lo sviluppatore si fida completamente di tutti i dati forniti dall'utente e li passa testualmente actx.redirect()

La pagina del rapporto Sonatype diceva, come puoi vedere dallo screenshot di oggi, "Reindirizzamento aperto che porta a Cross-Site Scripting". Il mio post precedente metteva in discussione la parte "reindirizzamento aperto":

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.

Sonatype concorda inoltre sul fatto che Koa non è responsabile della prevenzione dei reindirizzamenti aperti. La loro preoccupazione, la mia preoccupazione e la principale preoccupazione di tutti gli altri era l'XSS. Coinvolgere il reindirizzamento aperto creava solo confusione. Allo stesso tempo, tecnicamente non era irragionevole, come vedremo in seguito. (Influirà anche sul punteggio di vulnerabilità.)

Come accennato in precedenza, sfruttare con successo il comportamento di Koa richiede un reindirizzamento aperto. Ma:

• Koa non è responsabile della prevenzione dei reindirizzamenti aperti (come concluso in precedenza)
• Koa non verrà eseguito ctx.redirect()senza l'autorizzazione dello sviluppatore
• Koa non obbliga gli sviluppatori a utilizzare i reindirizzamenti

Quindi, c'è un altro livello di protezione: i casi d'uso. Con quale probabilità uno sviluppatore non vorrebbe alcun controllo su dove viene reindirizzato un browser? Molto spiacevole. Ciò significa che, molto probabilmente, gli sviluppatori passeranno i dati controllati dall'utente in ctx.redirect()aggiunta a un altro pezzo di stringa. Quindi, è più probabile che accada qualcosa di simile agli esempi mostrati di seguito:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Punteggio di vulnerabilità

Devono essere soddisfatte tre (3) condizioni affinché il bug sia sfruttabile, come discusso alla fine della sezione precedente.

• Quale versione di un browser viene utilizzata dipende dall'utente finale
• L'uso del metodo di reindirizzamento e il modo in cui viene utilizzato spetta allo sviluppatore

Ciò che richiede anche enfasi è che l'uso del metodo di reindirizzamento in modo non sicuro è il vettore di attacco. Per sfruttare con successo è necessario un vettore di attacco. Koa non fornisce il vettore di attacco; lo sviluppatore lo fa.

Mettiamo in correlazione questo con la definizione di "Vulnerabilità del software" fornita dal NIST:

La parte che vorrei evidenziare è “potrebbe essere sfruttata”. Prendi Koa come una libreria software. Puoi sfruttarlo senza creare prima il vettore di attacco richiesto? No. Quindi, dal punto di vista di Koa, una libreria software, non viene presentato alcun vettore di attacco; senza di essa, lo sfruttamento è impossibile. Se interpretassimo la definizione rigorosamente (cosa che faccio), non potremmo definire il comportamento di Koa una vulnerabilità.
Proviamo a calcolare un punteggio CVSS senza un vettore di attacco:

Non c'è punteggio se non c'è un vettore di attacco. Direi che questo è coerente con la definizione di vulnerabilità del software fornita dal NIST.
Sperimentiamo e creiamo uno scenario immaginario in cui esiste un vettore di attacco.

Ci sono ancora diversi problemi qui, oltre al vettore di attacco immaginario. La complessità dell'attacco è stata impostata su Alta perché uno sfruttamento riuscito richiede un vecchio browser. Un utente malintenzionato deve convincere le vittime a scaricare e installare un vecchio browser.
In tal senso, è richiesta l'interazione dell'utente, anche se le metriche di base dell'interazione dell'utente non riguardano realmente questo. In questo scenario, se lo sfruttamento dell'XSS richiede l'interazione dell'utente dipende da come l'applicazione Web ha utilizzato i reindirizzamenti e non da Koa. Vale anche la pena ricordare che il codice JavaScript inserito non veniva eseguito da solo poiché richiedeva l'interazione dell'utente in primo luogo: facendo clic sul collegamento nella risposta HTML.

Quindi cosa possiamo fare per forzare un punteggio di vulnerabilità su questo? Dobbiamo selezionare qualcosa. Un pio desiderio, assumendo il peggio, qualunque cosa tu preferisca. Una cosa è certa, stai facendo un calcolo che non dovresti fare in primo luogo, e il risultato è così lontano dalla realtà che non riesco nemmeno a trovare le parole per descriverlo.

La prossima grande novità sono le metriche di impatto. Devi sapere cosa sta per dire l'applicazione Web per raccontare l'impatto. Ma non stiamo calcolando un punteggio di vulnerabilità per un'applicazione Web... Dato il contesto, questo XSS non ha alcun impatto su Koa. Koa non gestisce né elabora informazioni riservate in proprio. Il bug non ha alcun impatto sulla disponibilità o sull'integrità. Questo ci lascia con il punteggio finale di 0.0, anche dopo aver forzato un vettore di attacco nel calcolo.

Quindi la domanda è: riportiamo fatti o finzione?

Sonatype ha portato alla mia attenzione la guida ufficiale per Scoring Vulnerabilities in Software Libraries , che è stata rilasciata nel 2019 con CVSSv3.1. Ammetto che non lo sapevo, il che è sia positivo che negativo. Bene perché sarebbe risultato in un post di sproloquio, male perché forse se l'avessi visto prima, avrei perso tutte le mie speranze prima di impegnarmi così tanto nel cercare di spiegare che non è il modo giusto per farlo. Allora, cosa dice la guida ufficiale?

Quando si assegna un punteggio all'impatto di una vulnerabilità in una libreria... L'analista dovrebbe valutare lo scenario di implementazione ragionevole nel caso peggiore. Quando possibile, le informazioni CVSS dovrebbero dettagliare queste ipotesi.

Quindi la risposta è che il punteggio di vulnerabilità è basato sulla finzione.

Inoltre, qual è uno " scenario di implementazione ragionevole nel caso peggiore"? Se analizzassimo molti progetti che utilizzavano Koa e scoprissimo che la maggior parte degli sviluppatori ha implementato reindirizzamenti aperti utilizzando il ctx.redirect()metodo di Koa, potrebbe essere ragionevole presumere il peggio. Ho fatto una rapida ricerca del codice nei progetti JavaScript per ctx.redirect(su GitHub. Ho ottenuto 16.827 risultati di codice. Cercando context.redirect(ho ricevuto 15.751 risultati di codice. Sarebbero 32.578 risultati di codice da analizzare. Alcuni di questi useranno Koa, alcuni Express e alcuni potrebbero essere qualcos'altro. (Naturalmente, il contesto potrebbe essere chiamato con qualsiasi nome, non solo ctxo context, quindi potrebbe esserci ancora più codice da esaminare.)

La domanda è: il passaggio dei dati forniti dall'utente senza cervello per il reindirizzamento è così comune? Ho adottato un approccio semi-automatico all'analisi scrivendo un piccolo script per controllare tutti i progetti che corrispondevano ai criteri di ricerca. Sfortunatamente, non sono riuscito a superare i primi 1.000 accessi poiché GitHub ha rifiutato ulteriori richieste:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Sulla base di ciò che ho visto e considerando quanto discusso nella sezione successiva ("Il vecchio browser Web"), non credo che l'ipotesi di un'implementazione nel caso peggiore sarebbe ragionevole. Non in questo caso specifico.

La guida ufficiale dice anche che:

Quando si assegna un punteggio a una vulnerabilità in una determinata implementazione utilizzando la libreria interessata, il punteggio deve essere ricalcolato per quella specifica implementazione.

Ciò è ragionevole e mitiga in una certa misura l'aspetto fantascientifico della situazione. È così che questo problema di Koa, con un punteggio di vulnerabilità di 9,8, è finito per essere 0,0 nel nostro caso.

La cosa buona è che Sonatype ha convenuto che il punteggio di vulnerabilità 9.8 era irragionevole e sono disposti a ridurlo. Lo apprezzo, e probabilmente lo faranno anche molti altri.

Inoltre, Sonatype mi ha detto che quando ha aggiunto il problema al proprio sistema, ha creduto che sarebbe stato meglio se i suoi clienti fossero stati informati di questa situazione potenzialmente inaspettata. Hanno detto: "era meglio allertare piuttosto che ignorare ciò che abbiamo visto e potenzialmente avere un esito negativo". E, naturalmente, avevano ragione.

Non ho mai messo in dubbio se i problemi di sicurezza debbano essere comunicati o meno. Sì, i problemi di sicurezza devono essere resi visibili. Quello che mi preoccupa è come vengono comunicati questi problemi:

• È appropriato chiamare qualcosa una vulnerabilità o più appropriato chiamarlo una debolezza della sicurezza o un comportamento predefinito insicuro e così via?
• Il punteggio di vulnerabilità assegnato è ragionevole?
• Vengono forniti dettagli e contesto sufficienti?

Ora parliamo un po' dei vecchi browser web.

Il vecchio browser web

Senza le brave persone di Sonatype, non avrei pensato ai vecchi browser web, probabilmente mai più.

Continuerò a non considerare i vecchi browser anche in futuro. Prima di tutto, ci sono troppe cose da tenere a mente; Non posso preoccuparmi dei vecchi browser web. Secondo, quanti anni ha ( non cliccare sul link se non hai il senso dell'umorismo! ) un vecchio browser web? Cosa significa veramente "vecchio"? Se qualcuno utilizza solo un browser vecchio di circa 1 anno, è molto probabile che abbia già problemi molto più grandi di XSS.

Comunque, ho fatto qualche ricerca e ho scoperto che:

• Google Chrome 48.0.2564.109 (64 bit) del 2016 (!) non mostrava nemmeno il corpo della risposta. Poiché il problema di Koa è stato riscontrato nel 2018, ho pensato che tornare indietro fino al 2016 sarebbe stato sufficiente, ma si è scoperto che non lo era.
• Firefox 4.0 del 2011 mostrava il corpo della risposta, ma richiedeva agli utenti di fare clic sul collegamento per eseguire il payload JavaScript. (Certo, è un link!)
• Firefox 52.0 del 2017, 1 anno prima della segnalazione del problema Koa XSS, non mostrava già il corpo della risposta con il payload JavaScript. Firefox ha appena generato un errore che diceva "Errore di contenuto danneggiato" a causa di una "violazione del protocollo di rete".

Koa 0.0.1 è stato rilasciato nel 2013, quindi ci sono stati alcuni anni in cui il problema avrebbe potuto essere sfruttato. A partire da questo, sarebbe probabilmente accettabile segnalare questo problema (ancora non con un punteggio di 9.8) fino a Koa 2.5.0 nel 2018. Dopodiché, tuttavia, nulla giustifica qualcosa al di sopra di 1.0.

Mentre stavo scavando, ho trovato qualcosa di interessante su Wikipedia . Permettetemi di citare:

Firefox 15 è stato rilasciato il 28 agosto 2012 … Firefox 15 ha introdotto aggiornamenti silenziosi, un aggiornamento automatico che aggiornerà Firefox all'ultima versione senza avvisare l'utente, [65] una funzionalità che hanno i browser Web Google Chrome e Internet Explorer 8 e versioni successive già implementato

Quindi tutti i principali browser Web avevano una funzione di aggiornamento automatico prima del rilascio della prima versione di Koa, il che significa che è probabile che la maggior parte degli utenti utilizzasse un browser Web aggiornato. Vediamo lo stato al tempo del “big bang”: 2013.

• Firefox 15 : ha restituito un errore che diceva "Errore di contenuto danneggiato", il che significa che il corpo della risposta non è stato visualizzato all'utente.
• Chrome 24.0.1312 (WebKit 537.17) : non mostrava alcun corpo della risposta. Mentre guardavo la scheda di rete degli strumenti di sviluppo, non c'era quasi nulla di visibile, quindi ho dovuto eseguire Wireshark per vedere se il browser ha eseguito la richiesta in primo luogo. In Wireshark, era visibile che Chrome ha contattato il mio servizio PoC e ha ricevuto la risposta con il payload JavaScript. Non ha reso il corpo della risposta. Ancora meglio, non è successo niente.
• Internet Explorer 11 (11.0.9600.19180) : ha recuperato la risposta dal mio servizio PoC, che ho verificato utilizzando Wireshark. Non ha mostrato il corpo della risposta all'utente. È tornato con la classica pagina di errore incorporata che dice "Questa pagina non può essere visualizzata".

Dopo aver svolto la ricerca di cui sopra, torniamo per un secondo a una citazione di Sonatype:

Koa sembra preoccuparsi di XSS in questo contesto poiché hanno già il codice lì per impedirlo, entità HTML che codifica l'URL quando lo scrivono nell'HTML

Sebbene questa affermazione sia corretta, il fatto che nessuno dei principali browser consentisse lo sfruttamento al momento del rilascio della prima versione di Koa, quanto citato suggerisce qualcosa di interessante, qualcosa di diverso da ciò che la frase vorrebbe suggerire. Si prega di notare che sto per scrivere speculazioni in quanto non posso sapere con precisione come stavano pensando gli sviluppatori di Koa. Posso facilmente immaginare che gli sviluppatori abbiano testato il comportamento in questione utilizzando un browser Web aggiornato. Potrebbero aver scoperto che la codifica HTML era adatta perché era già impossibile ottenere il codice JavaScript iniettato eseguito dalla hrefproprietà delaetichetta. Ciò solleva una domanda seria. Avendo trascorso gli ultimi cinque anni in più sul lato dello sviluppo software, vale anche per me: come sviluppatore, se sto per creare una nuova tecnologia web per il lato back-end, dovrei preoccuparmi dei vecchi browser web? E se dovessi, qual è la raccomandazione ufficiale della comunità della sicurezza in merito a quanto indietro nel tempo devo considerare i vecchi browser web? Non dovremmo considerare che la migliore pratica di sicurezza per gli utenti finali è mantenere aggiornati i loro browser e anche la funzione di aggiornamento automatico è lì per aiutare in questo? Inoltre, se ci aspettiamo che gli sviluppatori tengano a mente e testino con i vecchi browser, non possiamo aspettarci che i professionisti della sicurezza facciano lo stesso e nominino tutti i browser web e le loro versioni che contribuiscono a un problema specifico invece di riferirsi semplicemente a "vecchi browser ”? Sarebbe giusto.

Una cosa è certa, non c'è nulla di cui preoccuparsi da anni ormai...

Il navigatore moderno

Nella mia analisi, utilizzando il mio browser web, ho controllato il corpo della risposta e l'ho trovato vuoto. Non ho verificato se la risposta inviata via filo avesse un corpo. Si scopre che è stato solo Google Chrome a ignorare completamente il corpo della risposta; pertanto, non ha mostrato. Era abbastanza buono per me. Ragionevolmente, devo aggiungere.

Da allora, ho esaminato la risposta del mio servizio Web di prova utilizzando l'ultima versione di Koa. Di seguito possiamo vedere che c'era un corpo di risposta HTML con il codice JavaScript inserito:

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Prossime modifiche

Di seguito è riportato l'elenco degli aggiornamenti che Sonatype intende implementare in merito a questo problema:

• Aggiornamento della riga Riepilogo/Titolo per eliminare fraintendimenti (già avvenuto)
• Ridurre il punteggio di vulnerabilità a 4,7 (già avvenuto)
• Ricorda che la vulnerabilità può essere sfruttata solo se un utente utilizza un browser precedente

Ulteriori modifiche che vorrei vedere

Oltre alle modifiche menzionate nella sezione precedente, alcune cose potrebbero essere ulteriormente migliorate. Questi sono:

• Riducendo ulteriormente il punteggio di vulnerabilità, in particolare per le versioni Koa rilasciate dopo il 2018.
• Includendo il numero di versione almeno dei principali browser Web e le relative date di rilascio inclusi nel rapporto quando si fa riferimento ai "browser meno recenti". Ciò aiuterebbe in modo significativo chiunque quando "si valuta una vulnerabilità in una data implementazione utilizzando la libreria interessata". Ad esempio, se vedessi che un utente doveva utilizzare un browser dal 2011, entro un secondo avrei contrassegnato il problema come "non interessato" in SCA. È un sacco di tempo risparmiato.
• Le versioni di Koa interessate devono essere elencate nella pagina della vulnerabilità .

A proposito, Sonatype ha anche affermato di avere alcuni controlli interessanti nella loro offerta commerciale che, ad esempio, eseguono controlli effettivi a livello di codice per vedere se un'applicazione è stata interessata dalle vulnerabilità segnalate. Sembra chiaro, e data la natura fantascientifica di come vengono calcolati i punteggi di vulnerabilità per le biblioteche, questo tipo di controlli è un must per ridurre il carico sui team di ingegneri, specialmente se le cose continuano così.

Conclusione

Sono praticamente tutti gli aggiornamenti che ho. Sono contento di aver contattato Sonatype perché sono molto professionali e amichevoli. È stato un piacere lavorare con loro su questo.

Per quanto riguarda l'XSS in Koa: è qualcosa di cui nessuno di noi dovrebbe preoccuparsi da diversi anni.