Sto scrivendo un nuovo sito web in PHP e userò i cookie per tracciare i dati della sessione utente. Prima di finalizzare il progetto, voglio assicurarmi che il sito non sia vulnerabile agli attacchi. Ho scritto un elenco di metodi di attacco e ho escogitato delle contromisure per ciascuno di essi. Qualcuno può pensare ad altri metodi di attacco e in tal caso proporre anche contromisure adeguate?
Un elenco di tutti i metodi di attacco che potrei pensare:
- cookie di sessione Indovina / bruteforce
- Ruba cookie di sessione (ad esempio se l'utente malintenzionato salva il cookie di sessione su USB)
- Scripting tra siti
- Phishing (fissazione della sessione)
- Iniezione SQL
- Iniezione header HTTP
Va notato che userò il mio database per memorizzare le informazioni sulla sessione, non le funzioni di sessione standard di PHP. Quando rilevo un attacco eseguirò una funzione chiamata warn_and_halt() che registrerà l'attacco e informerà il sysadmin, quindi interromperà la sessione sotto attacco.
Le mie contromisure per ciascuno dei suddetti tipi di attacco sono:
-
Piuttosto che usare un intero grande per l'ID di sessione memorizzato nel cookie, genererò il mio numero casuale e poi lo cancellerò con qualcosa come SHA-1 per renderlo un po 'più difficile da indovinare. Naturalmente l'ID di sessione potrebbe non essere univoco se viene creato in questo modo, quindi dovrò controllare tutti gli altri ID di sessione nel database e rigenerare se l'ID di sessione appena generato esiste già. Sono fiducioso con questa misura.
-
Suppongo che l'USB verrà trasferito su un altro computer e il cookie di sessione caricato in un altro browser. Registrerò l'agente utente (nome del browser) per ogni sessione. Se l'agente utente cambia durante la sessione, allora creerò
warn_and_halt(). Ho letto di persone che usano l'indirizzo IP per convalidare l'ID di sessione, ma non penso che lo userò del tutto dato che gli indirizzi IP possono cambiare durante una sessione per ragioni completamente innocenti - per esempio se il router dell'utente resetta e negozia un nuovo IP con il loro ISP. Qualcuno può suggerire ulteriori contromisure qui? -
Imposterò il cookie di sessione come HTTPonly e controlleremo anche il dominio dei cookie in entrata. A mio parere non c'è molto di ciò che può essere fatto per impedire che ciò accada su un browser: il browser potrebbe scegliere di non rispettare la flag HTTPonly - nulla che io possa fare lì! Qualcuno conosce un modo migliore per prevenire XSS?
-
Immagino che il phishing si verifichi in caso di "cattiva" registrazione da parte dell'utente nel mio sito, quindi invio via email un link come
<a href='javascript:void(0);' onclick="document.cookie='sessionid=xxxx';document.location='http://mywebsite/'">all'utente "ignaro". Questo imposterà un cookie di sessione senza "dimenticarlo" sapendolo. Quindi "ignaro" inserirà le proprie informazioni personali e l'utente "cattivo" ha queste informazioni! Penso che la maggior parte dei browser non consentirà che il dominio del nuovo cookie sia impostato come mywebsite, quindi "dimentico" è abbastanza sicuro. Tuttavia, controllerò il dominio in arrivo di ogni cookie per assicurarmi che sia per il mio sito web. Utilizzerò sicuramente i cookie, piuttosto che GET o POST per memorizzare l'ID di sessione. Inoltre, risolverò la fissazione della sessione cambiando l'ID di sessione per ogni pagina visitata. -
L'iniezione SQL è un problema con un ambito molto più ampio rispetto al furto di ID di sessione, ma lo neutralizzerò in generale evitando sempre i dati in arrivo (compresi i cookie) e filtrando i caratteri errati con espressioni regolari. Penso di avere questo molto ben coperto.
-
Ho appena saputo dell'inputione header HTTP. Tuttavia, sembra abbastanza facile da contrastare: basta sfuggire ai campi dell'intestazione in entrata, specialmente per i ritorni a capo e per convalidare le intestazioni in entrata.
Quindi questi sono tutti gli attacchi e le contromisure che potrei pensare (dopo un bel po 'di lettura online). Se vedi qualcosa che ho perso, per favore rispondi. Se vedi che nessuna delle mie contromisure è insufficiente, ti preghiamo di dirlo.