Al
Mon May 24 21:58:25 CDT 2004
"alltel news" <kenwebster@carolinadotrr.com> wrote in message
news:HEpsc.7910$zs2.5946@fe39.usenetserver.com...
> The particular "hole" I'm trying to plug happens when a user terminates
his
> browser (without logging off) and walks away. An evildoer walks up behind
> him and opens a new browser window, and immediately (before my web
> application imposed idle time limit expires) navigates back through
history
> to a page in the site.
Fine. Plug that hole. But what about the hole where an evildoer takes over
one of your user's sessions? He may not be able to get into the person's
bank account, but might he send a particularly nasty email to the president
of the company and get this person fired?
IMHO, if you plug only one of these holes, you are plugging the wrong one.
Conversely, if you are only plugging one of them, why bother at all?
> From what I see in these assorted approaches you've mentioned, this
problem
> is unaddressed. It seems to me like an easy way to fix it would be to get
> some unique identifier from the browser itself, then make sure that it
> doesn't change mid-transaction.
Hey, the systems themselves could be more cooperative, and understand more
about security. But we are not quite in a position to do that just yet.
You *could* look for an add-on package that occasionally asks the user to
identify him/herself with password, logging off if the person is unable to.
But then you will simply be inconveniencing your users by getting in the way
of them getting things done. Not a particularly good way to foster good
security practices...
> Assume I have no control over browser settings that would clear history,
> etc.
>
> Or am I being overly anal about this?
You said it, not me :-) But being "anal" is not necessarily a bad thing
when it comes to security. Better, in fact, than not getting your hands
dirty in this stuff up to the elbows finding out how things work under the
hood. You might eventually back away from this idea, but at least you looked
into it. In the process, you might even learn a few things about what might
happen that will give you other ideas on how to counter those threats.
"Overly" anal would involve not letting go of an idea even once it turns out
to be nearly impossible, or focussing on just one security issue to the
exclusion of all others. Good security is all about balance, evaluating
potential threats, and managing the risks.
/Al
> "Michael Harris (MVP)" <mikhar at mvps dot org> wrote in message
> news:O7pkhJ6PEHA.556@TK2MSFTNGP10.phx.gbl...
> > alltel news wrote:
> > > I'm working on a web app that will be run on a server farm- so
> > > session level variables are out. I keep running into a need for a way
> > > to uniquely identify the user's browser "session" (i.e. a value that
> > > changes whenever the user browses to the site through a new browser
> > > window). I'm guessing the browser's process ID would work in
> > > combination with his IP.
> > >
> > > Is there a way to acquire such a value through script, either from
> > > the host or the client side?
> >
> >
> > I suggest looking at some of the many recommended solutions before
trying
> to
> > create your own...
> >
> > I've excluded ASP.NET solutions since we *are* in a vbscript newsgroup
> > ;-)...
> >
> > Google Search: "session state" "web farm" asp -.net site:microsoft.com
> >
>
http://www.google.com/search?q="session%20state"%20"web%20farm"%20asp%20-.net%20site:microsoft.com&num=100&scoring=d
> >
> >
> >
> > --
> > Michael Harris
> > Microsoft.MVP.Scripting
> > Sammamish WA US
> >
>
>
>