Login sicuro e livelli di utenza

[aasmdaa]

Sto progettando un sito intranet in un'azienda e tornano i soliti dubbi:

1) pur avendo cercato ovunque sul web e visto diversi articoli non ho trovato un sistema di login con le sessioni che sia ben fatto e sia sicuro;
- dato che non verrà utilizzato https:// mi sembra di capire che i dati che partono dal form fino ad arrivare al serve passano comunque in chiaro quindi ci sia poco da fare;
- utilizzare un javascript per criptare non lo trovo con molto senso dato che se un utente ha js disabilitato il sistema non funziona;
- è il caso di controllare i dati provenienti dal form con un htmlspecialchars?
- è il caso di criptare la password prima di inviarla al form?
- ci sono ulteriori metodi da implementare in MySQL per aumentare la sicurezza nella lettura/scrittura dei dati nel db?

2) una volta creato un buon login posso stare tranquillo utilizzando esclusivamente delle variabili di sessione per far accedere o meno ad alcune pagine del sito (in pratica ogni utente avrà un livello che gli permetterà di visualizzare o meno alcune parti di sito)

Ho letto anche questo articolo http://php.html.it/articoli/leggi/90...tenti-con-php/ ma è molto vecchio (2004). C'è qualcosa di simile ma più aggiornato?

[Samleo]

Per un buon login, io ti direi di utilizzare AJAX.

Sembra una stupidata, ma aiuta, anche a livello di sicurezza!

[aasmdaa]

Intendi qualcosa come questo?

http://php.html.it/articoli/leggi/22...in-ajax-e-php/

Ma se javascript è disattivato sul client non funziona...

[DKiller92]

Originariamente inviato da aasmdaa
Intendi qualcosa come questo?

http://php.html.it/articoli/leggi/22...in-ajax-e-php/

Ma se javascript è disattivato sul client non funziona...

Se l'utente ha JS disabilitato non può neanche loggarsi

Comunque in linea di massima:
- Fai l'escape delle stringhe che arrivano dal form e devono essere inserite in query
- Se devi stamparle, passale prima con htmlentities()
- Le password che metti in database passale 2 volte tipo sha1(md5($stringa))
- Controlla sempre che le richieste arrivino dal tuo sito per evitare Cross Site Request Forgery
- Se vuoi avere una sicurezza estrema, fai scadere le sessioni dopo 10-20 minuti di inutilizzo.
- Controlla se un accesso di uno stesso utente viene fatto contemporaneamente con 2 ip diversi, in tal caso fai reinserire la password
- Se hai pagine del tipo news.php?id=X che vanno a pescare da un database, controlla SEMPRE la variabile X, se deve essere numerica mettici is_number() ecc...
- Evita include arbitrari tipo: index.php?include=pagina.php

Poi boh chi più ne ha più ne metta

[aasmdaa]

Grazie. Serie di consigli molto utili. Se ce ne sono altri ben vengano.

'Controlla sempre che le richieste arrivino dal tuo sito per evitare Cross Site Request Forgery'

questo controllo a cosa serve e come si effettua?

[DKiller92]

Originariamente inviato da aasmdaa
Grazie. Serie di consigli molto utili. Se ce ne sono altri ben vengano.

'Controlla sempre che le richieste arrivino dal tuo sito per evitare Cross Site Request Forgery'

questo controllo a cosa serve e come si effettua?

In sostanza, se per esempio una delle pagine accessibili solo da admin del tuo sito fosse:
index.php?action=cancellasito
e la sua visita comportasse la cancellazione del sito, un esterno malintenzionato potrebbe mandarti una mail per esempio con il link che punta a quella pagina nascosto, inducendoti a cliccarvi e cancellare il sito, perchè tu sei l'admin.
Non sono molto bravo a spiegarmi, però spero di essere stato chiaro

Al massimo leggi questi link che sono molto più dettagliati

http://fatmatt.wordpress.com/2007/11...quest-forgery/
http://php.html.it/guide/lezione/299...est-forgeries/

[aasmdaa]

Ah ok è chiaro. grazie.

Invito anche altri che avesse ulteriori dritte/controlli da aggiungere ad un login ben fatto a proseguire la lista... ;-)

[oly1982]

Originariamente inviato da DKiller92
evitare Cross Site Request Forgery

sono interessato all'argomento e, leggendo uno dei link, ho pensato ad una cosa di questo genere

function protection_cross_request()
    {
    if (isset($_SERVER['HTTP_REFERER']) && $_SERVER['HTTP_REFERER']!="")
        {
        if (strpos($_SERVER['HTTP_REFERER'],$_SERVER['HTTP_HOST'])===FALSE)
            {
            return FALSE;
            }
        else
            {
            return TRUE;
            }
        }
    return FALSE;
    }

protection_cross_request() or die ('andò vaiiiii??!');
?> 

Ma la domanda che mi sorge è la seguente:
un utente malintenzionato può agire su HTTP_REFERER modificandolo a proprio piacimento?

oppure peggio ancora...

http://forum.it.altervista.org/php-m...p_referer.html

[oly1982]

mi rispondo da solo dopo qualche ricerca sul web e chiedo vostra conferma per sapere se ho capito bene...
$_SERVER['HTTP_REFERER'] è una info carpita attraverso gli header inviati dal browser al nostro server... E' UNA INFO PROVENIENTE DAL CLIENT (e già questo la dice lunga)

Inoltre come se non bastasse alcuni (fottuttissimi) browser per ragioni di sicurezza (la loro!!) 'nascondono' tale dato che, pertato risulta essere vuoto.

Pertanto la funzione postata precedentemente deve avere il return TRUE finale (altrimenti gli utenti con questi browser verrebbero ad essere bloccati) ed in ogni modo risulta essere un controllo 'limitato' dalle suddette ragioni anche se non è del tutto inutile!

[DKiller92]

Originariamente inviato da oly1982
mi rispondo da solo dopo qualche ricerca sul web e chiedo vostra conferma per sapere se ho capito bene...
$_SERVER['HTTP_REFERER'] è una info carpita attraverso gli header inviati dal browser al nostro server... E' UNA INFO PROVENIENTE DAL CLIENT (e già questo la dice lunga)

Inoltre come se non bastasse alcuni (fottuttissimi) browser per ragioni di sicurezza (la loro!!) 'nascondono' tale dato che, pertato risulta essere vuoto.

Pertanto la funzione postata precedentemente deve avere il return TRUE finale (altrimenti gli utenti con questi browser verrebbero ad essere bloccati) ed in ogni modo risulta essere un controllo 'limitato' dalle suddette ragioni anche se non è del tutto inutile!

Spesso infatti viene utilizzato anche un altro metodo per proteggersi da CSRF.
Praticamente ogni richiesta deve essere accompagnata dall'id di session.

Esempio:

PAGINA VALIDA

index.php?act=cancellasito&sid=0245485754

PAGINA NON VALIDA

index.php?act=cancellasito

Se non è chiaro domandate pure