[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
On Monday 29 Sep 2003 2:12 am, Simon Waters wrote: > Neil Williams wrote: > > 4. Most people here are not Windows users so it isn't a direct threat to > > security but HTML email still has that reputation (and rightly so). > > I disagree, I would suggest that HTML mail exercises sufficiently extra > ways through the code that it presents a significantly increased threat > to security on all major platforms. > > Linux mail clients aren't magically exempt from security problems. They > may be better engineered, and better supported <sic>, and the OS may > provide some extra protection, than the most exploited mail client and > OS(es), but all it takes is one buffer overflow (at least on most > platforms). > > Why do you think Kmail does that text only view of HTML? Call it > defensive coding. Agreed. There's a lot of discussion on HTML rendering on the KMail list but I've recently unsubscribed as it was generating too much mail. Basically HTML is too large a topic to re-code for one app so the only route is to open up the email client to the entire HTML engine used by whatever browser is built-in. This makes the email client vulnerable and there's been a lot of wrangling about that 'defensive coding'. It got quite heated but the defensive default is staying, for now at least. I know I won't use KMail if it goes. (I said so too, but it came across as a bit of a rant.) > 10. Allows cross site scripting attack against mailing list archives... > that security thing again... although hopefully Neil is on top of this one. Default MHonArc behaviour: Any markup related to scripting is removed for security reasons. Javascript URLs are munged to make them ineffective. At a minimum, the following tags are stripped: <applet>, <base>, <embed>, <form>, <ilayer>, <input>, <layer>, <link>, <meta>, <object>, <option>, <param>, <script>, <select>, <style>, <textarea>. At a minimum, the following attributes are removed: onload, onunload, onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup. http://www.mhonarc.org/MHonArc/doc/resources/mimefilters.html#default This can be extended if necessary to either: 1. Strip all HTML no matter what - Which relates to your comment: > Especially if it inserts a plain text version for people without HTML > capable clients! This is a particularly daft behaviour, either the HTML > version adds something, in which case don't lose that by automatically > converting to text, or it doesn't so why send it in HTML in the first place? In this scenario, it's useful because if this option is enabled, only the secondary plain text version will be archived. HTML messages with no plain text alternative will simply hit the archive /dev/null I see this as a little drastic as although HTML is not exactly welcomed here, it's not much good for the archive to skip HTML messages entirely - it would make the archive less readable if the first message disappears. If all HTML clients actually sent the duplicate plain text, it wouldn't be a problem! ;-) 2. Mung all HTML to plain text. Personally, I'm not so keen on this one. Why? http://www.codehelp.co.uk/php/taint.php This will prevent the content of the tag from being executed by the browser but will still allow the content of the tag to be incorporated into the input. Whilst this is safe, it is still intrusive. It's one of those swap < for < but preserve the contents. (Which will quickly be indexed by Google and possibly give us the reputation of documenting how to use Cross-Site Scripting (XSS).) So far, I'm happy with the default. Mark's HTML message has been preserved in the archive with the colours that he wanted but all that does is make that one page non-HTML4 compliant. I can live with that. http://www.dclug.org.uk/archive/msg01322.html > > want to emphasise something, use smilies or underline it like this. > > **************** Actually this reflects another problem, more general than HTML. This should have lined up in the archive but I've had to adjust the CSS to override certain pre behaviour, including spacing because some people just don't seem to have line-wrapping enabled. I've had a string of emails over the years where it is all on one line. This, understandably, causes consternation in an archive, particularly when the background colour of the outer edge of the page is black! :-( So I've had to force pre to behave much more like code - it uses the monospace but uses CSS block control to force the lines to wrap within the enclosing block. Why can't this be solved? It's only odd emails, it's not easy to tell from your email client if it's happening but it certainly used to wreck the archive. Again, it's only the original message that is affected, as soon as someone replies to the bad message in a decent email client, hard line endings are incorporated. > Smilies? Well I like smilies, but probably the exclamation mark is > better style! > > ¡Ola! The Spanish win here, marking the emphasis at the correct place in Alright smarty pants, what's the key sequence for your artwork? How can you expect it to adopted if you don't explain how to enter it? ;-) > > Since I switched to whitelisting (challenge/response) I stopped > filtering unexpected HTML mail straight to the probably spam bucket Except that containing base64 encoded HTML? Who is it that keeps sending that stuff? I could never read it even if I wanted to! Any base64 HTML just gets binned. > (Rick has the dubious honour of being the only false positive), but I Now I get that too - I'm sorry Rick, but twice now I've had to recover your email from the trashcan! I've added a filter now to look for your email addresses and skip the spam test! (So don't go changing your email address without telling me!) I reckon if you could sign your emails, Rick, it might overcome the false positives. (Your posts to the list are never affected because of the mailing list id but your personal messages do seem to give problems. > All the mail clients I use regularly support HTML, excepting mailx but > I'd be damn annoyed if you managed to send mail to those systems, given > the firewalling, and the lack of an SMTP daemon ;) Exactly, my mail clients support HTML but don't ever expect me to allow it to be shown as HTML. The little 'click here if you trust this message' link is destined to languish through lack of use. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00052.pgp
Description: signature