[ajug-members] Cookie question

Thu Jul 6 14:03:38 EDT 2006

Well, I think UUID's are a decent choice for most applications.  The
goal of data security is to make it sufficiently difficult for one to
access information.  No security mechanism is foolproof.  UUIDs are a
much better choice to key off of secure DB data than integers - how easy
is it for one to see this url:

http://www.companyapp.com/user.htm?uid=192283

and for them to attempt a hit at:

http://www.companyapp.com/userData.htm?uid=192284

and so on until they access other user's data.

Granted, most applications worth anything will have additional security
measures in effect to prevent this kind of thing (i.e. this request is
from user 192283, but they're asking for data for user 192284 - access
denied).  But there are _SO_ many apps out in the 'real world' that have
nothing of the sort - pretty scary actually.

When using UUIDs, and having single id generator for an entire
application, brute force hits to any given data type is much more
difficult.  Yes a hacker _might_ find out that A138B3-blah blah is an id
- but do they know if it is a session id, user id, event id, etc, etc? 
How do they access the website/server such that this 'discovered' ID is
placed accurately, with all supporting information to accurately submit
the request?  Yes, these things are possible, but much much more
difficult.  One might say 'sufficiently difficult' for most application
requirements.

JSecurity works this way (if desired) to store a session id in a cookie
- and that's the only thing stored in that cookie.  All other session
data is stored server side and keyed off of this id.  Of course, this is
configurable, and one might conceive of storing a public key in the
cookie instead, making brute force darn near impossible.  It also does
permissioning per user/role/group/ip address/object, etc. to do the more
secure checks described above as well (sorry for the plug ;) ).

Cheers,

Les
JSecurity co-founder
http://www.jsecurity.org

On Thu, 6 Jul 2006 11:04:02 -0400, "Dean H. Saxe"
<dean at fullfrontalnerdity.com> said:
> Burr,
> 
> GUID is not such a great idea.  While long and seemingly random, its  
> not too hard to brute force a GUID.  They are guaranteed unique, not  
> random!
> 
> And thanks, Burr.  </blush>  I know there are a few other security  
> folks on here who I have great respect for.  They're just not  
> speaking up! ;-)
> 
> -dhs
> 
> 
> 
> Dean H. Saxe, CISSP, CEH
> dean at fullfrontalnerdity.com
> "I have always strenuously supported the right of every man to his  
> own opinion, however different that opinion might be to mine. He who  
> denies another this right makes a slave of himself to his present  
> opinion, because he precludes himself the right of changing it."
>      -- Thomas Paine, 1783
> 
> Find out about my Hike for Discovery at www.fullfrontalnerdity.com/hfd
> 
> 
> 
> On Jul 6, 2006, at 10:44 AM, Burr Sutter wrote:
> 
> > I agree with Dean's point on the encrypting of cookies.  Simply put  
> > some
> > long unique string (GUID) that is really keyed to a database record  
> > (or
> > session data) on the server-side.  The 3rd party, assuming they could
> > steal your cookie, would then need access to your servers to figure  
> > out
> > what the real data is.
> >
> > And Dean is our resident Atlanta JUG security expert!
> >
> > Burr
> >
> > -----Original Message-----
> > From: ajug-members-bounces at ajug.org
> > [mailto:ajug-members-bounces at ajug.org] On Behalf Of Dean H. Saxe
> > Sent: Thursday, July 06, 2006 10:23 AM
> > To: General AJUG membership forum (100-200 messages/month)
> > Subject: Re: [ajug-members] Cookie question
> >
> > The JS will only have access to cookies in your domain if its
> > downloaded from your domain.  Or if it takes advantage of browser
> > flaws.  Some systems actually download the JS from other domains
> > rather than embedding it in your code.
> >
> > I highly recommend reading the book HTTP by O'Reilly, it explains all
> > of this in excruciating detail.
> >
> > With respect to encrypting the information, I have to disagree with
> > the poster.  If the information is sensitive enough that you don't
> > want it transmitted anywhere else, including a third party, don't
> > store it client side.  Sensitive data should always be stored server
> > side.
> >
> > -dhs
> >
> > Dean H. Saxe, CISSP, CEH
> > dean at fullfrontalnerdity.com
> > "What is objectionable, what is dangerous about extremists is not
> > that they are extreme, but that they are intolerant."
> >      -- Robert F. Kennedy, 1964
> >
> > Find out about my Hike for Discovery at www.fullfrontalnerdity.com/hfd
> >
> > On Jul 6, 2006, at 10:09 AM, Burr Sutter wrote:
> >
> >> 3rd party tracking systems typically use a
> >>
> >> A) small image that is embedded in your web pages OR
> >>
> >> B) a piece of JavaScript OR
> >>
> >> C) hook into the flash-plugin (via JS you can store pieces of data
> >> in Flash that is invisible to the end-user) - works well if the
> >> user shuts down cookie support
> >>
> >>
> >>
> >> With option A the 3rd party will likely provide a cookie with the
> >> request/response for the images (typically an invisible .gif) and
> >> in that scenario they will only have access to the cookies they
> >> provide for their domain.
> >>
> >> With option B where the 3rd party hands you a .js file and some
> >> script code to copy and paste into all of your pages then that JS
> >> could have access to all available cookies, you would have to look
> >> at their JS code for details
> >>
> >> With option C, I'm not sure as I've not personally tried the
> >> technique, just heard about it.
> >>
> >>
> >>
> >> What 3rd parties are you looking to use?  I've heard of Eloqua.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ajug-members-bounces at ajug.org [mailto:ajug-members-
> >> bounces at ajug.org] On Behalf Of James Thomas
> >> Sent: Thursday, July 06, 2006 9:31 AM
> >> To: ajug-members at ajug.org
> >> Subject: [ajug-members] Cookie question
> >>
> >>
> >>
> >> Hi Team,
> >>
> >> We are currently using 1st party cookies to track certain
> >> information about our customers, however, we have a third party
> >> business partner that creates and tracks other data about our users
> >> for us as well. We want to restrict access to our third party to
> >> only the cookies they are concerned with and not all of the cookies
> >> in the domain. What is the best way to accomplish this? This is a
> >> CF5 soon to be Java web app.
> >>
> >> Any thoughts?
> >>
> >> _______________________________________________
> >> ajug-members mailing list
> >> ajug-members at ajug.org
> >> http://www.ajug.org/mailman/listinfo/ajug-members
> >
> >
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> >
> > _______________________________________________
> > ajug-members mailing list
> > ajug-members at ajug.org
> > http://www.ajug.org/mailman/listinfo/ajug-members
> >
> 
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members