RE: ISA Server and SQL Injection

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

You make an excellent point from a product building standpoint.

My responsibility is to provide a company a more holistic overview
of an application, which may turn out to be the emergent behaviors
of appA, appB, and appC once I see how they are bolted together.

So I might find that appC, COTS, poorly built, can be better defended
by stronger data typing on appA which the customer controls.

> From a dev standpoint though you are right: why should your appA
be accountable for any other apps' lack of quality for data you handle
in a responsible manner?

In secure coding classes I preach that "the application must defend
itself" but with the meshing of distributed computing that's evolving
more and more, it's getting harder and harder for me to define where
the application begins and ends....

I will have to think on this more. I can't quite parse that being able
to break a query and subvert an application's behavior is an output
issue. Seems to break Microsoft's Rule #1 of security.

Good food for thought though; thanks,

-ae

> -----Original Message-----
> From: Jan P. Monsch [mailto:jan.monsch () csnc ch] 
> Sent: Wednesday, March 02, 2005 5:27 PM
> To: Evans, Arian
> Cc: webappsec () securityfocus com
> Subject: Re: ISA Server and SQL Injection
>
>
> Hi Arian,
>
> Secondary code injection attacks occur because secondary applications 
> often do not do their homework. This is why input validation is often 
> proposed as a solution. But it is the most radical solution and most 
> intrusive solution.
>
> A developer of a web application does not know what code injection 
> problems some exotic or even unknown application in the 
> backend has. Why 
> should it be the web application developers problem to solve a code 
> injection problem in another application he does not know about. If a 
> developer wants to protect any backend application he or she must 
> probably block all special characters to be safe against any type of 
> code injection attacks. I do not think that this makes sense 
> in the end 
> and that the restrictions imposed through this kind of filtering does 
> sometimes not meet business requirements. E.g. there are names like 
> "D'Amato" which requires a single quote.
>
> Therefore I think that every component should protect itself against 
> their own code injection issues. And most achieveable solution is to 
> encode any received input properly into output. (Btw. I think that 
> SQL-Injection is also a ouput encoding issue - where the output is the 
> SQL-Query).
>
> I know from practice that the real world looks different and I 
> therefore 
> think that input filter has it value especially if the backend 
> applications are not known to be safe against code injection.
>
> Regards Jan
>
>
>
> Evans, Arian wrote:
> > 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
>
>
> -- 
> _____________________________________________________________
> Jan P. Monsch
> Compass Security Network Computing AG
> Glärnischstrasse 7, CH-8640 Rapperswil, Switzerland
>
> Tel +41 55 214 41 67
> Fax +41 55 214 41 61
> jan.monsch () csnc ch
> http://www.csnc.ch
>
> PGP: F055 837D 2D86 1C86 C5E0  065C 0D16 B8B3 9E58 71F3
>
> Security Review - Penetration Testing - Computer Forensics
> _____________________________________________________________