On 15 Jun 01 at 12:52, zimageat_private wrote: > > When the request comes in, check if the incoming ticket matches the > > one stored in this user's session. If it does, this particular user > > was given the offer by our server, and not by anyone else. To spoof > > this system, someone would have to guess or otherwise find out what > > ticket value the victim was given by the server. > > > > To make it harder to find the ticket value given to a user, you could give > > the user many tickets, one for each possible action. This solution would > > require a "ticket pool" in the user's session. I've implemented the > > latter solution in both PHP and Java. Let me know if you would like some > > code. (It's not at all hard to implement, of course.) > > > > > > Sverre. > My company implemented this but went one more step. They created a file > that had (IP, ticket) pairs. The ticket was passed around in URLs, but ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^(1) > wasn't valid unless it came from the specific IP. To pretend to be > someone else, one would have to spoof their IP and guess the value of ^^^^^^^^^^^^^^(2) ^^^^^^^^^^^^^^^(3) > their (10 hour life-cycle) ticket. We did this, originally, because we > wanted to support web browsers that didn't use cookies. The file was, > actually, more like (IP, ticket, cookie-type-options-and-settings). It > worked well for us. (2) should be extended with "or to use the same proxy". (3) becomes much more simple due to (1), especially because if you allow inline images, the browser will supply the ticket in "Referer:" header when requesting the image. So, in many cases this extra step gives more cons than pros. But if sending such tickets via POST instead of URLs, this step is a good thing. ___________________________________________________________________ Dmitry Yu. Bolkhovityanov | Novosibirsk, RUSSIA phone (383-2)-39-49-56 | The Budker Institute of Nuclear Physics | Lab. 5-13
This archive was generated by hypermail 2b30 : Mon Jun 18 2001 - 23:00:19 PDT