Integrazione sicura dell'autenticazione PHP e WebSocket

Question

Integrazione sicura dell'autenticazione PHP e WebSocket

#1 da (1 voti)

1

Ho un server PHP che esegue un sito web e il sito web ha funzioni come le notifiche in tempo reale, che sono fondamentalmente notifiche che ti vengono inviate una volta che un utente ha gradito o commenti su uno dei tuoi post, dal vivo.

Ho deciso di utilizzare WebSocket per questo, solo per la pratica. Per utilizzare WebSocket, ho bisogno di autenticare l'utente e usare le sue informazioni per ottenere e fornire dati ad altri utenti connessi.

Fase uno

So che PHP ottiene l'ID di sessione dell'utente che ha effettuato l'accesso dai cookie e utilizza quell'ID per recuperare il suo file di sessione, che contiene il suo id utente.

Ho pensato di salvare l'ID di sessione in un database, collegato all'ID utente, e quindi quando la connessione websocket si inizializza, invio l'id della sessione cookie e quindi il server websocket controlla l'ID inviato dal database.

Fase due

Se ti piace o commenta un post, hai bisogno di un qualche tipo di servizio che lo gestisca, se puoi o meno commentare e cosa fa quando provi a farlo, e secondo me dovrebbe essere logica fatto sul server web, sul progetto PHP.

Ciò che ho pensato di fare è prima di tutto inviare una XMLHttpRequest quando ti piace o commentare un post e quella richiesta restituisce lo stato, se ha esito positivo o negativo. Se ha esito positivo, la risposta conterrà l'ID del post o simile e verrà inviata al server websocket e il server avviserà tutti gli utenti dopo aver verificato che è reale.

Riesci a trovare qualche difetto in una di queste fasi? Sto pensando nel modo giusto?

php websocket

posta Ben Beri 20.07.2018 - 10:14

fonte

1 risposta

Leggi altre domande sui tag php websocket

OIDC - qual è il punto di due token separati - accesso e id? E 'possibile specificare più valori per la condizione di errore (F =) usando Hydra?

score 1 · Answer 1

[...] if you can like or comment, and what it does when you try to do that, and in my opinion that logic should be done on the web server, on the PHP project.

Oh assolutamente. Altrimenti si implementeranno i controlli sul lato client, nel qual caso l'applicazione web decide, se l'utente è autorizzato a commentare / come un determinato post. Puoi farlo ma anche controlli lato server implementativi! Altrimenti nulla mi impedisce di fingere di essere un altro utente e di inviare la richiesta direttamente senza utilizzare la tua app web. I controlli sul lato client non dovrebbero mai essere usati come unica misura di sicurezza.

Implementerei anche una sorta di politica di una connessione per utente. Nel caso qualcuno rubi / indovina l'ID sessione dell'utente, può stabilire una connessione web-socket e magari persino usare gli altri endpoint (a seconda di come sono autenticati). Questo è un punto debole, poiché la connessione web socket può essere stabilita (e altri endpoint possono essere utilizzati) semplicemente lanciando un ID sessione valido sul server (indipendentemente dal nome utente / password nello scenario!). Assicurati che le sessioni scadano dopo X minuti e gli ID di sessione sono molto più difficili da indovinare della password (ad esempio utilizzando una funzione di hash crittografica o un generatore di numeri casuali sicuro).

Permettendo un solo Websocket per ogni ID di sessione (e solo una sessione attiva per utente?) impedisce a un utente malintenzionato di dirottare una sessione utilizzata in modo non notato.

Come al solito " non eseguire il rollover della tua crittografia " (se pensi di utilizzarlo come software di produzione). Come hai già detto che "PHP ottiene i dati dell'utente dall'ID di sessione", presumo tu stia usando una sorta di framework, dato che PHP non lo fa da solo. Forse la funzione di autenticazione è già implementata.

tl; dr

Implementa tutti i controlli di sicurezza almeno sul lato server (lato client è Esperienza utente, non sicurezza)
Assicurati che l'ID sessione indovinare non sia fattibile. Ciò include la pulizia delle sessioni che non sono più in uso. Forse una norma che impone una sessione per utente e una connessione web socket per sessione se adatta al tuo caso d'uso. Quindi nessuno può dirottare una sessione inosservata.