login in php: evitare richieste dirette della pagina.

[rickynewtek]

Salve a tutti ho realizzato uno script di login molto semplice, funziona bene ma nel caso venga caricata una pagina direttamente (es: aggiungi.php) vorrei un controllo per impedirlo. Devo lavorare con le sessioni?

[DrugsMatt]

si, prima di fare qualsiasi altra cosa controlli che l'utente sia loggato e abbia i permessi per visualizzare tale pagina, se non è così lo rimandi alla pagina di login terminando con un exit() lo script

[rickynewtek]

si grazie alla fine c'era arrivato, visto che ci sono vi chiedo una cosa:

Ho letto in giro che uno dei metodi più sicuri per evitare slq inj e cracker è usare delle librerie JS md5 etc...

Pensate che avere un login senza queste funzionalità sia "pericoloso"?

[Dirk Pitt]

L'SQL injection lo combatti facendo l'escape dei caratteri.
Vale a dire, nella pagina che riceve i dati dal form, dopo aver aperto la connessione al db, fai l'escape delle variabili POST:

connessione aperta...
$variabile1 = mysql_real_escape_string($_POST["campo_form1"]); 

[DrugsMatt]

Originariamente inviato da rickynewtek
si grazie alla fine c'era arrivato, visto che ci sono vi chiedo una cosa:

Ho letto in giro che uno dei metodi più sicuri per evitare slq inj e cracker è usare delle librerie JS md5 etc...

Pensate che avere un login senza queste funzionalità sia "pericoloso"?

Quoto Dirk Pitt sull'escape.

Per quanto riguarda l'md5 è sempre bene usare questo tipo di codifica hash per salvare nel database informazioni sensibili come le password, così anche se ci fosse una fuga di informazioni l'hacker avrebbe vita difficile a risalire al reale valore della password.

[Dirk Pitt]

Originariamente inviato da DrugsMatt
Quoto Dirk Pitt sull'escape.

Per quanto riguarda l'md5 è sempre bene usare questo tipo di codifica hash per salvare nel database informazioni sensibili come le password, così anche se ci fosse una fuga di informazioni l'hacker avrebbe vita difficile a risalire al reale valore della password.

Anche perchè il procedimento inverso non esiste

[DrugsMatt]

Originariamente inviato da Dirk Pitt
Anche perchè il procedimento inverso non esiste

Si, però potrebbe sempre ricorrere a un dizionario di parole e cercare le corrispondenze con uno script batch, aimè non si è mai completamente al sicuro! Anche se comunque l'hash lo si può complicare notevolmente..

[Dirk Pitt]

Se poi le password sono del tipo "1234"...
Vero è che se il malintenzionato ha in mano tutte le password "hashate", è perchè ha accesso al db. A quel punto di carpire le password degli utenti penso diventi inutile

[simotenax]

aggiungo che per evitare SQLinjections meglio utilizzare la codifica UTF-8 piuttosto che le varie latin; questo perchè per quelle codifiche esistono delle combinazioni di caratteri che non vengono strippate dal mysql_real_escape_string ma che una volta eseguiti in una query vengono trasformate in apici permettendo così l'sql injection.

inoltre ti consiglio di testare anche i casi con i commenti tramite sql in modo da verificare che le tue query per l'autenticazione siano sempre sicure.

[DrugsMatt]

Originariamente inviato da simotenax
aggiungo che per evitare SQLinjections meglio utilizzare la codifica UTF-8 piuttosto che le varie latin; questo perchè per quelle codifiche esistono delle combinazioni di caratteri che non vengono strippate dal mysql_real_escape_string ma che una volta eseguiti in una query vengono trasformate in apici permettendo così l'sql injection.

inoltre ti consiglio di testare anche i casi con i commenti tramite sql in modo da verificare che le tue query per l'autenticazione siano sempre sicure.

vero, ma bisogna assicurarsi che sia la pagina/form che il database siano codificati entrambi con la stessa codifica, altrimenti alcuni caratteri, come gli accentati latini, potrebbero non venir scritti affatto nel db. Quindi cautela prima di cambiar codifica!