Hi Paul,
On 23 Feb 2005, at 14:20, Paul Johnston wrote:
I think what you're saying boils down to "just get the code right".
Well, sure, if everyone did just get the code right then we wouldn't
have these problems.
But the point of defence in depth is to design a system that is
secure, even if a few coding errors have been made.
Well the point of defence in depth is to have a secure system, with
multiple security checkpoints to ensure that a flaw in any single level
doesn't give access to the whole system. And if we had infinite
budgets I'm sure we would have a wild time in the app security
superstore, but we don't; and we have to spend the limited resources we
have very wisely. If I had to choose between fixing the problem at the
root, or applying a patch - I'll go for the root every time. And this
is not necessarily just code audits, but can range from stricter
quality assurance procedures, to developer education, peer review and
security testing. These have longer term benefits for an organisation
since they contribute to the wider security process rather than solving
a specific problem.
With this in mind, app firewalls are a useful part of the arsenal. On
a practical level, doing this gives more security than expending
equivalent effort just on auditing the code.
I don't agree, and as mentioned above there are other areas of security
where this money can be spent besides code audit. The investment in
code audit is not a once off expense, but can have knock on effects
that benefit the whole security picture at an organisation. If the
methodology of, and the result of the audit is properly distributed and
understood by developers then future applications will also benefit
from it.
I think that an app firewall can give a false sense of security since
those who don't understand the technology will believe it to be
protecting them from _all_ application level attacks when in reality it
cannot do this.
They have no hope whatsoever to protect a web application where say
switching a name value pair gives you another persons account.
The current ones perhaps, but that's not an inherent limitation. Just
like TCP/IP firewalls have become stateful, so will application
firewalls. Say the field is "basketid", the app firewall starts by
blocking ALL values of that. When a user requests a page with a link
to a valid basketid for that user, the app firewall statefully adds
that id to the whitelist for just that user. This way, if the
parameter is vulnerable to tampering (e.g. it's sequential) the app
firewall provides further protection.
If we take this suggestion to it's conclusion, then the business logic
(at least the authorisation and access control restrictions) will be
defined in two places, once in the app, and once at the app firewall,
each time in it's own language. While this is apparently exactly where
we want to be with regards to defence in depth - I think app firewalls
are the wrong place to start. First get the security in the app right
and then consider re-enforcing this on app firewalls.
Regards,
Stephen
Ideally, the back-end application protects this by using 128-bit
random numbers as IDs. The front-end app firewall provides further
protection. Now, if EITHER of these protections fail, the resulting
system is still secure.
Regards,
Paul
--
Paul Johnston, GSEC
Internet Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk
----------------------------------------------------------------------
CONFIDENTIALITY: This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited. If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER: Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
