Autenticazione HTTP

[skjobax]

Salve a tutti...
Siccome sto creando uno script molto delicato, ho messo il file class.php a cui si riferisce in un sito e quello che lo usa in un altro..

Per garantire la migliore protezione ho inserito un .htaccess che richiede nome utente e password..
Come è possibile eseguire la login via PHP?

[clickeweb]

Ciao skjobax,

è una bella domanda la tua...

cercando su googole ho trovato questa guida

http://<br /> <a href="http://www.e...ess/</a><br />

anche se non credo che sia la risposta giusta alla tua richiesta.

Cerco di approfondire se trovo qualche soluzione..

[skjobax]

Grazie del tuo link, ho trovato questo:

http://adminassword@192.168.1.1/

Ma siccome è XSS non vorrei usarlo.
Inoltre presenterebbe una falla nella sicurezza, dato che scrivo pubblicamente user e password nel php che magari si può hackerare...

Troverò un' altra soluzione, ma rimango dell'idea che nulla è perfettamente protetto...

[k.b]

Per gestire un sistema di autenticazione via PHP, nella versione piu' semplice, ti servono queste componenti:

- un posto in cui registrare le credenziali degli utenti registrati (tipicamente una tabella di un database)
- un form in cui l'utente inserisce user e password
- uno script PHP che riceve queste informazioni e le confronta con quelle memorizzate e, in caso positivo, imposta qualche variabile che permetta all'utente di accedere alle risorse protette senza dover ripetere user e pass per ogni pagina (cioe' cookie o variabili di sessione)
- una parte di codice in tutte le pagine da proteggere che verifichi che le variabili di cui sopra (cookie o sessione) siano correttamente impostate in modo da consentire l'accesso solo in quel caso

Non e' esattamente una cosa banale, visto che ci sono molti dettagli di cui e' necessario tenere conto per quanto riguarda la sicurezza, ma la struttura base del sistema e' quella e sono sicuro che ci sono molte guide che spiegano il processo nel dettaglio. E' un po' troppo lungo per riassumerlo in un post di un forum, ti consiglio di documentarti ed eventualmente chiedere se hai dubbi specifici.

[skjobax]

In realtà usare cookie è sconsigliatissimo in faccia alla sicurezza, mentre le session, che sono server, sono più sicure.

Infatti non avevo pensato alle session...
Posso inserire un controllo della $_SESSION nel file class.php o magari fare una check-if-not-defined...

O forse ambedue...

Grazie del vostro aiuto

[k.b]

Originariamente inviato da skjobax
In realtà usare cookie è sconsigliatissimo in faccia alla sicurezza, mentre le session, che sono server, sono più sicure.

Questa e' una baggianata colossale, anche perche' indovina come viene propagato l'id delle sessioni (hint: tramite un cookie)?

L'unico problema e' se registri nei cookie informazioni IN CHIARO, ma quello e' un problema dell'incompetenza dello sviluppatore, non dei cookie.

[skjobax]

Intendevo appunto quello...
Dovrei criptare le info e fare un check, ma non voglio utlizzare algoritmi conosciuti e se li creo io è un casino...

[k.b]

Originariamente inviato da skjobax
Intendevo appunto quello...
Dovrei criptare le info e fare un check, ma non voglio utlizzare algoritmi conosciuti e se li creo io è un casino...

Non devi criptare, devi usare algoritmi di hashing, cosa che devi comunque fare a meno che tu non voglia registrare le password in chiaro nel database.

Non c'e' nulla che renda tecnicamente piu' sicure le sessioni rispetto ai cookie ai fini dell'autenticazione, salvo - come detto - l'incompetenza di chi scrive il codice.

[Santino83_02]

ma che stai facendo un sito per una banca?

comunque, tanto per avere un pò più di sicurezza in più:

- https
- SESSION

stavo per scrivere altro, poi ho trovato questo su wikipedia che dà un bello spunto:

Methods to prevent session hijacking include:

- An open source solution is ArpON "Arp handler inspectiON". It is a portable ARP handler which detects and blocks all man-in-the-middle attacks through ARP poisoning and spoofing attacks with a static ARP inspection (SARPI) and dynamic ARP inspection (DARPI) approach on switched or hubbed LANs with or without DHCP. This requires an agent on every host that is to be protected.

- Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.

- Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after he has logged in.

- Encryption of the data passed between the parties; in particular the session key. This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack.

- Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.

- Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, preventing the back button from working properly, on the web).
Users may also wish to log out of websites whenever they are finished using them.[2][3]

i punti più ragionevoli, a mio avviso, sono il 2°, 3°, 4° e 5°, (anche se il 4°, criptare i dati, non so se è superfluo usando l'https). Sostanzialmente confrontare gli ip che usano la session può evitare l'attacco dall'esterno, e la "paura" che gli utenti possano essere buttati fuori a metà sessione per il cambio di ip, beh, secondo me è molto remota o comunque potrebbe essere un rischio accettabile.

fonte: http://en.wikipedia.org/wiki/Session_hijacking

[nickcv]

le sessioni inoltre non sono così sicure se non ti difendi da attacchi di tipo session fixation o se comunque il server è condiviso e tutti hanno accesso al punto in cui vengono salvate le sessioni sul server...

come dice kb tutto dipende dall'intelligenza dello sviluppatore.