sessioni solo con i cookie, perchè?

[daniele_dll]

Originariamente inviato da cescoh
anche io intendevo dire controllo sia del SID che dell'IP.

Per le reti NATTATE, il problema non si pone in quanto, anche se credo che sia molto improbabile, se arrivano due client dalla stessa LAN avranno si lo stesso IP ma SID diversi per cui va bene.

si infatti, il problema sorge se uno dall'interno di una lan prova a far danni xche ha lo stesso ip

[Fabio Heller]

Originariamente inviato da daniele_dll
per quanto riguarda i provider americani che cambiano l'ip, non so dove l'hai letto, ma mi sembra surreale perché se cambio l'ip nell'intestazione del pacchetto il picci remoto mi butta l'ip da un'altra parte nella risposta...e quindi o il provider americano ha uno stack tcp/ip modificato con delle tabelle per lo scrambling interne (ed ovviamente l'ip a cui vengono renviati i dati sono comunque suoi) oppure è una bufala xche non è tecnicamente fattibile

Infatti la cosa non avviene esattamente così, ma è ben conosciuta da diverso tempo.
Se prima potevo avere dei dubbi (era per "sentito dire") ne ho trovato una conferma qualche settimana fa in questo libro
http://www.amazon.com/exec/obidos/tg...17410?v=glance


I grossi ISP americani gestiscono i propri utenti attraverso cluster di proxy server, i navigatori possono passare da un proxy all'altro nell'arco di pochi secondi da una request all'altra.

Se puoi accettare di passare l'id attraverso query string in un'area riservata, puoi anche accettare di rinunciare al controllo sugli IP (che fornisce falsi positivi e falsi negativi) e nei casi descritti sopra rende la sessione del tutto inutilizzabile.

[daniele_dll]

Originariamente inviato da Fabio Heller
Infatti la cosa non avviene esattamente così, ma è ben conosciuta da diverso tempo.
Se prima potevo avere dei dubbi (era per "sentito dire") ne ho trovato una conferma qualche settimana fa in questo libro
http://www.amazon.com/exec/obidos/tg...17410?v=glance


I grossi ISP americani gestiscono i propri utenti attraverso cluster di proxy server, i navigatori possono passare da un proxy all'altro nell'arco di pochi secondi da una request all'altra.

Se puoi accettare di passare l'id attraverso query string in un'area riservata, puoi anche accettare di rinunciare al controllo sugli IP (che fornisce falsi positivi e falsi negativi) e nei casi descritti sopra rende la sessione del tutto inutilizzabile.

allora la cosa cambia in maniera seria, in pratica utilizzano il trasparent proxing (non ricordo se si mette la y) e non capisco perché :\ ... se serve per l'anonimità...beh non è molto utile xche fanno sballare tanti sistemi di sicurezza :\

[Fabio Heller]

Originariamente inviato da daniele_dll
allora la cosa cambia in maniera seria, in pratica utilizzano il trasparent proxing (non ricordo se si mette la y) e non capisco perché :\ ... se serve per l'anonimità...beh non è molto utile xche fanno sballare tanti sistemi di sicurezza :\

Da quel che dicono serve per una questione di scalabilità dei servizi, ma qui mi fermo perchè non ne so di più

[daniele_dll]

Originariamente inviato da Fabio Heller
Da quel che dicono serve per una questione di scalabilità dei servizi, ma qui mi fermo perchè non ne so di più

boh e che non capisco a quale scopo fanno una cosa del genere :\

[lordmax]

Ciao da LordMax

Originariamente inviato da daniele_dll
boh e che non capisco a quale scopo fanno una cosa del genere :\

Credo sia più che altro per una questione di bilanciamento delle risorse.
Scambiando il flusso fra i vari proxy riescono ad avere le linee sempre bilanciate fra di loro.

[daniele_dll]

Originariamente inviato da lordmax
Credo sia più che altro per una questione di bilanciamento delle risorse.
Scambiando il flusso fra i vari proxy riescono ad avere le linee sempre bilanciate fra di loro.

mmm non credo sia realmente questo il motivo...xche...a questo punto vuol dire che quegli utenti non hanno ip pubblici
e quindi vuoldire che non è solo per navigare ma per tutto...e quindi ancora mi viene da pensare che siano infrastrutture come fastweb comunque molto ristrette

[cescoh]

Originariamente inviato da Fabio Heller

Se puoi accettare di passare l'id attraverso query string in un'area riservata, puoi anche accettare di rinunciare al controllo sugli IP (che fornisce falsi positivi e falsi negativi) e nei casi descritti sopra rende la sessione del tutto inutilizzabile.

:master: :master: :master:
Non ci capisco più niente!
Questa tua ultima frase proprio non l'ho capita, in particolare cosa significa che il controllo sugli ip fornisce falsi positivi e falsi negativi?

Ciao

[Fabio Heller]

Originariamente inviato da cescoh
:master: :master: :master:
Non ci capisco più niente!
Questa tua ultima frase proprio non l'ho capita, in particolare cosa significa che il controllo sugli ip fornisce falsi positivi e falsi negativi?

Ciao

Volevo dire che rinunciare al controllo sull'ip non è una cosa così grave, sicuramente meno grave di passare l'id via URL in un'area riservata

Falsi positivi e falsi negativi vuol dire che il controllo sull'ip può comportare sia che vengano accettati utenti non validi (stesso ip dietro una LAN) sia che vengano rifiutati utenti validi (ip diverso da parte di uno stesso utente)

[cescoh]

Originariamente inviato da Fabio Heller
Volevo dire che rinunciare al controllo sull'ip non è una cosa così grave, sicuramente meno grave di passare l'id via URL in un'area riservata

Ok, ho capito, lasciamo perdere il controllo dell'IP che effettivamente mi pare che porti più complicazioni che vantaggi.
Vorrei però parlare di protcolli:

L'id lo devo passare comunque per mantenere la sessione, anche se mi muovo in un'area riservata. Che differenza fa (al fine di eventuali sniffaggi) se lo passo via URL o via cookie??, tanto alla fine non è sempre una informazione che viaggia negli header dell'http??

Mi viene un altro dubbio:
attualmente ho progettato il mio carrello per far passare su https tutte le pagine che contengono dati 'sensibili'(login, dati utente, dati pagamento) mentre le altre pagine come il carrello, l'aggiunta o la modifica di prodotti avviene su http.
Posso avere una sessione senza essere logato e quindi fare tutte le operazioni sul carrello, quando voglio pagare devo logarmi, dal quel momento posso pagare (https) ma anche tornare ad aggiungere o modificare i prodotti (http), se a questo punto mi sniffano l'id possono andare nella pagina per variare i dati dell'utente e fare quello che vogliono. O no??
In sostanza mi chiedo: dal momento in cui effettuo il login non sarebbe meglio far passare tutte le pagine su https??

Cescoh