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

["Mark Curphey" <mark () curphey com>]

Maybe a little of topic for the exact thread below but I get this stuff
straight (most of the time)in my head using a few ordering mechanisms.

1. I think of it as data validation and not input validation
2. I build sets of system boundaries. These maybe a view of an individual
component as a system (COM object) or a web application / service.
3. I then define trust boundaries or relationships between systems that
should or should not trust each other. 

Basic threat model I guess....


-----Original Message-----
From: Rogan Dawes [mailto:discard () dawes za net] 
Sent: Friday, November 12, 2004 3:36 AM
To: Gunter Ollmann
Cc: Jan P. Monsch; webappsec () securityfocus com
Subject: Re: New Whitepaper - "Second-order Code Injection Attacks"

Hi Folks

(please excuse my obfuscated reply address, it's an anti-spam mechanism)

I recently did some web application security training, and found that the
concept of "boundary validation" (not my own idea) or "boundary
quoting/escaping" (my own, I guess) was well received by the delegates.

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

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.

In my opinion, once data makes it into the application, it should always be
presented accurately. Ensuring that only valid data makes it into the data
is a somewhat different problem.

The example of the XSS via SMS is an example. In my opinion, the program
that received the SMS should have checked that it contained valid data, and
rejected it, AND the application that presented that data in HTML format
should have been escaping angle brackets before writing data to the output.

Can anyone suggest ways that this can be bypassed, or a situation in which
this could fail?

One side note: the domain can also be something like "a script section of an
HTML document", "a quoted string in a script section of an HTML document",
"an attribute of a tag in an HTML document", etc, as each of those domains
can have different quoting rules . . .

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

Rogan


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"