Re: New Whitepaper - "Second-order Code Injection Attacks"

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

> The fundamental idea is that whenever data is transferred from one 
> "domain" to another (where a domain is something like "browser", "Java 
> code", "SQL statement", "XML message", "interbank transfer record", 
> "SMS", etc), one must take care to ensure that the data does not get 
> corrupted in any way. By "corrupted", I mean "parts of the data get 
> interpreted as meta-data".

Yep, I completely agree 
(http://seclists.org/lists/webappsec/2004/Apr-Jun/0346.html).  It makes 
sense that each context (or domain) performs it's own data validation, 
since only that context will know what constitutes valid data.  A 
single quote could mean bad things when sent to an SQL query string, 
but could be completely innocent as an SMS message.
I remember being taught programming as a young bear, and one of the 
fundamental principles was that of defensive programming where no input 
data is trusted until it is validated.  This becomes more and more 
important in modular applications where the data generated by certain 
modules cannot always be implicitly trusted.
Sadly, in the real world a modular approach to input validation is 
rarely adopted.  Firstly, it's a relief to see input validation being 
done at all - and when it is done, it's usually performed by one set of 
routines that typically sit just behind the front end.

> This simplifies the problem, I think. It becomes the responsibility of 
> the interface layer (however it is implemented) to ensure that the 
> data does not get corrupted while passing through the interface. The 
> creator of the interface layer should have enough information about 
> the destination system to know what needs taking care of, and how to 
> do that. e.g. using prepared statements for a DB, escaping angle 
> brackets sent to the browser, etc.

It also makes it easier to define valid data and to keep tabs on which 
characters are meta-characters, since now each domain sees to it's own 
affairs.

<snip>
> I realise that this has performance implications, of course, but since 
> when is that a good reason to discard security? ;-)

The other obstacles to implementing this sort of validation will be 
educating developers as to its importance and then convincing the 
business that they need to invest extra development hours in 
implementing these measures.

Stephen


> Gunter Ollmann wrote:
> > Hi Jan,
> > Jan P. Monsch wrote:
> > > Thank you for your very interessting paper on "Second-Order Code 
> > > Injection Attacks".
> > Cool - hopefully it useful to others as well.
> > > Concerning your protection recommendations I think that they must 
> > > supplemented:
> > > - An attack has a direction. For example SQL-Injection is a back-end 
> > > directed attack. XSS in contrast is a front-end directed attack. To 
> > > get the optimal protection it is necessary to prevent in direction 
> > > of the attack. For SQL-Injection this results in input validation 
> > > and for XSS this results in output encoding (' -> &quote).
> > While correct for a large number of cases, this is not particularly 
> > true for second-order code injection attacks.  For example, malicious 
> > SQL code may be injected into an address field, and only executed as 
> > part of a SQL query much later on a remote system (e.g. an analysis 
> > tool for shortest-path delivery routes).  This may be extended such 
> > that the SQL injection's purpose is to force a ackend database (or 
> > helpdesk MDB file) to pull down more laicious code... basically XSS 
> > through SQL statements.
> > Sanitisation of "dangerous" characters such as single-quote is always 
> > to be recommended as the first port of call.  However, there are more 
> > than 40 different (and commonly used) ways of encoding this character 
> > that are effective on UK-English/US-English/International-English 
> > formats... this expands more when dealing with other language 
> > systems.
> > > - I think that removing characters does often not meet complex 
> > > business requirements (Think of family names like D'Amato). An 
> > > backend application does often not know which other applications are 
> > > dependant on that data. So every component using data must protect 
> > > itself. Especially in case of HTML GUIs the application must perform 
> > > output encoding.
> > This is correct - but you have to start somewhere.  There most 
> > certainly isn't a "silver bullet" for handling particular groups of 
> > dangerous characters.
> > > - When auditing XML based application it must be verified that the 
> > > XML documents encode the content properly.
> > Easier said than done.  The process of verifying that XML documents 
> > are encode properly may actually intruce yet another vulnerable layer 
> > to the application.
>
> --
> Rogan Dawes
>
> *ALL* messages to discard () dawes za net will be dropped, and added
> to my blacklist. Please respond to "lists AT dawes DOT za DOT net"
 ----------------------------------------------------------------------
 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.
 ----------------------------------------------------------------------