Per Borgo e Alessandro, avete un problema sicurezza per cortesia collegate il cervello (icona verde che non c'è).
Il filtro che valida, ho detto valida! FILTER_VALIDATE_EMAIL valida l'email secondo la RFC (non ricordo il numero) per la quale ad esempio localhost è un indirizzo valido come pallino
Ma non è finita, bastava leggere il manuale per rendersi conto che:
Bisogna anche aggiungere il filtro: FILTER_SANITIZE_EMAIL per togliere i caratteri !#$%&'*+-/=?^_`{|}~@.[]. e dare in uscita un valore diverso.
L'esempio riportato alla pagina del manuale chiarisce qualche cosa: http://it.php.net/manual/en/filter.examples.sanitization.php
Per questo a Borgo non tornava quello che diceva Alessandro.
@iacoposk8 la sicurezza assoluta non si raggiunge mai, si tenta di avvicinarsi ad un livello di sicurezza pratico, certo la paranoia aiuta ma si rischia di non dormire la notte.
1) le sesioni in php sono meno che perfette ma non sono nemmeno tanto male, cambiare il valore di sessione può essere un'idea ma tutto sommato anche abbastanza inutile dato che non saprai mai quando avverrà l'attacco.
Meglio usare i token, si crea un numero univoco, tutto sommato un secondo numero di sessione ma ottenuto tramite un artificio, ad esempio il timestamp+$_SERVER['REMOTE_ADDRESS'] passato all'md5 ti darà un valore abbastanza difficile da replicare (a dire il vero no ma insomma ci si possono inventare mille altri modi per ottenere un valore univoco) lo si mette in un array di sessione e lo si confronta con la sessione con la quale è stato creato, se non ci sono incongruenze si va avanti.
2) è un modo ma non necessariamente sicuro però è buono.
3) con il metodo dei token ma non solo, insomma se a uno gli si dice di cliccare qui e quello clicca non c'è nulla da fare.
4) la macchina più insicura e quella posta tra il monitor e la sedia, se uno è "cretino" compierà azioni che nessuno aveva previsto, vedi le leggi di murphy.
Per questo sul Web si parla di insicurezza e non di sicurezza.
Il filtro che valida, ho detto valida! FILTER_VALIDATE_EMAIL valida l'email secondo la RFC (non ricordo il numero) per la quale ad esempio localhost è un indirizzo valido come pallino
Ma non è finita, bastava leggere il manuale per rendersi conto che:
ovvero che comunque la stringa viene sempre riportata come'è in ingresso se ritenuta valida e pinco@pallino lo è.
Bisogna anche aggiungere il filtro: FILTER_SANITIZE_EMAIL per togliere i caratteri !#$%&'*+-/=?^_`{|}~@.[]. e dare in uscita un valore diverso.
http://it.php.net/manual/en/intro.filter.php
L'esempio riportato alla pagina del manuale chiarisce qualche cosa: http://it.php.net/manual/en/filter.examples.sanitization.php
la validazione passa ma vengono tolte le parentesi.
Per questo a Borgo non tornava quello che diceva Alessandro.
@iacoposk8 la sicurezza assoluta non si raggiunge mai, si tenta di avvicinarsi ad un livello di sicurezza pratico, certo la paranoia aiuta ma si rischia di non dormire la notte.
1) le sesioni in php sono meno che perfette ma non sono nemmeno tanto male, cambiare il valore di sessione può essere un'idea ma tutto sommato anche abbastanza inutile dato che non saprai mai quando avverrà l'attacco.
Meglio usare i token, si crea un numero univoco, tutto sommato un secondo numero di sessione ma ottenuto tramite un artificio, ad esempio il timestamp+$_SERVER['REMOTE_ADDRESS'] passato all'md5 ti darà un valore abbastanza difficile da replicare (a dire il vero no ma insomma ci si possono inventare mille altri modi per ottenere un valore univoco) lo si mette in un array di sessione e lo si confronta con la sessione con la quale è stato creato, se non ci sono incongruenze si va avanti.
2) è un modo ma non necessariamente sicuro però è buono.
3) con il metodo dei token ma non solo, insomma se a uno gli si dice di cliccare qui e quello clicca non c'è nulla da fare.
4) la macchina più insicura e quella posta tra il monitor e la sedia, se uno è "cretino" compierà azioni che nessuno aveva previsto, vedi le leggi di murphy.
Per questo sul Web si parla di insicurezza e non di sicurezza.