Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: > > The patch means that auth creds are never sent, only an auth token that's > valid for 20 mins or so, or you could set it to less. The token *is* the cred in that scenario, you can't not send some form credentials. > Can you explain the XSS risk when a client user is not permitted to write > HTML content to be stored by the app? The malicious code doesn't have to be stored in the app being attacked. Typically its part of a URI pointing to the app to attack and includes the xss payload. That URI however could be found any number of places... social engineering usually comes into play then to get the victim to click on it. While its typically easier to convince users to click a link if it comes from the same site it appears to be going to, (think about message board systems like slash where where hyperlinks in comments are usually suffixed by [domain.com] to give the user the ability to avoid goatse and such) in the end, what dictates the likelyhood of attack is the value of the service more than anything. [Sadly this doesn't dictate the likely hood of XSS holes getting reported on security lists, where people frequently post every about silly little backwater application they can find.] > >restrictions, etc. but few people will go through the trouble, and I'd > >wager most people using the various cookie-based auth folder products > >don't even know the risks. > > This I'd agree with, but I find the argument "this car's breaks only let me > stop in 1 mile, so there's no point in changing them so I can stop in 0.5 > miles" a poor one... Well, knock yourself out, I mean, clearly auth techniques based around cookies need a lot of additional protection. Those same protections, if written modularly, can usually be used to bolster HTTP auth as well, so there's no harm in writing them. Its convincing people to actually use the damned things thats the problem. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Jamie Heilman wrote: The problem of using cookies for auth creds is a little more complex than that. The reality is, in a well written application, cookies should never be used to store auth creds, even if you only send them over SSL. The patch means that auth creds are never sent, only an auth token that's valid for 20 mins or so, or you could set it to less. The reason is that client side scripting languanges are usually permitted access to cookie structures whereas they are explicitly forbidden access to auth cred structures. This is one of the main things that makes cross-site scripting attacks dangerous. Can you explain the XSS risk when a client user is not permitted to write HTML content to be stored by the app? restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. This I'd agree with, but I find the argument "this car's breaks only let me stop in 1 mile, so there's no point in changing them so I can stop in 0.5 miles" a poor one... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [patch] More secure cookie crumbler?
Chris Withers wrote: > PS: To make cookie auth properly secure, you really need to be working over > SSL only, and in addition, you should tweak CookieCrumbler further so that > it sets the secure session bit, meaning your sessions should only get > returned over a secure connection... mindyou, to get basic auth to be even > vaguely secure, you also need to be working over SSL ;-) The problem of using cookies for auth creds is a little more complex than that. The reality is, in a well written application, cookies should never be used to store auth creds, even if you only send them over SSL. The reason is that client side scripting languanges are usually permitted access to cookie structures whereas they are explicitly forbidden access to auth cred structures. This is one of the main things that makes cross-site scripting attacks dangerous. ...and given that Zope is already highly susceptible to cross-site scripting attacks... Of course you can limit the potential for serious damage with aggressive expiration, source address restrictions, etc. but few people will go through the trouble, and I'd wager most people using the various cookie-based auth folder products don't even know the risks. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [patch] More secure cookie crumbler?
Hi Shane and zope-dev,
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a
little more secure.
It makes CookieCrumbler not store the user's password and username on the
browser side and rotates the token stored on the browser side ever 10 seconds or
time between request, whichever is longer. It also provides a session timeout
controlled by the server.
I thought I'd post it here so people could have a look and let me know what you
think.
If the patch is sound, it'd be great to see the patch make it into the next
release of CookieCrumbler, and maybe the CMF and Plone HEADs?
cheers,
Chris
PS: To make cookie auth properly secure, you really need to be working over SSL
only, and in addition, you should tweak CookieCrumbler further so that it sets
the secure session bit, meaning your sessions should only get returned over a
secure connection... mindyou, to get basic auth to be even vaguely secure, you
also need to be working over SSL ;-) (and you should never let your users change
their password without some other form of authentication, or at the very least
making them enter their old password in the same atomic operation as setting
their new password ;-)
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
Index: CookieCrumbler.py
===
--- CookieCrumbler.py (revision 207)
+++ CookieCrumbler.py (working copy)
@@ -24,17 +24,39 @@
from AccessControl import getSecurityManager, ClassSecurityInfo, Permissions
from ZPublisher import BeforeTraverse
import Globals
+import threading
from Globals import HTMLFile
from zLOG import LOG, ERROR
from ZPublisher.HTTPRequest import HTTPRequest
from OFS.Folder import Folder
+from BTrees.OOBTree import OOBTree
+from time import time
-
# Constants.
ATTEMPT_NONE = 0 # No attempt at authentication
ATTEMPT_LOGIN = 1 # Attempt to log in
ATTEMPT_RESUME = 2 # Attempt to resume session
+# set this to 0 to get "old style" sessioning
+more_secure = 1
+
+# the default store of session information, for "more secure" sessioning
+lock = threading.Lock()
+session2ac = OOBTree()
+session2reset = OOBTree()
+time2session = OOBTree()
+import random
+try:
+jn = random.randint(0,2L**160)
+def getRandom():
+return hex(random.randint(0,2**160))[2:-1]
+except:
+# python < 2.3
+jn = random.random()
+def getRandom():
+return str(random.random())[2:]
+random.jumpahead(jn)
+
ModifyCookieCrumblers = 'Modify Cookie Crumblers'
ViewManagementScreens = Permissions.view_management_screens
@@ -115,9 +137,74 @@
return getattr( self.aq_inner.aq_parent, name, default )
security.declarePrivate('defaultSetAuthCookie')
-def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ):
-resp.setCookie( cookie_name, cookie_value, path=self.getCookiePath())
+security.declarePrivate('defaultGetAuthCookie')
+security.declarePrivate('defaultExpireOldSessions')
+if more_secure:
+def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ):
+session = getRandom()
+global session2ac
+global session2reset
+global time2session
+lock.acquire()
+session2ac[session]=cookie_value
+# tweak this for session expirey time
+t = time()
+expiretime = t+20*60 # 20 mins
+if not time2session.has_key(expiretime):
+time2session[expiretime]=[]
+time2session[expiretime].append(session)
+# cookie reset time (this allows rotating session values
+# while still letting simultaneous requests such as ZMI
+# keep working)
+session2reset[session]=t+10 #10 secs
+lock.release()
+resp.setCookie( cookie_name, session, path=self.getCookiePath())
+def defaultGetAuthCookie( self, resp, cookie_name, acc ):
+lock.acquire()
+ac = session2ac.get(acc,None)
+if ac is None:
+lock.release()
+method = self.getCookieMethod( 'expireAuthCookie'
+ , self.defaultExpireAuthCookie )
+method( resp, cookie_name=self.auth_cookie )
+return None
+t = session2reset[acc]
+lock.release()
+if t___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
