Re: ISA Server and SQL Injection

[Stephen de Vries <stephen () corsaire com>]

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.
 ----------------------------------------------------------------------