Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Based on this report, I’m wondering if Flash/AS3 also processes the right-to-left override and right-to-left embed characters?
For example, would a chat program implemented in AS be vulnerable to someone using RTLO/RTLE to circumvent profanity filters (e.g. writing “\u202E!nmad” to write “damn!”) or impersonate another user (e.g. putting “\u202EmoT” as their username to show up as “Tom”)?
If this is true, what countermeasures can be taken to avoid these issues?
It’s to do with the text renderer rather than ActionScript as such. If you’re using the new Flash 10 text renderer that supports bidirectional and complex text layout, then yes, user input may render in an unexpected way. The new text renderer is used by classes such as
TextLine. You can see this in action by pasting something like:into the text layout example demo at http://blog.theflashblog.com/?p=442.
In the old text renderer you won’t get this, but you also won’t be able to render complex scripts properly either.
When you are accepting untrusted user input for inclusion in a wider string of text, whether or not Flash is involved, you should filter out these characters. A good group to choose to filter out is the one described by W3C as not suitable for use in markup. This includes the bidi overrides and a bunch of other generally troublesome control codes.
I would recommend most web applications routinely filter out all of these, as well as all the ASCII and C1 control codes other than newline (U+0000–U+0009, U+000B–U+001F, U+007F–U+009F).
(Profanity filters aren’t a compelling reason to disallow bidi IMO—they’re so easily fooled by almost anything that it’s not even worth bothering.)