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
_____________________________________________________________
