I agree with caveats ;-) What you have to take into account here is that
"subverting application logic" or whatever it gets called is a great example
of something the testing methodology will cover. Again let me recap for
clarity that the point of the COV's and the attack components is to define
common language and definitions from which people are able to describe
complex attacks unambiguously in other work. Subverting application logic
will and should be a huge part of a web security testing methodology and
will probably have many examples of things that can be done using things
like url parameter manipulation or session hijacking or <insert attack
component of choice>.... the methodology should and will break down how to
understand how application decisions are made and enforced and therefore how
to build attack trees to subvert them. But application logic isn't a primary
attack component, its an instance for anyone who know OO.

PS - I used the term authorization and not authentication which are very
very different.

-----Original Message-----
From: jeremiahwww.whitehatsec.com
[mailto:jeremiahwww.whitehatsec.com]On Behalf Of Jeremiah Grossman
Sent: Thursday, November 01, 2001 10:09 PM
To: Mark Curphey
Cc: dwgowasp.org; Izhar Bar-Gad; webappsecsecurityfocus.com; Nigel
Tranter
Subject: Re: (OWASP)RE: (OWASP-SM-PS-1) - Page Sequencing

As much as "page sequencing" can be and many times IS involved directly
with authentication, it is most likely part of a larger issue... an issue
that has many descriptive terms. ("Page Sequencing, Application Flow/State,
business logic, or even data aggregation")...

whatever the term... the REAL overlying problem is manipulating a process
flow or multiple process flow together in order to leverage an attack.
These types of attacks can get quite complex and WILL vary from web
site to web site... but the concepts are sound.

Again, whatever term we would use to define this section should encompass
many "flow" attacks which include page sequencing....

the larger question becomes apparent.... what other "generic" flow
manipulations
attacks could we define or explain that would go into this section?

Jer

Mark Curphey wrote:

> I think the original thought was that if you don't track a session
correctly
> an adversary can jump out of the desired sequence of events. I guess
> original thoughts were it is really an authorization problem....you have
> pages a, b and c and only want user to see c when he has completed a and
b.
> If c doesn't check the session token to see that it was produced from
> visiting and completing b, then he can jump straight into c unauthorized.
>
> Based on that, what was being called page sequencing is just a consequence
> or something you can do as a result of bad session management. To do it
you
> may use forceful browsing or parameter manipulation or whatever....
>
> I think the session management section should be beefed up and maybe this
is
> an example of what can go wrong rather than a section itself. Remember the
> description of how each attack component can be used to describe more
> complex attacks like jumping out of sequences or manipulation application
> logic can be found here http://www.owasp.org/projects/cov/
>
> -----Original Message-----
> From: dwgowasp.org [mailto:dwgowasp.org]
> Sent: Thursday, November 01, 2001 7:31 PM
> To: Izhar Bar-Gad; 'webappsecsecurityfocus.com'; Mark Curphey
> Cc: Jeremiah Grossman; Nigel Tranter
> Subject: Re: (OWASP)RE: (OWASP-SM-PS-1) - Page Sequencing
>
> I have to agree with Izhar here, because this is the "real Web Application
> Security" problem and why many scanners do not work. First it is a
business
> logic problem - many companies do not seem to understand that the web is
> stateless, and try to enforce or assume a flow to the site, or create
addhoc
> methods of enforcing that flow. The issue is that although you can
"spider"
> through it with a scanner, a human must look at it that understands that
the
> business logic is/was/can be subverted. And this problem is big. Perhaps
we
> need to devote special attention to this issue, and perhaps splinter off a
> new section of the COV to "business logic" or something like that.
>
> Jeremiah, I am sure you must have some thoughts on this as well.
> Nigel, I think you had some ideas about this also.
>
> dwg
>
> > Page sequencing is actually as subset problem of the "application
> > flow/state" problem, that does not reside only under session
> manipulations.
> > Many attacks can be performed by causing the site to jump to states
which
> > are not part of the flow. For example jumping to a late stage in the
> > definition of a financial transaction. The problem is that in many cases
> the
> > application acts like a "state machine", however it does not verify
> movement
> > only according to the links between the states.
> >
> > Izhar
> >

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]