6 ms·

I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ‮ppa.emorhCelgooG

by Rygu 15y ago

yahelc 15y ago
Whoa. Check out you did to the markup of this page. http://d.pr/HKSQ http://d.pr/HKSQ
- nzmsv 15y ago
  Looks like the bug is in Chrome's View Source - the markup itself is fine.
  - cbr 15y ago
    Is it a bug? Or is chrome correctly interpreting the right-to-left override character it sees in the source?
    - nzmsv 15y ago
      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.
  - yahelc 15y ago
    Are you sure? curling from Terminal, I get the same result.
    - cbr 15y ago
      That's probably because your terminal interprets the RLO character. Should it? I'm not sure.
      - icebraining 15y ago
        rxvt-unicode, despite being perfectly able to display unicode characters (hence the name), drops the RLO.
- aw3c2 15y ago
  Ha, nice catch! edit: I get the same in Opera 11.50, Firefox 5.0 and some Chrome version.
- jerf 15y ago
  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/dirlang.html#h-8.2.2 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.)
  - yuvipanda 15y ago
    Is this 'really, really paranoid' library available somewhere?
    - jerf 15y ago
      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/ http://htmlpurifier.org/ .
      - yuvipanda 15y ago
        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?
        jerf 15y ago
        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.
jerrya 15y ago
This is an interesting page from 2006: http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-mirroring.html http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-... and seems to demonstrate to me that Firefox, Opera, and Internet Explorer all will eagerly display the RLO character, and Chrome and Safari will not. Is Chrome and Safari broken or being responsible? (Are there settings to change the behaviors in any of these browsers...?)
lobo_tuerto 15y ago
Inspecting the element with Chrome shows an amusing behavior. Try it.
xtacy 15y ago
Try selecting the text, it behaves funnily in a way that I can't understand!
- bzbarsky 15y ago
  It behaves funny in a very "simple" way. Selections have this little problem where you move your mouse over the visual representation but the selection is in the logical representation. So say your logical text is this: ltr LTR. where the capital letters are RTL chars (whether because they're actually RTL or because of an RLO in the char stream). That is, the above represents the reading order. Visually this would look like this: ltr RTL. assuming that this paragraph directionality is left-to-right; a reader reading this text would read the letters in the order 'l', 't', 'r', ' ', n 'L', 'T', 'R' (which if you note matches the logical order, hence the name). Now say you mouse down between the 't' the 'r' and drag right until your mouse is between the 'R' and the 'T'. Those are your selection endpoints. But the selection happens on the _logical_ text, so what's selected is the 'r', the space, the 'L', and the 'T' (and even in that order). You can see that in the example above; if you mouse down between the two 'o' chars in "elgooG" and drag right to between the two 'o' chars in "Google", then you get exactly this sort of behavior.
  - xtacy 15y ago
    Ah, that makes sense. I didn't think that text selection defines end points and everything between the endpoints (in the physical text) is highlighted. So, if you have: Hi RLO elgooG ^ select ^ I expected (everything between the logical end points selected): Hi Google ^^^^^^^ (selected) In other words, I expected text selection to obey RLO character as well.
    - groby_b 15y ago
      Nope - selection is on logical text, not on visual text. For tons of "fun" reasons. If you want an afternoon of madness, read the Chrome or WebKit sources relating to BiDi text. If that's not enough pain, read http://unicode.org/reports/tr9/ http://unicode.org/reports/tr9/ (the unicode BiDi algorithm) If you're still liking it, I know a few people who'd love to hire you :)
username3 15y ago
Go to ‮http://www.yahoo.com/q=google+oohay=q?/moc.elgoog.www//:ptth http://www.yahoo.com/q=google+oohay=q?/moc.elgoog.www//:ptth :ta elgooG
- Rygu 15y ago
  This is really dangerous. Luckily the status bar reveals the real URL. However it's still dangerous when you use a visually trusted address like Gmail: ‮ http://nyan.cat/?0/u/liam/moc.elgoog.liam//:sptth http://nyan.cat/?0/u/liam/moc.elgoog.liam//:sptth
Dove 15y ago
How many failed 0x202Egp registrations do you suppose there have been in the last hour?

I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ‮ppa.emorhCelgooG

by Rygu 15y ago

I'm pretty shocked that I have never heard of the RLO unicode character before this article. Let's see if it works: ppa.emorhCelgooG => ‮ppa.emorhCelgooG

yahelc 15y ago

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

nzmsv 15y ago
Looks like the bug is in Chrome's View Source - the markup itself is fine.
- cbr 15y ago
  Is it a bug? Or is chrome correctly interpreting the right-to-left override character it sees in the source?
  - nzmsv 15y ago
    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.
- yahelc 15y ago
  Are you sure? curling from Terminal, I get the same result.
  - cbr 15y ago
    That's probably because your terminal interprets the RLO character. Should it? I'm not sure.
    - icebraining 15y ago
      rxvt-unicode, despite being perfectly able to display unicode characters (hence the name), drops the RLO.
aw3c2 15y ago
Ha, nice catch! edit: I get the same in Opera 11.50, Firefox 5.0 and some Chrome version.
jerf 15y ago
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/dirlang.html#h-8.2.2 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.)
- yuvipanda 15y ago
  Is this 'really, really paranoid' library available somewhere?
  - jerf 15y ago
    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/ http://htmlpurifier.org/ .
    - yuvipanda 15y ago
      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?
      - jerf 15y ago
        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.

jerrya 15y ago

This is an interesting page from 2006: http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-mirroring.html http://digitalpbk.blogspot.com/2006/11/fun-with-unicode-and-... and seems to demonstrate to me that Firefox, Opera, and Internet Explorer all will eagerly display the RLO character, and Chrome and Safari will not. Is Chrome and Safari broken or being responsible? (Are there settings to change the behaviors in any of these browsers...?)

lobo_tuerto 15y ago

Inspecting the element with Chrome shows an amusing behavior. Try it.

xtacy 15y ago

Try selecting the text, it behaves funnily in a way that I can't understand!

bzbarsky 15y ago
It behaves funny in a very "simple" way. Selections have this little problem where you move your mouse over the visual representation but the selection is in the logical representation. So say your logical text is this: ltr LTR. where the capital letters are RTL chars (whether because they're actually RTL or because of an RLO in the char stream). That is, the above represents the reading order. Visually this would look like this: ltr RTL. assuming that this paragraph directionality is left-to-right; a reader reading this text would read the letters in the order 'l', 't', 'r', ' ', n 'L', 'T', 'R' (which if you note matches the logical order, hence the name). Now say you mouse down between the 't' the 'r' and drag right until your mouse is between the 'R' and the 'T'. Those are your selection endpoints. But the selection happens on the _logical_ text, so what's selected is the 'r', the space, the 'L', and the 'T' (and even in that order). You can see that in the example above; if you mouse down between the two 'o' chars in "elgooG" and drag right to between the two 'o' chars in "Google", then you get exactly this sort of behavior.
- xtacy 15y ago
  Ah, that makes sense. I didn't think that text selection defines end points and everything between the endpoints (in the physical text) is highlighted. So, if you have: Hi RLO elgooG ^ select ^ I expected (everything between the logical end points selected): Hi Google ^^^^^^^ (selected) In other words, I expected text selection to obey RLO character as well.
  - groby_b 15y ago
    Nope - selection is on logical text, not on visual text. For tons of "fun" reasons. If you want an afternoon of madness, read the Chrome or WebKit sources relating to BiDi text. If that's not enough pain, read http://unicode.org/reports/tr9/ http://unicode.org/reports/tr9/ (the unicode BiDi algorithm) If you're still liking it, I know a few people who'd love to hire you :)

username3 15y ago

Go to ‮http://www.yahoo.com/q=google+oohay=q?/moc.elgoog.www//:ptth http://www.yahoo.com/q=google+oohay=q?/moc.elgoog.www//:ptth :ta elgooG

Rygu 15y ago
This is really dangerous. Luckily the status bar reveals the real URL. However it's still dangerous when you use a visually trusted address like Gmail: ‮ http://nyan.cat/?0/u/liam/moc.elgoog.liam//:sptth http://nyan.cat/?0/u/liam/moc.elgoog.liam//:sptth

Dove 15y ago

How many failed 0x202Egp registrations do you suppose there have been in the last hour?