Dobbiamo fare un penetration test sulla nostra web app ma vogliamo prepararci prima — esiste una checklist da fare internamente?

L'anno scorso abbiamo speso 5.000 sterline per far testare un software B2B simile. Non avendo fatto alcuna preparazione preliminare, 14 delle 22 vulnerabilità trovate nel report erano semplici header HTTP mancanti e risposte predefinite del server. Ci siamo pentiti amaramente vedendo che almeno 1.500 sterline del tempo del consulente erano state usate solo per segnalare queste banalità.

L'aspetto più critico è la stabilità dell'ambiente di test. Configurate assolutamente un server di test separato contenente una copia anonimizzata dei dati di produzione, invece di usare l'ambiente live. Quando il tester farà tentativi che rischiano di corrompere il database o intasare le code, la vostra operatività reale non si fermerà. Inoltre, vietate al team di sviluppo di fare deploy di nuovo codice nell'ambiente per tutta la durata del test.

Date un'occhiata alla validazione dell'input e alla crittografia. Verificate l'escape dei caratteri speciali nei campi dei form e nei parametri URL. Assicuratevi che tutti gli input utente scritti nel database siano filtrati correttamente e che i token di sessione vengano completamente invalidati lato server al momento del logout. Questo tipo di falle compromette direttamente l'esito del test.

Nel preparare i test, non cercate di rendere tutto perfetto semplificando eccessivamente l'ambiente. A volte gli sviluppatori spengono completamente il firewall o disabilitano vari livelli di protezione solo per comodità nei test. Poi il sistema risulta pulito nel report, ma va in crash appena va in produzione. L'ambiente di test deve essere la copia esatta della configurazione di produzione.

Fornite ai tester due account validi per ciascuno dei due diversi livelli di autorizzazione: due utenti standard e due amministratori. Aggiungete anche un account demo con tutti i permessi limitati. In questo modo potranno testare il passaggio di privilegi tra utenti e l'escalation orizzontale fin dalle primissime ore senza intoppi.

Il vostro accordo è white-box o black-box? Se condividerete il codice sorgente e gli schemi API, colmare le lacune della documentazione durante la fase preparatoria deve essere la vostra massima priorità. Se invece non darete accesso al codice, il vostro focus dovrà essere interamente sugli endpoint esposti all'esterno.

Il vostro è un approccio davvero corretto. Fare una preparazione interna aumenta sensibilmente anche la consapevolezza sulla sicurezza tra gli sviluppatori. Se organizzate un workshop interno di mezza giornata con il team per rivedere sul codice i punti principali della OWASP, otterrete il massimo rendimento dal pentest.

mettete assolutamente l ip in whitelist sul firewall... insomma nel nostro pentest il tipo è stato bloccato subito il prio giorno e ci han messo mezza giornata di mail x sbloccarlo soldi buttati.

Sono d'accordo.

A me è successo l'esatto contrario, per questo scrivo. Le soluzioni che funzionano su piccola scala crollano quando si cresce l'ho imparato tardi.

Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla. Confermato dall'esperienza.

Se volete procedere così, risolvete questo punto fin dall'inizio. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Questa è la mia opinione, non la scrivo come verità assoluta.

Riassumo quanto detto finora. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Buon lavoro.

Questo thread è archiviato.

Nel nostro caso è andata così. comunque se non lo rendete scritto fin dall'inizio poi nascono discussioni.

Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live. Se scrivete qui il risultato sarà utile anche ad altri.

La penso diversamente. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Un backup non testato non è un backup. Se avete domande, scrivete, rispondo per quanto possibile.

Non ho alcuna esperienza in materia di penetration test web app, quindi chiedo. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Se avete domande, scrivete, rispondo per quanto possibile.

Argomento molto attuale.

La mia domanda sarà un po' da principiante, scusate. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.