Sistema di accesso basato sul database SOAP

Question

Sistema di accesso basato sul database SOAP

#1 da (2 voti)

0

Recentemente mi è stato contestato di creare un framework Login che contiene i dati dell'utente in un database separato che connetto tramite una connessione SOAP. Ora, ho fatto qualcosa in questo senso prima di usare solo MySQL.

Ora, per creare il sistema di login, memorizzo le informazioni utente restituite in $_SESSION variabili; Restituiscono la password in testo semplice (insieme ad altre informazioni) - non sono sicuro del perché - tuttavia, non memorizzo la password in testo semplice; piuttosto crittaggio la password con una chiave univoca per ogni utente.

Per verificare se l'utente è attualmente connesso, utilizzo le loro sessioni utilizzando 2 diversi parametri hash e confrontati con logged_in__string che viene eseguita al login; questa è la configurazione di base:

$_SESSION['logged_in__string'] = hash ( 'sha512', 'USER_PASSWORD' . $_SERVER['HTTP_USER_AGENT'] );

Dopo averlo creato, crittografo la password utilizzando una chiave univoca per ogni utente; Quindi crea una nuova funzione, check() che decrittografa la password e crea il valore hash confrontandolo con $_SESSION['logged_in__string'] e, se uguale, l'utente ha effettuato l'accesso.

Il mio interesse è nelle variabili $_SESSION . Quali sono alcuni potenziali rischi nell'approccio che ho adottato e, se ce ne sono, quali sono alcuni buoni metodi per proteggere queste sessioni per l'utente.

php session-management

posta Samuel 26.10.2017 - 23:04

fonte

1 risposta

Leggi altre domande sui tag php session-management

Azioni da intraprendere dopo l'apertura del sospetto PDF Come è possibile che non possiamo davvero tracciare il server C & C (o altri server nascosti)?

score 2 · Accepted Answer

Hash le tue password

Prima di tutto, sembra che il database memorizzi la password in testo semplice. Questo è molto, molto, molto cattivo. Vedi questa domanda per sapere come farlo nel modo giusto.

Il problema con il tuo sistema

Ora, alla tua domanda attuale. Lo scopo del tuo sistema è quello di fermare il dirottamento di sessione. Tuttavia, non fa nulla del genere. Se rubo uno dei cookie di sessione degli utenti e lo mando in una richiesta al tuo server, come sapresti che è stato rubato? Tutto ciò che fa il tuo sistema è decifrare la password che l'utente reale ha fornito al momento del login e verificare che sia corretta, quale sarà sempre. Il tuo sistema si riduce fondamentalmente a verificare che password = password con un po 'di "polvere magica crittografica cosparsa sopra" (per citare Androl Genhald ).

Per vedere questo, scrivi il tuo sistema in pseudo codice semplificato e poi controlla come si comporterebbe il server in caso di attacco con carta e penna. Trovo che sia una tecnica utile per problemi come questo.

Un po 'oltre il punto, ma: usare solo un round di SHA-256 non è sufficiente per le password di hashing. E memorizzare i dati crittografati e la chiave nello stesso posto non è una buona idea.

La soluzione

Semplificalo:

$_SESSION['logged_in'] = true

Quindi, per proteggersi contro il dirottamento di sessione, puoi fare quanto segue:

Utilizza un buon HTTPS.
Assicurati che i tuoi ID di sessione abbiano sufficiente entropia.
Contrassegna il cookie di sessione come sicuro e solo HTTP.
Attenzione per XSS.

Il sistema si assicura anche che l'agente utente rimanga costante durante una sessione. Questa è solo una protezione limitata poiché l'interprete può essere facilmente falsificato, ma potrebbe essere di aiuto nei confronti di un aggressore non sofisticato. Se si desidera mantenere tale controllo, è sufficiente memorizzare l'agente utente originale nella sessione e quindi a ogni richiesta verificare che l'intestazione dell'agente utente sia uguale a quella memorizzata.