Hacker News Reader

Comment by yahelc | Hacker News Reader

Whoa. Check out you did to the markup of this page. http://d.pr/HKSQ

The HTML standard specifies that changes in text direction are bounded to the block they occur in: http://www.w3.org/TR/1999/REC-html401-19991224/struct/dirlan...

I discovered this as I was writing a paranoid HTML cleanup library and wanted to prevent the attack where a user sticks a text-direction-change character into the page and reverses the whole thing. As we've all just witnessed, that can't happen in a conforming browser.

But when viewing the page as a text stream, yup, it reverses and then never really unsticks. Everything's working as designed!

(Maybe my library should still restore the page flow after all... I never thought of how it could mess up view source. As attacks go, it's weak sauce... but like I said, it's meant to be really, really paranoid.)

Is this 'really, really paranoid' library available somewhere?

Not yet. But it'll be in Haskell anyhow, so you're probably not actually interested :)

There are other such libraries for other languages, poke around. See for instance http://htmlpurifier.org/ .

Even more intriguing. What exactly were you writing in Haskell that needed a super-paranoid html sanitizer? Yet another web server/blog/cms? Or something way more cooler?

Yet another blog, except not targeted for release or anything, just to run my own site. To replace the Django blog that runs my site. It's sort of my entertaining diversion, you know? Working with my own fresh, clean code base where I can try some ideas out without having to carry around a couple of man-centuries worth of legacy code every time I step at work. The cleansing library doubles as my HTML formatter, too, doing things like ensuring close italic tags and such. The paranoia is half real, half fun exercise.

Ah, yes - I see where you're coming from. Some day I hope to finish my blog, written in C :D Good luck for your haskell blog :)

Doesn't the library just have to perform a simple search-and-replace on the entire page's HTML for the blacklisted characters to remove them?

Normally blacklisting is bad, but we're only targeting the few text-direction-changing characters that exist.

Looks like the bug is in Chrome's View Source - the markup itself is fine.

Is it a bug? Or is chrome correctly interpreting the right-to-left override character it sees in the source?

Good point. It is probably the right thing to do technically, since the source view can't rely on parsing the markup. I think I'd prefer such non-printable characters to be simply escaped though.

Are you sure? curling from Terminal, I get the same result.

That's probably because your terminal interprets the RLO character. Should it? I'm not sure.

rxvt-unicode, despite being perfectly able to display unicode characters (hence the name), drops the RLO.

Ha, nice catch!

edit: I get the same in Opera 11.50, Firefox 5.0 and some Chrome version.

Reply on news.ycombinator.com