Re: ISA Server 2004 Log Manipulation

["Steven M. Christey" <coley@xxxxxxxxx>]

>You can insert the 'tab' value and possibly break 3rd party log
>analyzers.

OK, this makes sense - if ISA supports tab-separated format, then tab
is a special character within such a log file, and attackers should be
prevented from injecting it (by filtering, quoting, whatever...)

>Other interesting characters may be ... a "<" character for CSS, and
>whatever else your heart desires.

This is a bit more difficult.

Are you saying that there's a web interface or static HTML reports,
provided by ISA, that don't handle "<" characters when they are
processing ISA log files?  Then I would view it as a vuln in the web
interface or HTML page generator.

Are you saying that ISA should protect against all possible XSS
attacks that might be launched against third-party or external
applications that might happen to have XSS issues when they parse log
files from ISA?  If so - then I don't think that should be ISA's
responsibility.

How might one handle this?  To protect against XSS, you could quote
the "<" to be "&lt;" - but then, your quoting has just allowed the
attacker to exploit shell metacharacter vulnerabilities in any
applications that process the log file.  Well, you could remove the
"<" completely - but then you've mis-represented the actual inputs
that the attacker provided, hampering possible forensics activities.

I don't think it should be one application's responsibility to protect
against all the possible attacks that could be launched against
third-party products that happen to parse the original application's
output - unless either the application's core functionality is to
protect against such an attack (e.g. an anti-virus product that sits
between the Internet and a desktop machine).

More to the point - I don't think it's *possible* for one application
to protect against all the ways that its own outputs could be
mis-interpreted by other downstream products that are outside of its
own control.  A gray area occurs with interaction errors between two
products that function correctly when separate, but somehow have
issues when they work together - but this is rarely encountered.

Sorry if this was not what you originally meant - but it's a useful
point of discussion, regardless :)

- Steve