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