Descriptions:
•
Comprendere tutte le potenziali posizioni accessibili agli attaccanti. Ad esempio, alcuni programmatori presumono che i cookie e i campi nascosti dei moduli non possano essere modificati da un attaccante, oppure potrebbero non considerare che le variabili d'ambiente possano essere modificate prima dell'invocazione di un programma privilegiato.
•
Memorizza le informazioni sullo stato esclusivamente sul lato server. Assicurati che il sistema tenga in modo definitivo e inequivocabile traccia del proprio stato e dello stato dell'utente e che siano definite regole per le transizioni di stato legittime. Non consentire a nessun utente dell'applicazione di influenzare direttamente lo stato in alcun modo, se non attraverso azioni legittime che portano a transizioni di stato.
•
Memorizza le informazioni di stato e i dati sensibili esclusivamente sul lato server.
Assicurati che il sistema tenga in modo definitivo e inequivocabile traccia del proprio stato e dello stato dell'utente e che abbia regole definite per le transizioni di stato legittime. Non consentire a nessun utente dell'applicazione di influenzare direttamente lo stato in alcun modo, se non attraverso azioni legittime che portano a transizioni di stato.
Se le informazioni devono essere memorizzate sul client, non farlo senza crittografia e verifica dell'integrità, o senza un meccanismo lato server per rilevare manomissioni. Utilizza un algoritmo di codice di autenticazione del messaggio (MAC), come Hash Message Authentication Code (HMAC) [REF-529]. Applica questo contro lo stato o i dati sensibili che devono essere esposti, in modo da garantire l'integrità dei dati — cioè, che i dati non siano stati modificati. Assicurati che venga utilizzato un algoritmo di hash forte (CWE-328).
•
Utilizzare una libreria o framework verificato che non consenta questa vulnerabilità o che fornisca costrutti che rendano più facile evitarla [REF-1482].
Con un protocollo senza stato come HTTP, alcuni framework possono mantenere lo stato per te.
Gli esempi includono ASP.NET View State e la funzione di Gestione Sessioni di OWASP ESAPI.
Fai attenzione alle funzionalità del linguaggio che forniscono supporto allo stato, poiché queste potrebbero essere offerte come comodità per il programmatore e potrebbero non considerare gli aspetti di sicurezza.
•
Quando si utilizza PHP, configurare l'applicazione in modo che non utilizzi register_globals. Durante l'implementazione, sviluppare l'applicazione in modo da non fare affidamento su questa funzione, ma fare attenzione a non implementare un'eventuale emulazione di register_globals soggetta a vulnerabilità come CWE-95, CWE-621 e problemi simili.
•
Per qualsiasi verifica di sicurezza eseguita sul lato client, assicurarsi che tali verifiche siano duplicate anche sul lato server, al fine di evitare CWE-602. Gli attaccanti possono aggirare le verifiche lato client modificando i valori dopo che sono stati eseguiti, o modificando il client per rimuovere completamente le verifiche lato client. Successivamente, questi valori modificati verrebbero inviati al server.
•
Utilizzare strumenti e tecniche che richiedono analisi manuale (umana), come penetration testing, threat modeling e strumenti interattivi che consentono al tester di registrare e modificare una sessione attiva. Questi possono essere più efficaci rispetto a tecniche strettamente automatizzate. Ciò è particolarmente vero per le vulnerabilità legate a design e regole di business.