<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3492" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV dir=ltr align=left><SPAN class=062535400-22042009><FONT face="Trebuchet MS" 
color=#0000ff size=2>you may found interesting to check 
this:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=062535400-22042009><FONT face="Trebuchet MS" 
color=#0000ff size=2><A 
href="http://jaspan.com/improved_persistent_login_cookie_best_practice">http://jaspan.com/improved_persistent_login_cookie_best_practice</A></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=062535400-22042009><FONT face="Trebuchet MS" 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=ltr align=left><SPAN class=062535400-22042009></SPAN>&nbsp;</DIV><BR>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader lang=es dir=ltr align=left>
  <HR tabIndex=-1>
  <FONT face=Tahoma size=2><B>De:</B> seaside-bounces@lists.squeakfoundation.org 
  [mailto:seaside-bounces@lists.squeakfoundation.org] <B>En nombre de </B>Nevin 
  Pratt<BR><B>Enviado el:</B> Tuesday, April 21, 2009 21:50<BR><B>Para:</B> 
  Seaside - general discussion<BR><B>Asunto:</B> NAT'd IP's Re: [Seaside] 
  Seaside session stealing<BR></FONT><BR></DIV>
  <DIV></DIV>Sorry to follow up to my own post, but obviously a simple IP check 
  doesn't work for multiple users behind the same router, whose IP got NAT'd to 
  all be the same IP.<BR><BR>So, I'm still thinking a combination of a "remember 
  me" cookie, and an IP check, is still needed.&nbsp; But I accidentally 
  reversed their order in my post below.&nbsp; Here it is again, in proper 
  order:<BR><BR>1. Check for a "remember me" cookie.&nbsp; If a proper "remember 
  me" cookie exists, then the session is NOT stolen.<BR><BR>2. If we don't get a 
  proper "remember me" cookie back from the user, then check to see if cookies 
  are enabled in the user's browser.&nbsp; If they are not even enabled, then 
  default to an IP check-- if the IP is the same, consider that the session is 
  NOT stolen.<BR><BR>3. If the above two checks fail, then assume the session is 
  stolen.<BR><BR>The hole in the above, though, is users whose IP is being 
  NAT'd, *and* have cookies turned off, could hijack sessions between each 
  other.&nbsp; But, for non-banking, non-financial data, this is probably secure 
  enough, and lets the website reach the widest audience, whether they have 
  cookies enabled or not.<BR><BR>At least, that's my 
  thought.<BR><BR>Nevin<BR><BR>
  <BLOCKQUOTE cite=mid:49EE6559.3000303@bountifulbaby.com type="cite">Hi 
    everyone,<BR><BR>Seaside sessions can be "stolen" with something as simple 
    as user's sharing a URL (one person emailing a URL to another person, for 
    example).&nbsp; There are various ways to guard against this problem.&nbsp; 
    This email is a discussion of some of those ways.<BR><BR>The obvious 
    (non)solution is to configure Seaside to use cookies for the session 
    data.&nbsp; The reason I say it is a *non*-solution is because users cannot 
    have more than one window open to your website with this method, because the 
    cookie is shared with all windows of the browser.&nbsp; Also, some users 
    have browser cookies turned off, thereby cutting off all access to a Seaside 
    website that is using session cookies.<BR><BR>Another idea is to look at the 
    IP of the user.&nbsp; But, at one time, AOL users (using AOL's proxy 
    servers) would often have their IP changed with (potentially) *every* 
    request, thus making it completely unpractical to rely on the user's 
    IP.<BR><BR>However, in late 2006, AOL agreed to send <I>X-Forwarded-For</I> 
    headers, which now are supposed to accurately identify AOL users' home IP 
    addresses.&nbsp; Here is a Wikipedia reference for more information on 
    this:<BR><BR>&nbsp;&nbsp; <A class=moz-txt-link-freetext 
    href="http://en.wikipedia.org/wiki/Wikipedia:AOL" 
    moz-do-not-send="true">http://en.wikipedia.org/wiki/Wikipedia:AOL</A><BR><BR>With 
    this change in AOL, I am thinking that *maybe* it is now practical to guard 
    against Seaside session stealing via simple IP checks, with something like 
    the following code:<BR><BR><BR>&nbsp;<TT>&nbsp; | currentAccessIP 
    |<BR>&nbsp;&nbsp;&nbsp; currentAccessIP :=&nbsp; self session currentRequest 
    nativeRequest&nbsp; 
    <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    headerAt: 'x-forwarded-for'<BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    ifAbsent: [].<BR>&nbsp;&nbsp;&nbsp; currentAccessIP ~= lastClientAccessIP 
    ifTrue: ["the Seaside session has been stolen"].<BR></TT><BR><BR>(obviously 
    "<TT>lastClientAccessIP</TT>" would have had to have already been set, via 
    the user's very first hit to the website)<BR><BR><BR>But I'm not sure if 
    this would be sufficient.&nbsp; That's my question to everyone-- do you 
    think IP checks can now be relied upon to guard against session stealing, or 
    not?<BR><BR>I've looked at some PHP code that approached the 
    session-stealing problem with a simple "remember me" cookie.&nbsp; The 
    "remember me" cookie is uniquely set when the user first starts interacting 
    with the website, and then if a subsequent request does not have the cookie, 
    the session is deemed to have been stolen.&nbsp; But, obviously this 
    approach does not work for users that turn cookies off.<BR><BR>Another 
    approach I've wondered about (and seems quite secure) is the 
    following:<BR><BR>1. Use an IP check-- if the IP is the same, the session is 
    NOT stolen.<BR><BR>2. If the IP is different, then check for a "remember me" 
    cookie.&nbsp; If a proper "remember me" cookie exists, then the session is 
    NOT stolen.<BR><BR>3. If the above two checks fail, then assume the session 
    is stolen.<BR><BR>But I'm not sure if something that elaborate is really 
    needed any more.&nbsp; I'm thinking that possibly a simple IP check will 
    suffice these days.&nbsp; But I'm scared to try only doing an IP check, and 
    nothing else :-) :-)<BR><BR>Does anybody else have any thoughts on 
    this?<BR><BR>Nevin<BR><BR>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
    &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <BR><BR><BR><PRE wrap=""><HR width="90%" SIZE=4>
_______________________________________________
seaside mailing list
<A class=moz-txt-link-abbreviated href="mailto:seaside@lists.squeakfoundation.org">seaside@lists.squeakfoundation.org</A>
<A class=moz-txt-link-freetext href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>