Ver Mensaje Individual
  #4 (permalink)  
Antiguo 21/06/2006, 10:42
Cluster
O_O
 
Fecha de Ingreso: enero-2002
Ubicación: Santiago - Chile
Mensajes: 34.417
Antigüedad: 22 años, 3 meses
Puntos: 129
Cita:
Iniciado por B**
Entonces que es mas recomendable.. propagar el SID por URL o por cookies..?
Yo he leido q no es muy fiable por cookies por q aveces el usuario no las tiene activadas.. pero por URL no es seguro tampoco..por q creo q vi q pueden acceder a un directorio y ahi sacarlas..
Tu usarias cookies Cluster? osea, tiene mas ventajas?
Yo propago el SID en Cookies.

Es cierto que si el usuario "paranóico" que no sabe o valoriza de donde viene la cookie que se pretende crear en su equipo .. las bloquea .. no disfrutará de mis aplicaciones. OK .. pero esto es un tema bajo mi punto de vista de avisar a los usuarios y de que estos "sepan" lo que hacen cuando bloquen cookies. (A título personal .. yo bloque cookies ..pero por lo menos sé las que bloqueo y autorizo las de mi confianza de los sitios que sé que me las piden).

Propagar el SID en el URL .. tiene bajo mi punto mas problemas de seguridad vs a "usabilidad" (no depender de que el usuario permita cookies o no ..) y los que detalla este documento (recomendado su lectura por php.net .. por algo será):

Cita:
Sessions and security
External links: Session fixation

The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.

Assess the importance of the data carried by your sessions and deploy additional protections -- this usually comes at a price, reduced convenience for the user. For example, if you want to protect users from simple social engineering tactics, you need to enable session.use_only_cookies. In that case, cookies must be enabled unconditionally on the user side, or sessions will not work.

There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.
http://www.acros.si/papers/session_fixation.pdf

Un saludo,
__________________
Por motivos personales ya no puedo estar con Uds. Fue grato haber compartido todos estos años. Igualmente los seguiré leyendo.