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

[Rogan Dawes <discard () dawes za net>]

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"