-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi David,
Just catching up on my list reading (which I've been pretty remiss
with lately). Hopefully I'm not jumping in too late here.
On Tuesday 15 June 2004 7:04 am, David Cameron wrote:
> > Exactly. I think that Alex Russell first started talking about
> > "boundary validation" [1] (although I think that Sverre Huseby
> > was talking about the concept previously),
So I think that when I started talking about it, I always made sure to
note that it's nothing new and certainly not something I somehow
invented.
> > which refers to
> > making sure that content inappropriate for the "service" on the
> > other side of the boundary is appropriately filtered. This could
> > be done on either side of the boundary, of course, but is not
> > restricted to "input filtering".
This is something that, in a perfect world, might be done on both
sides of the boundary, since each boundary side will know what the
other side "is". Regardless, each self-contained subsystem will need
to filter outgoing data to remove whatever escaping (etc.) it's
filtering may have introduced on the inbound side of things, so it
does need to be done on both sides for any subsystem that adopts it.
This isn't to say that doing it only on the inbound is bad, but
rather that you might mangle the data beyond beleif if you don't.
> Boundary filtering is an excellent concept which aids in good
> application design. However it can add to the complexity in other
> ways.
I think there has always been some agreement on this, but defense in
depth is always more complex when viewed at large. OTOH, it
simplifies the analysis path for determining the threats against any
individual component in the system, and components can be secured on
a one-by-one basis (which is work you'd be doing to come up with a
secure whole anyway).
> As I pointed out in the referenced discussion it pushes the
> error checking further from the source of the error.
But cross-boundary error transmission is something that all web apps
struggle with today anyway. Consider the case of an ODBC exception.
What happens in most apps today? Do things get logged centrally and
in a reasonable fashion? Does the user find out about the error
first? What should my app layer DO when it gets one of these? Many
times, these interactions are completely unspecified which leads to
all kinds of information gathering vulns.
But to go it one better, consider an app that DOES log this stuff
centrally and I get said ODBC exception, where does it get handled
from? Not usually the DB layer, since that's a good place to put
catch-all exception handling. More likely, it'll happen as close to
the edges of the HTTP transaction as the app container will allow
(global or catch-all exception handling routines are very common).
> In addition to
> that, in some cases the source of the error might be the only place
> where this problem may be solved. I talked about this as a problem
> only in an asynchronous environment, I think it has wider
> application though. I'll try to explain using an example.
>
> Suppose you have a web application that goes something like this
> (MS platform:
>
> Front End(1) Bus Logic(2) DB(3)
> ASP.Net -------> MSMQ ------> SQL Server
> <------- COM <-------
>
> Applying Boundary filtering, SQL injection and basically data that
> would be filtered between 2 and 3. Taking the example further.
> Suppose you have a comments which is represented at the web app as
> a textbox and in the database as a VarChar(2000) column. Consider
> the case where someone enters 2001 characters into the field. As
> far as the web application is concerned, text is text and how much
> text should be allowed is a concern for the database. If the update
> is sent to an asynchronous MSMQ process, what action should be
> taken if it fails at the boundary? The solution proposed by Alex
> (http://seclists.org/lists/webappsec/2003/Jan-Mar/0163.html) would
> be to drop the relevant message and log the issue for later.
Or mangle the message to fit the accepted policy and tell a source
system about it. That would be a per-filter policy.
> However from the user perspective the comment has been updated,
> there haven't been any errors, despite the fact that the comment
> hasn't in fact been updated.
I've often considered this question and i'm still somewhat undecided
about it. On the one hand, your system knows what happened, can tell
you about it later, and you haven't mangled any data. Should your
source system be told that something really really bad happened?
What's the protocol for that? Does it open you up to information
disclosure vulns? I've thought it might be an option that your filter
could support, but then I go back on it when I start thinking about
the ammount of work required just to tune your filters.
> Now consider that there may be further tiers between 2 and 3. The
> problem then becomes more difficult again. I believe is better to
> ensure that "exceptions" are passed back up the tree until the
> reach a place where they can be dealt with (in the example, all the
> way back to the user). In an asynchronous environment this may need
> to be implemented using some sort of call back system (verifying
> the update). I think this error handling "chain" is a common
> structure in OO systems.
I guess these days my thinking is that exception passing is different
(but related) to the filtering task, but much more akin to a "dumb
logger". In the situation you describe, interposing more layers also
has the implied meaning that the information that would be
encapsulated in the base exception becomes less and less pertinent
(i.e., I only really use the exception as status information since
it's value decreases with distance). All the front end cares about is
if something happened or not, not necessarialy WHAT happened, aside
from broad descriptions.
My filter may report any kind of status it wants to, but to do that it
has to be able to gererate arbitrary exceptions and ensure that those
don't do something nasty themselves, so they are necessiarly
information-poor. In the case where i'm getting input I don't like
and/or want, the front end should have ALREADY checked the length of
the input (in it's input filter for the HTTP POST/GET) and reported
the problem there. In the case where we get all the way back to the
DB layer before this becomes a problem, one might hope that the DB
will first and foremost try to keep itself whole, and then as a
secondary responsibility, tell someone about what happened. It seems
entirely reasonable to have the filtering system generate 'filter
exceptions' at each boundary, but then you have to have some protocol
for encoding/decoding these as useful entities. I've started thinking
of logging as only the most rich ("trusted") recipient of status
information from a filter, and a throw exception would be another
kind that might include much less information, but still indicate
that something went pear-shaped. Filters have to be really smart to
handle this kind of distinction, and I haven't written that use this
generic concept of a "listener" yet, but I intend to.
Regards
- --
Alex Russell
alex_at_burstlib.org BD10 7AFC 87F6 63F9 1691 83FA 9884 3A15 AFC9 61B7
alex_at_netWindows.org F687 1964 1EF6 453E 9BD0 5148 A15D 1D43 AB92 9A46
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFA0IGBoV0dQ6uSmkYRAmmhAKDWoWy+/DbZ2qdlesDElI6rwi4ocACg3XP5
0CS4ZDuX4sglRXgsHJrz1qQ=
=QRwL
-----END PGP SIGNATURE-----
Received on Jun 17 2004
Intro
