[Home] [By Thread] [By Date] [Recent Entries]
David,
Thank you for the excellent reply. See my comments below. On May 29, 2006, at 11:53 PM, David Carlisle wrote:
Excellent clarification. In some instances users are allowed to insert XHTML and for those instances I'm running standard HTML input sanitization routines (encoding potentially dangerous elements as entities, for example).
It's not clear what I mean because the whole unicode/utf-n is unclear to me, in spite of how much I read about it, but I understand what you're saying and you seem to have understood where I'm coming from. The bottom line is I want to avoid the kinds of attacks that are common in URLs, where the less-than and greater-than symbols of a SCRIPT element can be URL encoded and in some browsers/servers, go undetected.
Yes. These situations are handled with standard HTML sanitizing routines prior to insertion, but it did make me wonder what other doors I might leaving open by providing users with completely valid XHTML on the output. This article, in particular, opened my eyes to what is possible with JavaScript. Now that more and more browsers are shipping with XSLT processors built in (or could ship that way), it opens the door for client-side processing with somewhat unpredictable results, doesn't it? http://www.webappsec.org/projects/articles/071105.shtml Thanks again for your concise reply! Ted Stresen-Reuter
|

Cart



