RE: ISA Server and SQL Injection

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

re: point #2, that's an interesting perspective.

Input validation and cannonicalization has primacy to my mind
as many attacks are *done* once input is processed, regardless
of output encoding/error handling.

Additionally, input validation can stop embedded and secondary
application attacks that the primary application can't control
(e.g.--application taking input is the data broker for other applications
that will handle/parse/output the data, from CRM systems to
administrative applications to log readers).

Ideally those all have proper encoding of their output as well,
but in reality they often don't.

Using inject script tags (XSS, etc.) as your example, while output
encoding is an effective defense in certain cases, one problem is
that you don't always know or control where your output is going.

<OT>
I see this as more and more of a problem in today's modern, complex,
distributed computing environments. We plug more and more apps
together to the point where in some cases pen testing "app X" is as
silly as pen testing "node 1" on a interconnected network, as appX,
appY, and appZ are so tied together they really need to be tested
and treated as one entity, even though they all have a unique UI.
</OT>

-ae

> -----Original Message-----
> From: Jan P. Monsch [mailto:jan.monsch () csnc ch] 
> Sent: Tuesday, March 01, 2005 3:37 PM
> Cc: webappsec () securityfocus com
> Subject: Re: ISA Server and SQL Injection
>
>
> Hi there!
>
> I have lots of discussions with customers regarding the issue of 
> perimeter application filters. May conclusion regarding the 
> issue is as 
> follows:
>
> 1. Validation in the application itself is the best and most efficient 
> way of handling code injection problems. Because the application knows 
> about its domain but the gateway filter not. In addition the 
> application 
> can provide appropriate error messages for incorrect input.
>
> 2. Output validation is much better then Input validation, 
> because most 
> problems are related to incorrectly encoding input parameters into 
> output. In addition proper output encoding allows to use critical 
> characters like < > within the application. This is especially 
> important 
> in back-office applications.
>
> 3. Output validation should be handled in a security 
> framework, built by 
> a security expert. It must be implemented such that the business 
> developer has not to worry about encoding stuff. (I know this 
> is a ideal 
> world szenario)
>
> 4. In may opinion validation on the gateway does only make sense if it 
> used in a transitional way until input/output validation in the 
> application has been implemented or it is used as a part of intrusion 
> detection.
>
> Regars Jan