[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bypassing of web filters by using ASCII
I've found that the two methods you described work, e.g. using HTML such as this:
<link rel="stylesheet" type="text/css" href="ascii.css">
<span>If this text is orange and an alert appears, the obfuscated JS in the CSS was evaluated</span>
and a CSS file like this:
óðáî û ãïìïòº ïòáîçå» âáãëçòïõîäº õòì¨§êáöáóãòéðôºáìåòô¨¢èåììï¢©»§© ý
/* code above is
The color attribute and JS code get executed in IE.
I could not get @charset to work as an inline style directive.
Setting document.charset also works, although I have to reload the page in IE
(this can probably be avoided with some further hacking):
<script>document.charset = 'US-ASCII';</script>
So to change the charset, you need to be able to inject into the stylesheet,
include a remote stylesheet, or inject script code to set document.charset.
If any of those are possible, an attacker may as well inject malicious code directly,
though being able to obfuscate the JS code in this way may help bypass client side filters.
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.
Internet Security Specialist, Westpoint Ltd
Albion Wharf, 19 Albion Street, Manchester M1 5LN, United Kingdom
James C. Slora Jr. wrote:
> Amit Klein wrote Thursday, June 22, 2006 3:47 AM
>> So in order to exploit this in HTML over HTTP, the attacker needs to
> either add/modify the Content-Type response header, or to add/modify the
> META tag in the HTML page.
> There are other ways that might carry a bigger injection threat:
> Style sheet:
> Object property:
> By extension, it should also work for inline styles.