It's just one more control.  Alone I would agree with you, it's not enough.
You should be checking access.  In the user admin case I think it makes
sense to check and see if you are supposed to have access to that specific
user id information or not.


Listen this is getting silly.  Don't like it, don't do it.

--
Timothy Heald
Web Portfolio Manager
Overseas Security Advisory Council
U.S. Department of State
571.345.2319

The opinions expressed here do not necessarily reflect those of the U.S.
Department of State or any affiliated organization(s).  Nor have these
opinions been approved or sanctioned by these organizations. This e-mail is
unclassified based on the definitions in E.O. 12958.

-----Original Message-----
From: Barney Boisvert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 23, 2004 4:04 PM
To: CF-Talk
Subject: RE: Securing CF Apps.

What!?!?!?

I sure hope the application security would say "hey, you don't have
permission to look at that userID's info, so here's a nice fat error
message", long before it every got to querying the database.

That's the whole point of a security system: to control access to resources.
If you merely make it hard to request the resource, but don't actually
control access, you don't have a security system, you've just got a mess.

Cheers,
barneyb

> -----Original Message-----
> From: Bryan Stevenson [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 23, 2004 12:54 PM
> To: CF-Talk
> Subject: Re: Securing CF Apps.
>
> and it's not that little....take this example
>
> a page displays user specific medical record data and take
> URL param containing user_ID
>
> don't encrypt user_ID in URL
>   -any shmuck can alter the value of user_ID to see anyone's data
>
> do encrypt user_ID in URL
>   -same shmuck would not be able to make such a chnage as the
> user_ID would not decrypt properly and the query would fail
>
> I'd say encrypting vars in the URL is pretty dang important ;-)
>
> That said it's also a good idea to make sure the record being
> displayed belongs to the logged in user ;-)
>
> Cheers
>
> Bryan Stevenson B.Comm.
> VP & Director of E-Commerce Development
> Electric Edge Systems Group Inc.
> t. 250.920.8830
> e. [EMAIL PROTECTED]
>
> ---------------------------------------------------------
> Macromedia Associate Partner
> www.macromedia.com
> ---------------------------------------------------------
> Vancouver Island ColdFusion Users Group
> Founder & Director
> www.cfug-vancouverisland.com
>   ----- Original Message -----
>   From: Adrocknaphobia
>   To: CF-Talk
>   Sent: Tuesday, March 23, 2004 12:47 PM
>   Subject: Re: Securing CF Apps.
>
>
>   Little is better than none.
>
>   -adam
>
>   > -----Original Message-----
>   > From: Kwang Suh [mailto:[EMAIL PROTECTED]
>   > Sent: Tuesday, March 23, 2004 08:42 PM
>   > To: 'CF-Talk'
>   > Subject: RE: Securing CF Apps.
>   >
>   > Munging URLs provides a little, if any, benefit for web apps.
>   >
>   > ----- Original Message -----
>   > From: "Heald, Tim" <[EMAIL PROTECTED]>
>   > Date: Tuesday, March 23, 2004 1:34 pm
>   > Subject: RE: Securing CF Apps.
>   >
>   > > Good post man, and your right, for the most part the
> applications
>   > > I am
>   > > talking about are not available over the internet, or
> only through
>   > > VPN or
>   > > other methods.
>   > >
>   > > Like I said earlier, for public sites you are going to use very
>   > > differentresources than you will use on a closed/classified
>   > > application.
>   > > However the topic was securing CF apps.  Not sites :)  
> it can be
>   > > difficultfor some to differentiate between an
> application and a site.
>   > >
>   > > --
>   > > Timothy Heald
>   > > Web Portfolio Manager
>   > > Overseas Security Advisory Council
>   > > U.S. Department of State
>   > > 571.345.2319
>   > >
>   > > The opinions expressed here do not necessarily reflect those of
>   > > the U.S.
>   > > Department of State or any affiliated organization(s).  
> Nor have these
>   > > opinions been approved or sanctioned by these
> organizations. This
>   > > e-mail is
>   > > unclassified based on the definitions in E.O. 12958.
>   > >
>   > > -----Original Message-----
>   > > From: Ian Skinner [EMAIL PROTECTED]
>   > > Sent: Tuesday, March 23, 2004 3:19 PM
>   > > To: CF-Talk
>   > > Subject: RE: Securing CF Apps.
>   > >
>   > >
>   > > I see this as a sliding scale, security vs user experience.
>   > >
>   > >
>   > > There's the general public website where the the owners
> want as much
>   > > exposure as possible.  For this type of application you
> may not want
>   > > security to the nth degree.  As was just posted,
> allowing the user to
>   > > bookmark pages and/or directly type url's is desirable for the
>   > > purpose of
>   > > that application.
>   > >
>   > >
>   > > On the other hand, there are applications where this is
>   > > undesirable.  I
>   > > suspect that applications Tim is writing are even
> available to the
>   > > generalpublic at all, and if you are even seeing the page in a
>   > > browser if you are
>   > > not supposed to be, you have hacked through several
> layers of security
>   > > already.
>   > >
>   > >
>   > > We write applications somewhat in the middle.  There
> are parts of
>   > > our data
>   > > that we DO NOT WANT to exposed to any more risk then we
> can, very
>   > > sensitiveHIPPA data.  We are taking at least a year to
> thoroughly
>   > > test our first
>   > > application that will allow a very limited access to users to
>   > > their personal
>   > > data directly through the internet.
>   > >
>   > >
>   > > So it all comes down to the analysis that has been
> mentioned.  You
>   > > need to
>   > > decided on the purpose of the application, what are
> it's security
>   > > needs and
>   > > build to that level.
>   > >
>   > >
>   > > My .02, keep the change.
>   > > --------------
>   > > Ian Skinner
>   > > Web Programmer
>   > > BloodSource
>   > > www.BloodSource.org
>   > > Sacramento, CA
>   > >
>   > > "C code. C code run. Run code run. Please!"
>   > >     - Cynthia Dunning
>   > >  _____  
>   > >
>   > >
>   > >
>   > >
>   >
>   >
>
>
>
  _____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to