ID sessione sul codice sorgente html della pagina

2

Voglio sapere se è pericoloso in qualsiasi modo memorizzare l'ID della sessione utente loggato corrente sul codice sorgente generato dalla pagina.

Perché volevo farlo?

Sto provando a condividere la sessione utente tra due applicazioni, una (la principale) in PHP e un'altra in Node.js. Il Node.js viene utilizzato solo per i dati in tempo reale, ma voglio solo inviare dati in tempo reale agli utenti registrati nell'applicazione PHP.

Poiché gli ID di sessione sono memorizzati in un'istanza Redis accessibile sia per PHP che per Node, posso semplicemente inviare l'ID di sessione dal client al Node.js (usando la messaggistica websockets).

Perché non utilizzare i cookie già presenti nel browser utente?

L'applicazione Node viene servita utilizzando un host diverso. Quindi il cookie non sarà disponibile.

    
posta JCM 29.01.2014 - 23:08
fonte

4 risposte

3

vi è un rischio introdotto includendo l'identificatore di sessione del codice HTML poiché renderà più semplice sfruttare le vulnerabilità XSS per dirottare le sessioni.

Per prima cosa, l'accesso all'ID di sessione da JavaScript è CATTIVO PRATICO , i cookie dovrebbero avere il flag HTTPONLY per impedirlo.

Nel tuo caso, anche se il flag HTTPONLY è impostato, l'identificatore di sessione nel corpo della pagina rende più facile l'accesso a questo identificatore mentre sfrutta l'XSS e quindi ignora l'HTTPONLY.

    
risposta data 30.01.2014 - 01:13
fonte
1

Se il codice è privo di bug e non è soggetto a correzioni di sessione o XSS e vi si accede tramite HTTPS con cookie sicuri, probabilmente è OK - ma è un compito molto alto da raggiungere e mantenere. Quando si rompe sarà davvero difficile rilevare / testare / correggere eventuali problemi. La soluzione che proponi è molto fragile.

La migliore soluzione per condividere una sessione tra diversi stack di applicazioni è quella di fornire loro l'accesso tramite lo stesso vhost - in questo modo non c'è confusione con la messaggistica per gestire il problema dei cookie - ci sono prodotti validi e stabili disponibili per fare questo - Molti dei quali sono gratuiti (Varnish, Nginx, Apache Traffic Server).

In alternativa dovrebbe essere possibile riprodurre un'architettura di tipo SSO per condividere la sessione tra diversi vhosts.

    
risposta data 30.01.2014 - 11:22
fonte
0

Utilizzi HTTPS per le risposte di entrambi gli host? Se è così, non c'è alcun pericolo particolare. In caso contrario, hai appena esteso il potenziale per il dirottamento di sessioni che esisteva già per te host PHP e Node (a causa dei cookie di sessione) su tutte le richieste sia per gli host PHP che per quelli Node.

Finché usi SSL, qui sei relativamente al sicuro. Se non si utilizza SSL e sono in gioco dati sensibili, non lo è.

    
risposta data 29.01.2014 - 23:16
fonte
0

Probabilmente dovresti provare una richiesta Ajax dal tuo codice php per aggiornare il tuo client sui dati live inviati al tuo server comune. Ciò mantiene tutte le preoccupazioni separate, e non crea inutilmente un requisito che il codice php sia legato a una fonte.

    
risposta data 01.02.2014 - 03:59
fonte

Leggi altre domande sui tag