On Thu, 20 Jan 2011 16:57:52 -0500, Celejar wrote: > On Thu, 20 Jan 2011 15:26:31 +0000 (UTC) Camaleón wrote: > >> In regards to "http cookie hijacking" the first and foremost a >> programmer would ask himself is "do we really need to *constantly* >> generate a write/ read operations of the cookies for *all* the tasks?". >> On these days, no one of us can browse the web and join to online >> services with a completely cookie disabled browser and that's a bit >> excessive, IMO. >> >> If the data, that now is being exchanged between the server and user's >> computer by means of cookies, is to be stored in the server itself in a >> database, most of theses attacks could be prevented. > > How? However your browser is identifying itself to the server, if > encryption isn't in use, that token can be hijacked.
Well, I already said that the login screen is a "key point" (where the user provides sensible data) and as such has to use a secure channel and enforce data encryption but not the remainder traffic. So the problem here is about identifying the unneeded and avoidable information exchange that flows between the server and the client. Using cookies for tracking/ identifying the user's session can be replaced with another methods or can require additional security measures for verifying the authenticity of the client. Sensible data needs, at least, a secure/encrypted channel... is the user's session ID considered "sensible", okay, then use it but do not abuse of it! >> In addition, enforcing a good policy, like user login session >> regeneration or logouts, also help but these options are not always >> neither implemented nor enforced and most of the new "cloud" services >> rely on full-session encryption to simplify things. > > Again, I'd certainly want full-session ideally, to avoid MITM and > similar threats. I can see that many of the new "cloud services" need to use encryption to protect their users but not all the sections of the sites require the same level of confidentiality, neither all the actions do, i.e., do you need to use a secure channel when performing a google search, browsing digg, reading slashdot or even posting to this mailing list? What I mean is that enforcing a 100% https policy without a notion of what we want to prevent would be like telling people that whenever they are going shopping and use their plastic credit card, tell the seller "please, do not look at it" to avoid him getting the numbers >:-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2011.01.21.12.44...@gmail.com
