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 infatti non c'è scritto da nessuna parte che ci deve stare il punto e poi il top level domain.
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 infatti non c'è scritto da nessuna parte che ci deve stare il punto e poi il top level domain.
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 è.Validation is used to validate or check if the data meets certain qualifications. For example, passing in FILTER_VALIDATE_EMAIL will determine if the data is a valid email address, but will not change the data itself.
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.phpValidation is used to validate or check if the data meets certain qualifications. For example, passing in FILTER_VALIDATE_EMAIL will determine if the data is a valid email address, but will not change the data itself.
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.