On Fri, 21 Jan 2011 03:21:26 -0600, Dave Sherohman wrote: > On Thu, Jan 20, 2011 at 03:26:31PM +0000, 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?". > > Unfortunately, if the site is to exist within a single base URI, yes, we > do need to *constantly* read cookies. That's the way browsers work - if > the browser holds any cookies related to a given URI, it will send those > cookies on *every* request to that URI. The cookies are not requested > on a per-fetch basis by the server.
But not for all the tasks! This "cookie policy" is being enforced by "companies", but it is not a programming requirement. Let me put a simple and illustrative example with the Googe search engine. To avoid using their "instant" search facility, you can: - Accept a cookie - Use this URI: http://www.google.com/webhp?complete=0&hl=en Why Google prefers using cookies is something we all here should "guess": tracking the users. Is it licit...? Yes, but in the end, this is not a technical based policy ("we do this way because we cannot do it in another way"), it's a marketing policy. (...) > (Well, OK, there is one other way around it: Discard the stateless HTTP > protocol and replace it with a protocol based on persistent connections > so that you don't have to fake persistence by using cookies to > re-identify yourself every time you talk to the server, but there's no > way that's happening any time soon.) Which reminds me the current state of the old "smtp" protocol. Instead of getting a complete redesign of it (it is broken by design) we are still looking for bypasses (like SPF, domainkeys or dkim implementations...) to avoid spam, prevent user usurpation and keeping message integrity. >> 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. > > Any decent site will only use a single cookie containing a random > session ID and store all additional data on the server itself, keyed to > that ID. In this (extremely common) scenario, the only thing being > exchanged between the server and the user's computer by means of cookies > is this identification token; storing it solely on the server and not > repeatedly exchanging it would mean that the server is not able to > identify the user. Then encrypt it at login and apply additional measures to prevent it can be hijacked, but you need to be aware that just by using ssl you are not completely safe against all kind of attacks. Look: *** http://en.wikipedia.org/wiki/HTTP_cookie#Drawbacks_of_cookies "... A different way to steal cookies is cross-site scripting and making the browser itself send cookies to malicious servers that should not receive them. Modern browsers allow execution of pieces of code retrieved from the server. If cookies are accessible during execution, their value may be communicated in some form to servers that should not access them. Encrypting cookies before sending them on the network does not help against this attack.[37] *** 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.13.20...@gmail.com
