bugtraq - RE: Bypassing of web filters by using ASCII

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ED4D2B7262D0FF46B802B35FF362FE68538288@lincoln.fairfax.phra.com>
Date: Mon, 26 Jun 2006 15:31:58 -0400
From: "James C. Slora Jr." <james.slora@...a.com>
To: <bugtraq@...urityfocus.com>
Subject: RE: Bypassing of web filters by using ASCII

Hubert Seiwert wrote Monday, June 26, 2006 1:57 PM

> I don't currently see how this "ascii vulnerability" would make code 
> injection possible on webservers where the Content-Type is not 
> US-ASCII already, as the 3 methods mentioned to change the charset 
> (http-equiv content-type header, CSS @charset, document.charset) 
> depend on being able to inject things already.

Agreed - the ASCII vulnerability doesn't make servers less secure. It
doesn't make user-agents less secure either, since nothing here has
exposed any new attack vectors. It merely introduces a big, glaring,
open way for hostile code to evade detection when delivered from hostile
servers or in served code that is already vulnerable to injection. Doing
this without XSS can further exploit site trust.

So while the merits of IE's US-ASCII rendering choice can be easily
debated, products that claim to help protect IE users by detecting
hostile code need to step up and cover the ASCII issue fully.

- Jim