Risposta.

Storia della domanda

Con l'aumento degli attacchi informatici, l'accento sui test di sicurezza è aumentato. Anche per i tester manuali è importante saper identificare vulnerabilità standard.

Problema

Spesso i tester manuali considerano le questioni di sicurezza solo una responsabilità degli automatizzatori o degli esperti di sicurezza. Questo porta a trascurare bug elementari, fatali per il business.

Soluzione

Il test manuale della sicurezza è un tentativo di riprodurre potenziali attacchi dalla posizione di un normale utente:

Verifica di XSS, SQL Injection, CSRF.
Manipolazioni con cookie e sessioni.
Tentativi di elusione dell'autenticazione e delle limitazioni dei diritti.

Tutti i problemi trovati devono necessariamente essere documentati secondo il modello "Bug Report" con una descrizione dettagliata del passo, del risultato atteso e di quello effettivo, oltre a indicare il livello di criticità.

Caratteristiche chiave:

Utilizzo di tecniche manuali semplici (modifica dei parametri nell'URL, tentativi di inserire valori pericolosi).
Verifica delle vulnerabilità standard dall'OWASP Top 10.
Necessità di comunicare con DevOps/Backend per chiarire come vengono gestiti gli errori e quali log vengono generati.

Domande insidiose.

È possibile identificare manualmente tutte le vulnerabilità critiche nell'applicazione?

No. L'approccio manuale consente di trovare vulnerabilità ovvie, ma per una copertura completa sono necessari scanner automatizzati e penetration test.

È sufficiente controllare solo il modulo di accesso e password per il test di sicurezza?

No. È necessario controllare tutti i moduli funzionali, in particolare quelli che modificano/salvano dati, le interazioni con le API, il caricamento di file e le operazioni sui diritti di accesso.

È necessario che il tester comprenda le richieste e le risposte HTTP se si parla di test manuale della sicurezza?

Sì. Lavorare con strumenti come DevTools, Postman o Fiddler è la chiave per trovare problemi di sicurezza manualmente.

Errori comuni e anti-pattern

Il test di sicurezza è limitato all'accesso e alla registrazione.
Ignorare le vulnerabilità se non si riesce ad sfruttarle subito.
Non documentare le vulnerabilità trovate in violazione degli standard dei bug report.

Esempio dalla vita reale

Caso negativo

Il tester ha verificato solo l'accesso al sistema per XSS, senza testare gli altri moduli utente e i parametri URL.

Pro:

Test di prima linea eseguito rapidamente.

Contro:

È stata trascurata una vulnerabilità critica nel profilo utente, dove era possibile eseguire un'iniezione SQL.

Caso positivo

Il tester ha controllato in sequenza tutti i moduli di input, ha modificato i parametri nelle richieste, ha descritto dettagliatamente quanto trovato nel bug report, e ha contattato DevOps per consulenza sulla gestione degli errori.