Durante il corso, abbiamo appreso una serie di metodi per scoprire bug e
vulnerabilità in diversi tipi di software e infrastruttura, di solito alla fine del test dovrai informare il cliente con tutte le
vulnerabilità che hai trovato o con tutte le risultati.
Questo viene fatto utilizzando un rapporto di prova.
Quindi, in pratica, ciò che intendiamo per rapporto di prova, è solo un documento che include tutto ciò
che hai trovato durante il tuo impegno in modo che il cliente o l'amministratore possano procedere e correggere tutte le vulnerabilità e
le debolezze che hai trovato.
Questi rapporti vengono letti molto spesso anche dai dirigenti.
Pertanto, dovresti tenerne conto.
Quindi un buon rapporto dovrebbe essere abbastanza facile.
Ma è anche facile capire ora se lavori come tester, quindi l'azienda per cui lavori probabilmente
avrà il proprio modello e i propri standard che devi seguire quando scrivi un
rapporto.
E in molti casi, non lo farai nemmeno.
Inoltrerai semplicemente i tuoi risultati a un altro membro del tuo team e questi riempiranno correttamente
gli spazi vuoti nel rapporto.
Pertanto, probabilmente non sarà necessario scriverne uno da zero.
E in molti casi non scriverai nemmeno il rapporto effettivo che il cliente vede.
Detto questo, voglio ancora mostrarti come è fatto, solo per darti un'idea di come appare
un rapporto di prova.
Ora, prima di tutto, prima di mostrarti l'esempio che ho, includerò questo
repository, che fondamentalmente contiene un gran numero di rapporti Pantazis.
Quindi potresti effettivamente guardare attraverso questi per ispirazione e solo per vedere i diversi stili che le diverse
aziende seguono quando realizzano un rapporto di prova.
Quindi puoi fare clic su uno di questi e troverai il rapporto e puoi effettivamente esaminarlo
per imparare come questa specifica azienda, scrivi i loro rapporti e forse trovi qualcosa che ti piace
che inizieresti a includere nel tuo rapporto .
Quindi includerò questo nelle risorse della conferenza in modo che tu possa tornarci per trarre ispirazione.
Ma quello che voglio veramente fare è guidarti attraverso un campione di rapporti che usiamo qui in sicurezza.
Giusto per darti un'idea delle sezioni principali che hanno la maggior parte dei rapporti.
Includerò anche questo nelle risorse.
Quindi sentiti libero di modificarlo e usarlo o prenderne alcuni elementi se lo desideri.
Quindi noterai dal repository qui dentro, ogni azienda ha il suo stile di scrittura dei report, ma
in generale ci sono sempre alcune sezioni principali che troverai in ogni report.
Quindi, iniziando dalla prima pagina proprio qui, abbiamo la pagina di copertina.
Quindi, di nuovo, puoi venderlo come vuoi.
Di solito hai il logo dell'azienda, hai il titolo e poi avrai la data del rapporto e
la versione.
Questo è molto importante.
E poi abbiamo la società, le nostre informazioni sulla società.
Quindi questo rapporto è scritto da noi.
Queste sono le informazioni sulla nostra azienda.
E poi hai nel campo di forza, hai la compagnia per cui stai scrivendo questo rapporto.
Quindi avresti il nome dell'azienda, avrai un ID specifico per questa azienda.
Questa è l'idea che hai identificato questa azienda nei tuoi registri.
Di nuovo, probabilmente non è qualcosa che farai da solo.
Ti verrà data questa idea dalla tua stessa azienda.
E poi abbiamo le informazioni di contatto per entrambe le società.
Quindi puoi vedere in questa azienda che abbiamo questo lì uno e poi Tester due con i loro indirizzi e-mail.
Questo potrebbe essere ovviamente un elenco più grande con tutto il team che sta facendo il test e simile
all'azienda per cui stai facendo il test.
Ancora una volta, hai i loro nomi, la loro posizione nell'azienda e le loro informazioni di contatto.
Ora, di nuovo, tieni presente che non devi sempre modellare la prima pagina in questo modo, ma più o
meno di solito nella prima pagina avrai il titolo, la data, la versione e le informazioni di contatto.
Così è come lo facciamo noi.
Ma ancora una volta, puoi farlo nel modo che desideri e puoi trarre ispirazione dalla risorsa che
includerò qui.
Successivamente, di solito abbiamo di nuovo il sommario, come puoi vedere, cose semplici di solito avrebbero
in qualsiasi tipo di documento.
Questo ti aiuterà a navigare nell'intero documento.
E come ho detto qui, possiamo vedere le sezioni principali di qualsiasi rapporto di protesta.
Quindi è molto importante avere un riassunto esecutivo.
Questo è un riassunto dell'intero coinvolgimento progettato per le persone meno tecniche.
Quindi dovrebbe dare loro un'idea delle tue scoperte senza immergerti troppo nei dettagli tecnici.
Quindi abbiamo un riepilogo dell'impegno in cui dettagliamo l'ambito.
Quindi questo è ciò che hai testato, quali parti del loro sistema hai testato, le valutazioni del rischio che
hai usato e una panoramica di tutto ciò che hai trovato.
Quindi, ancora una volta, finora, non ci stiamo immergendo in profondità o semplicemente questo è solo un riassunto dell'intero impegno.
Avrai un'idea migliore di tutto questo mentre esamino il rapporto.
E poi, nella sezione dei dettagli tecnici, è qui che ti immergi davvero in profondità in tutto ciò che hai
trovato.
Quindi fondamentalmente abbiamo una sezione per ogni risultato.
Quindi, come puoi vedere, questo è solo un esempio.
Quindi ho fatto solo tre risultati.
Abbiamo un'iniezione iniziale, una richiesta incrociata tra siti.
Sì.
SRF e una divulgazione delle informazioni.
Quindi, come puoi vedere nella prima sezione, in pratica avevamo solo un riassunto di
tutto ciò che abbiamo trovato, mentre nei dettagli tecnici stavamo praticamente analizzando ogni singolo risultato.
E parleremo di come l'abbiamo trovata nei dettagli, come replicarla.
Includerai degli screenshot, se possibile, in modo che il team tecnico possa comprendere esattamente la
gravità di questa vulnerabilità e come risolverla.
Noterai che altre aziende includeranno un'appendice alla fine, includeranno consigli in cui ti
diranno esattamente come correggere le vulnerabilità.
Come ho detto, dipende molto dall'azienda.
Ogni singola azienda ha il proprio stile e ogni singola azienda ha il proprio format.
Quindi quello che ti sto mostrando qui è solo un esempio di come lo facciamo.
Puoi trarre ispirazione dalle risorse e in molti casi dovrai solo seguire il modello che la tua azienda
ha perché non vogliono che tu lo faccia a modo tuo.
Quindi andiamo alla pagina successiva e vedrai in questa pagina abbiamo le informazioni legali.
Ed è per questo che in realtà ho detto che probabilmente non lo farai da solo.
Non avrai mai bisogno di farlo da solo perché avrai parti del rapporto come questa.
Non dovrai mai modificare e saranno effettivamente scritti dal team legale della tua azienda.
Quindi spiegheranno tutto ciò che potrebbe andare fuori controllo per assicurarsi che non sarai citato in giudizio.
Se qualcosa va storto, conterrà cose come disclaimer, PIL, la nostra privacy, cose legali e tutte quelle
cose che non conosciamo molto bene.
Di solito scrivono i tester e i legali, e poi abbiamo il changelog del documento.
Quindi ogni volta che viene apportata una modifica al documento, puoi vedere che abbiamo la data, abbiamo la versione
e abbiamo un commento.
Perché abbiamo fatto questo cambiamento o cosa c'è di così significativo in questo cambiamento?
Quindi questo era il rapporto iniziale quando l'abbiamo fatto il 1 gennaio e poi il 10 gennaio abbiamo fatto una seconda
versione in cui abbiamo finito con la seconda fase.
Ancora una volta, questi sono solo campioni.
Ma solo per darvi un'idea che tenere un registro delle modifiche di tutti i cambiamenti che questo
documento subisce è molto, molto importante.
Non tutte le aziende lo fanno.
Ma ancora una volta, è solo una nostra scelta di aggiungerlo al nostro rapporto.
Continuo a dirlo solo per darti un'idea che non ci sono regole fisse per fare questo tipo di documenti.
Puoi aggiungere o rimuovere tutto ciò che vuoi, ma le parti principali sarebbero la parte legale, la sintesi esecutiva
e poi la parte tecnica.
Queste saranno le parti principali del rapporto.
Quindi ora abbiamo il sommario esecutivo e puoi leggerlo.
Questo non dovrebbe essere lungo.
Quindi, secondo me, deve essere una pagina al massimo di due pagine se proprio devi.
E sostanzialmente dice solo che ci è stato ordinato di testare un sistema.
Spiegherà come è organizzato questo documento, dove la prima sezione è meno dettagliata, solo per
darti un'idea del rischio.
E il secondo è dettagliato per consentire ai tecnici di comprendere questi rischi e risolverli e quindi è stata data
la valutazione del rischio.
Quindi presumiamo che questo sia ad alto rischio in base alle vulnerabilità che abbiamo trovato.
Descriverà in dettaglio la metodologia che abbiamo seguito.
E poi abbiamo alcuni grafici qui.
Ricorda, questa parte viene letta dai dirigenti.
Queste sono persone che non sono molto tecniche per la maggior parte del tempo, e inoltre non hanno molto tempo.
Quindi includiamo dei grafici qui per mostrare loro la quantità di vulnerabilità che abbiamo trovato.
Quindi possiamo vedere che abbiamo cinque vulnerabilità che sono alte.
Ne abbiamo 10 medi e otto bassi.
Quindi questo darà loro una buona comprensione delle minacce che devono affrontare.
E poi torniamo al sommario.
Questo sarà ancora letto dalle persone meno tecniche.
Quindi, prima di tutto, stiamo dettagliando l'ambito per assicurarci di dire loro cosa abbiamo testato, anche se ci hanno
già detto cosa testare, solo in modo che nel caso in futuro, se qualcosa fosse scoperto al di
fuori del nostro scopo e tornano da noi, possiamo dire, beh, questo era fuori dallo scopo.
Non abbiamo testato questo l'anno prossimo, inclusa la valutazione del rischio.
Quindi avrai questo in ogni documento.
Vuoi che lo modifichi.
Fondamentalmente stiamo solo dicendo come classificheremmo una certa vulnerabilità come bassa, media, alta o
critica.
E stiamo dicendo, a nostro avviso, come dovresti gestire le vulnerabilità basse, medie, alte e critiche che puoi
vedere per le criticità, diciamo che devi correggere immediatamente, mentre per la legge devi
correggere nel prossimo ciclo di aggiornamento.
Ancora una volta, questa è solo la nostra opinione.
Successivamente, abbiamo i risultati della revisione.
Quindi siamo ancora nella sezione uno.
Questo è ancora per i dirigenti.
Non abbiamo bisogno di immergerci troppo in profondità.
Quindi ci è stata data solo l'idea della vulnerabilità.
E puoi vedere per la prima vulnerabilità, è fondamentale.
È un'iniezione di Ezechiele.
E in molti casi, in molti rapporti, in realtà lo fermeranno, dicendo che è solo un'iniezione di ESKIL.
Ci piace mostrare effettivamente l'impatto in questa sezione perché, come ho detto, questi ragazzi non sono tecnici.
Quindi, se è un'iniezione, potrebbero non sapere cos'è un'iniezione ESKIL.
Ciò di cui si preoccupano è l'impatto di questa vulnerabilità.
Di nuovo, non hanno molto tempo, quindi devi andare dritto al punto.
Quindi stiamo dicendo che è un'iniezione naturale che potrebbe portare all'accesso autorizzato al
database.
Quindi ora sanno che con questa vulnerabilità un hacker può accedere al loro database.
Questo è probabilmente piuttosto brutto.
Un'altra vulnerabilità che abbiamo riscontrato è media ed eccessiva.
Di nuovo SRF, molti rapporti si fermeranno qui, in realtà non spiegano nulla alle persone non tecniche.
Quindi stiamo dicendo che i clienti possono essere costretti a inviare determinate richieste non critiche.
Ecco perché è una richiesta mediatica, non non critica.
Ma possono essere costretti a inviare materiale.
E poi abbiamo una vulnerabilità in cui viene divulgata la versione HP.
Quindi questo non è davvero molto critico perché non è una vera vulnerabilità che può essere sfruttata
per ottenere l'accesso o esporre i dati dell'utente.
Ma queste informazioni potrebbero essere utili agli hacker per concatenare altri attacchi o scoprire vulnerabilità
per questa versione specifica.
Ed è per questo che è basso.
Ecco perché non ha bisogno di essere curato molto urgentemente, come quelli critici, come abbiamo detto
sopra e qui.
E sentiti libero di leggere il testo qui, vedrai che molto è fondamentalmente solo per schiarirci le
spalle e assicurarci che capiscano tutto ciò che è nel rapporto.
E quella sarebbe stata la fine dell'estate.
E ora entriamo nei dettagli tecnici.
Quindi, in questa sezione, abbiamo fondamentalmente, come ho detto, una sottosezione per ogni singolo risultato che
abbiamo.
E ci stiamo immergendo davvero nei dettagli di questa scoperta.
Quindi puoi vedere che questa è l'iniezione effettiva di cui abbiamo parlato prima nel riepilogo.
Ma questa volta diamo loro l'URL che è vulnerabile.
Stiamo dando loro il parametro vulnerabile.
Stiamo dando loro dei riferimenti per capire cos'è l'iniezione di Eskil.
Nel caso in cui non lo capissero, stiamo dando loro la richiesta esatta e la risposta esatta che
abbiamo ricevuto, il che ci ha portato a determinare che questa particolare pagina è vulnerabile a un'iniezione.
Quindi diamo loro l'impatto qui in dettaglio, non solo dicendo che possono accedere al database.
Quindi stiamo dicendo che possono accedere al database.
Possono recuperare i dati a cui abbiamo avuto accesso alla tabella dell'utente.
Quindi ti immergerai nei dettagli e dovresti anche includere schermate qui.
Se pensi che ti saranno utili nella sezione mitigazione.
Stiamo solo dando loro una rapida raccomandazione.
Come ho detto, alcune aziende forniscono raccomandazioni dettagliate.
Questo dipende molto anche dal fidanzamento.
Quindi, in questo esempio, stiamo semplicemente dicendo di usare le istruzioni prepare con query parametrizzate e stiamo dando
loro un riferimento per imparare come farlo o per capire come funziona.
E questo è praticamente tutto.
Quindi lo ripeterai per ogni singola vulnerabilità che hai trovato?
Lascio il resto vuoto poiché questo è solo un campione, ma rende l'idea.
Quindi avrai una sottosezione per ogni scoperta in cui hai spiegato tutto nei dettagli in modo che
capiscano la vulnerabilità e poi possano andare avanti e risolverla.
Alla fine, molte aziende avrebbero un'appendice e potrebbero avere una sezione di consigli più ampia, come ho detto,
questo è il nostro stile di scrittura dei rapporti su ciò che ogni azienda ha il suo stile, se vuoi.
Potrebbe essere necessario un po' di tempo per esaminare i report di esempio che abbiamo in questo repository.
Ovviamente, includerò entrambi i collegamenti per il mio campione e per gli altri campioni e le risorse in modo
che tu possa esaminarli tu stesso e avere un'idea di come appaiono i rapporti di Pennhurst.
Ma come ho detto, in molti casi, riempirai semplicemente un campione simile a quello che abbiamo qui.
Quindi non ti verrà mai chiesto di inventarne uno da zero.