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. The only way around this is to have separate "/public" and "/authenticated" spaces within your app's URI space and set all cookies to apply only to the "/authenticated" space. This isn't a viable solution these days, however, as it means that documents in the "/public" space will have absolutely no access to any information regarding the user or his session, so it won't be able to do things that users have become accustomed to, such as showing who you're logged in as (or even whether you're logged in at all, making any "login" or "logout" links within the "/public" space problematic, at best). (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.) > 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. -- Dave Sherohman -- 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/20110121092126.gh3...@sherohman.org
