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<time(): + del session2ac[acc] + del session2reset[acc] + method = self.getCookieMethod( 'setAuthCookie' + , self.defaultSetAuthCookie ) + method( resp, cookie_name, ac ) + return ac + + def defaultExpireOldSessions(self): + global session2ac + global session2reset + global time2session + expiretime = time() + lock.acquire() + for t,sessions in time2session.items(0,expiretime): + for session in sessions: + try: + del session2ac[session] + del session2reset[session] + except KeyError: + # it's already gone + pass + del time2session[t] + lock.release() + else: + def defaultSetAuthCookie( self, resp, cookie_name, cookie_value ): + resp.setCookie( cookie_name, quote(cookie_value), path=self.getCookiePath()) + + def defaultGetAuthCookie( self, acc ): + return unquote(acc) + + def defaultExpireOldSessions(self): + pass + security.declarePrivate('defaultExpireAuthCookie') def defaultExpireAuthCookie( self, resp, cookie_name ): resp.expireCookie( cookie_name, path=self.getCookiePath()) @@ -167,15 +254,22 @@ path=self.getCookiePath()) method = self.getCookieMethod( 'setAuthCookie' , self.defaultSetAuthCookie ) - method( resp, self.auth_cookie, quote( ac ) ) + method( resp, self.auth_cookie, ac ) self.delRequestVar(req, self.name_cookie) self.delRequestVar(req, self.pw_cookie) elif req.has_key(self.auth_cookie): + # take the opportunity to potentially delete expired sessions + method = self.getCookieMethod( 'expireOldSessions' + , self.defaultExpireOldSessions ) + method() # Attempt to resume a session if the cookie is valid. # Copy __ac to the auth header. - ac = unquote(req[self.auth_cookie]) - if ac and ac != 'deleted': + acc = req[self.auth_cookie] + if acc and acc != 'deleted': + method = self.getCookieMethod( 'getAuthCookie' + , self.defaultGetAuthCookie ) + ac = method( resp, self.auth_cookie, acc) try: decodestring(ac) except:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it.
PS: To make cookie auth properly secure, you really need to be working over SSL only
I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler. Shane
Shane Hathaway wrote:
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it.
Well, that's a little harsh. The default methods will only work on setups where there's at most one ZEO client accepting web requests for each user. However, all you have to do is drop 3 ZSQL-methods-filtereted-through-python-scripts or python-scripts-using-a-session-data-container and it works across any number of ZEO clients accepting web requests for any user.
PS: To make cookie auth properly secure, you really need to be working over SSL only
I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler.
That was the reason for the long NB/PS at the end of the email. The patch does still prevent the Browser seeing the password of the user, and reduces the chances of session hijacking. With normal cookie crumbler, if you snoop a session, you can keep using it until the user changes their password. With the patch, at longest it'll be until the app server is restarted, but more likely the 20 minute session expirey time on the server and, if the session was being using actively at the time it was snooped, until the user next requests a page. For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Mon, 12 Apr 2004, Chris Withers wrote:
For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-)
Making cookie authentication secure is surprisingly difficult, and you've barely taken one step. I don't want CookieCrumbler to go in this direction at all. A much more fruitful endeavor would be to simply add digest authentication support to Zope's user folders. See the middle of this page for a fairly clear explanation: http://frontier.userland.com/stories/storyReader$2159 Shane
From: "Shane Hathaway" <shane@zope.com>
Making cookie authentication secure is surprisingly difficult, and you've barely taken one step. I don't want CookieCrumbler to go in this direction at all. A much more fruitful endeavor would be to simply add digest authentication support to Zope's user folders. See the middle of this page for a fairly clear explanation:
The problem with that is that as far as I know, it still doesn't offer a nice, clean, cross-browser way of logging out. Which means most people will still use cookie-authentication...
Shane Hathaway wrote:
Making cookie authentication secure is surprisingly difficult, and you've barely taken one step.
So how does PAS do cookie auth then? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 04/12/04 09:04, Chris Withers wrote:
For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-)
BTW, I wouldn't mind if you or Stuart took over maintainership of CookieCrumbler after the next release. Then you'd be able to take it any direction you want. I don't believe its model can support well the things you're asking it to do, but I'll happily give you the chance to prove me wrong. :-) Shane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/2004, at 1:40 PM, Shane Hathaway wrote:
On 04/12/04 09:04, Chris Withers wrote:
For me, that's worth patching for, it's up to you if you want to include it in an offical CookieCrumbler release or not ;-)
BTW, I wouldn't mind if you or Stuart took over maintainership of CookieCrumbler after the next release. Then you'd be able to take it any direction you want. I don't believe its model can support well the things you're asking it to do, but I'll happily give you the chance to prove me wrong. :-)
I wouldn't be taking it in any direction - I like the product the way it is (Now I have checked in my code :-) ). Give me a poke if you don't feel like applying bug fixes though. - -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgLQXAfqZj7rGN0oRAtRqAJ92YgRN62v9S/NLKrihGZguNnQF9gCgmyg4 EGTx2vtEJ7EKLlFjMEBWe8s= =uEZG -----END PGP SIGNATURE-----
On Sat, 17 Apr 2004, Stuart Bishop wrote:
BTW, I wouldn't mind if you or Stuart took over maintainership of CookieCrumbler after the next release. Then you'd be able to take it any direction you want. I don't believe its model can support well the things you're asking it to do, but I'll happily give you the chance to prove me wrong. :-)
I wouldn't be taking it in any direction - I like the product the way it is (Now I have checked in my code :-) ). Give me a poke if you don't feel like applying bug fixes though.
Hmm. I really wasn't expecting any new code yet. Session cookies are a very significant maintenance burden in Zope, and it's not in my interest to support them. If you don't mind, I think I'll release a version of CC without any session support, then I'll give Chris Withers the maintainer hat. He'll start with your latest version. Shane
Shane Hathaway wrote:
Hmm. I really wasn't expecting any new code yet. Session cookies are a very significant maintenance burden in Zope, and it's not in my interest to support them. If you don't mind, I think I'll release a version of CC without any session support, then I'll give Chris Withers the maintainer hat. He'll start with your latest version.
I'll certainly take that on, if only because Cookie Crumbler is in such wide use. I wonder how many Plone users are aware their passwords are stored unencrypted in client cookies which fly back and forth waiting to be snapped up by packet sniffers, XSS, and JS attacks ;-) That said, basic auth ain't much better, but at least that's protectable by SSL... Hmmm, I wonder about sticking the token in the URL as an option, as with the SESSION stuff... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, 20 Apr 2004, Chris Withers wrote:
I wonder how many Plone users are aware their passwords are stored unencrypted in client cookies which fly back and forth waiting to be snapped up by packet sniffers, XSS, and JS attacks ;-)
Even with unbreakable encryption of credentials after login, you still send the username and password in the clear at login time, and sniffers can reuse the session ID with ease. You really shouldn't tell the Plone users they will be safer with a session token, because they won't. Shane
Shane Hathaway wrote:
On Tue, 20 Apr 2004, Chris Withers wrote:
I wonder how many Plone users are aware their passwords are stored unencrypted in client cookies which fly back and forth waiting to be snapped up by packet sniffers, XSS, and JS attacks ;-)
Even with unbreakable encryption of credentials after login, you still send the username and password in the clear at login time, and sniffers can reuse the session ID with ease. You really shouldn't tell the Plone users they will be safer with a session token, because they won't.
Shane
Why not make the login page itself SSL-protected then? peter.
On Tue, 20 Apr 2004, Peter Sabaini wrote:
Shane Hathaway wrote:
Even with unbreakable encryption of credentials after login, you still send the username and password in the clear at login time, and sniffers can reuse the session ID with ease. You really shouldn't tell the Plone users they will be safer with a session token, because they won't.
Why not make the login page itself SSL-protected then?
If you're going to go to the trouble of setting up SSL, why not encrypt the whole session? Let anonymous users come in via HTTP, then go all-SSL for logged in users. Sourceforge is a great example of this. Shane
Shane Hathaway wrote:
On Tue, 20 Apr 2004, Peter Sabaini wrote:
Shane Hathaway wrote:
Even with unbreakable encryption of credentials after login, you still send the username and password in the clear at login time, and sniffers can reuse the session ID with ease. You really shouldn't tell the Plone users they will be safer with a session token, because they won't.
Why not make the login page itself SSL-protected then?
If you're going to go to the trouble of setting up SSL, why not encrypt the whole session? Let anonymous users come in via HTTP, then go all-SSL for logged in users. Sourceforge is a great example of this.
Yes, thats what I was talking about. In our Zope apps this is standard procedure -- we have one non-SSL welcome page at the most, everything else goes through HTTPS, makes sense IMHO for data acquisition applications with at least moderately sensitive data peter.
Shane Hathaway wrote:
Even with unbreakable encryption of credentials after login, you still send the username and password in the clear at login time, and sniffers can reuse the session ID with ease. You really shouldn't tell the Plone users they will be safer with a session token, because they won't.
Well, they will. You go from being able to sniff from ANY request, to only being able to sniff from the login request. Session ID re-use will only work if the legitimately logged in user doesn't use the session they've just logged in to. If they do, both the legitimate and illegitimate session will get bumped out. Now, dependent on your point of view and the sensitivity of your data, that may only be a small improvement, but it IS an improvement... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Shane Hathaway wrote:
Hmm. I really wasn't expecting any new code yet. Session cookies are a very significant maintenance burden in Zope, and it's not in my interest to support them. If you don't mind, I think I'll release a version of CC without any session support, then I'll give Chris Withers the maintainer hat. He'll start with your latest version.
I'll certainly take that on, if only because Cookie Crumbler is in such wide use.
I wonder how many Plone users are aware their passwords are stored unencrypted in client cookies which fly back and forth waiting to be snapped up by packet sniffers, XSS, and JS attacks ;-)
That said, basic auth ain't much better, but at least that's protectable by SSL...
Cookies and Basic Auth both are transmitted via HTTP headers, so both should benefit from SSL Another question of course is what happens afterwards; in my experience at least IE has a tendency to even store Session cookies longer than one might expect (ie. the lifetime of the browser instance) I made a patch to CC to crypt auth tokens with AES, though thats not ideal it should help a little
Hmmm, I wonder about sticking the token in the URL as an option, as with the SESSION stuff...
Chris
On 12/04/2004, at 10:39 PM, Shane Hathaway wrote:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it.
I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage). I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-) Does this look worth releasing as a separate product?
PS: To make cookie auth properly secure, you really need to be working over SSL only
I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler.
Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?). -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/
Stuart Bishop wrote:
On 12/04/2004, at 10:39 PM, Shane Hathaway wrote:
On Mon, 12 Apr 2004, Chris Withers wrote:
I think the attached patch (against CookieCrumbler 1.1) makes CookieCrumbler a little more secure.
Your patch won't work with multiple ZEO app servers. It appears to store the tokens in a module global. Do not apply it.
I've attached some similar code we are using. Instead of patching CookieCrumbler, it extends it and is drop-in compatible. We are stuffing the auth credentials into the SESSION, so it will work with ZEO if your SESSION machinery copes (either using server affinity or your session storage is mounted by the ZEO clients from a central storage).
I was going to pack this up and release it as a product under BSD or MIT licence, but I either forgot or came up with a technical reason not to. Either way, I'm having memory issues :-)
Does this look worth releasing as a separate product?
I haven't looked at the code. Do you have actual experience using core sessions over ZEO? I pondered that recently for a client, and fell back to using a hacked together version of Anthony Baxter's SQLSession product, instead. SessionStorage would work either as a separate product, or as a knob for the CookieCrumbler, I think. If ZPL is an adequate license, why don't you check it in there?
PS: To make cookie auth properly secure, you really need to be working over SSL only
I agree--SSL is required. Let's not give people a false sense of security by changing CookieCrumbler.
Unfortunately it causes performance to blow. We compromise by having the auth form on the SSL server, but the rest of the application on raw HTTP. This at least reduces the window that a replay attack can be used. It would be possible to tie the auth credential down to a particular IP address, but that is entering the world of diminishing returns and incompatibilities (think ISP's with farms of proxies - is this still a problem nowadays?).
Yes; not only that, but AOL users change their IPs seemingly at random during a single session. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
fwiw, Simon Eisenmann checked in a SessionStorage product into the collective which does much the same. released under the zpl http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/ -kapil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/2004, at 4:28 PM, Kapil Thangavelu wrote:
fwiw, Simon Eisenmann checked in a SessionStorage product into the collective which does much the same. released under the zpl
http://cvs.sourceforge.net/viewcvs.py/collective/SessionCrumbler/
Looks pretty similar. It looks like it was written against the CMF's Cookie Crumbler rather than the standalone - I don't know if these two implementations have diverged much or not. - -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgLKtAfqZj7rGN0oRApVJAJ93KDOQZ2qV9v8gDv5adu5ITDu8rgCfa/0R ZRfH3ojpD4qQjx/XQ3B3wrM= =AtNX -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/04/2004, at 3:34 PM, Tres Seaver wrote:
I haven't looked at the code. Do you have actual experience using core sessions over ZEO? I pondered that recently for a client, and fell back to using a hacked together version of Anthony Baxter's SQLSession product, instead.
No experience unfortunately, although I do use sessions stored in the ZODB rather than temporary storage. I would consider it a bug if it didn't work :-) Performance may be an issue depending on how you use your SESSIONs of course which I suspect would be the major issue with doing this.
SessionStorage would work either as a separate product, or as a knob for the CookieCrumbler, I think. If ZPL is an adequate license, why don't you check it in there?
I've checked a version into Products/CookieCrumber and added a note to the CHANGES.txt - -- Stuart Bishop <stuart@stuartbishop.net> http://www.stuartbishop.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQFAgK/jAfqZj7rGN0oRAuvLAJ0dc8+B6NuTnIbUQWOV2OqCQYCfJQCeNHJm t6lrGtXwIkmhRr+O9VPrHuQ= =f7dh -----END PGP SIGNATURE-----
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
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
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
Jamie Heilman wrote:
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.]
Yup. I worry hard about XSS when it comes to my banking, my credit cards, my taxes; I don't much care when it comes to a news site.
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.
Right, mostly for the same reasons you point out above: the perceived threat isn't enough to warrant the pain. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
participants (10)
-
Chris Withers -
Chris Withers -
Jamie Heilman -
Kapil Thangavelu -
Lennart Regebro -
Peter Sabaini -
Shane Hathaway -
Stuart Bishop -
Stuart Bishop -
Tres Seaver