RE: Whitepaper "SESSION RIDING - A Widespread Vulnerability in To day's Web Applications"

["Evans, Arian" <Arian.Evans () fishnetsecurity com>]

Noah Gray wrote:

> > Other than that, this is very plausible attack that I would 
> > agree hasn't received enough attention. I would also add that in the 
> > case of the img tag in the email, an iframe could also be used, similar to 
> > recent viruses. It needn't even be visible.

Ben Timby replied:
 
> I agree w/ you completely.

Okay, call me clueless here, but hasn't it been a basic principle
of secure application development that for critical or sensitive
functions we should use user authentication (or some form of a unique
secret) as opposed to entity authentication (e.g.-session cookie)?

Maybe I was too critical in my initial response to Thomas's paper.
I still do not believe we need a new term; this fixation on particulars
(XSS, XST, XFS, XDS, etc.) is to my mind one of the main detractors
to focusing on overall robust application design.

My initial post was facetious pointing out that even secret tokens
can be stolen...but yes, of course, it raises the bar which is
the point of many halfway web security measures we take. I went on
to point out only a user-supplied secret is truly effective for preventing
transparent execution in my silly 'advisory'; of course, coupled with
a slick phishing/luring attack even this could be squeezed out of users.

Are our efforts better applied focusing on development of a rigorous
state and session management criteria?

At least, that interests me far more than discussing nuances of how
'session riding' differs from 'session hijacking', 'session point-blanking',
whatever. Someone smarter than me tell me what I'm missing here,

Thomas, I know you've got a vested interest in your paper, and thank
you guys for writing it and bringing this into the webappsec dialogue.
Sorry to be critical; my concern is that your paper is more likely to
bring about a new webapp "firewall" 'feature' than stimulate work on
documenting strong state/session handling. Which isn't really your fault.

Arian

p.s.--on the referer (sic) issue, someone mentioned this and while
server-side filtering has its effective benefits (one can do excellent
things with mod_rewrite), client-side tracking of this as I've commonly
run into (via a parameter, etc.) produces a whole new security risk.
I don't think referrer tracking is really the answer at all....






The information transmitted in this e-mail is intended only for the addressee and may contain confidential and/or 
privileged material. 
Any interception, review, retransmission, dissemination, or other use of, or taking of any action upon this information 
by persons or entities
other than the intended recipient is prohibited by law and may subject them to criminal or civil liability. If you 
received this communication 
in error, please contact us immediately at 816.421.6611, and delete the communication from any computer or network 
system.