3

I am considering the xss sanitization of user-supplied inputs gathered from an Internet-facing ASP.NET MVC5 web site. Sanitizing such inputs when presenting them back in a browser is well-documented and catered for. However, I haven't found reputable guidelines for how best to handle sanitization in the context of constructing emails which contain said user-supplied values.

By default, I will be sending plain-text messages which suggests that I don't need to HTML-encode these values. However, I am concerned that modern mail clients will attempt to render anything which looks like HTML as HTML.

I could just HtmlEncode everything, but then we consider the input for "Company name" which can quite legitimately contain the "&" symbol and I'm not keen on sending a message that reads "Father & Son Ltd."

Gray
  • 7,050
  • 2
  • 29
  • 52
Neil Moss
  • 6,598
  • 2
  • 26
  • 42

2 Answers2

2

So, it is possible for XSS to exist in email, and has happened in the past, but it is considered a vulnerability in the email client, nothing to do with the sender. It pretty much only happens in a web-based email (like gmail) rather than something like Outlook. Email clients don't generally (and should not) run scripts from emails (desktop clients especially).

So I would say you don't really need to worry about this issue. It would be considered a vulnerability in the email client, and if such a vulnerability was known by an attacker, they wouldn't bother using your weird client, when they would be able to craft an email exactly how they'd like by sending it themselves.

I am only answering from a security standpoint, if your concern is about the client including styles/links/etc, that's a different issue. I would consider any email client trying to render a plaintext email as HTML is broken and not something you should worry about.

Gray
  • 7,050
  • 2
  • 29
  • 52
  • From a security standpoint, your answer is absolutely true. From a reputational standpoint (if "reputational" is even a word), I would make sure users of my system couldn't use it as an attack vector on unsuspecting users with old unpatched clients. If I could that is. – Lasse V. Karlsen Oct 03 '15 at 20:22
  • @LasseV.Karlsen I could see that perspective. I guess I am leaning more towards reducing the chance of sending mal-formatted emails (like how the OP mentioned escaped characters rendering as-is). I think the reputational damage in this case would still fall on the client vendor. Because, like I said, a malicious attacker would rather just send the emails themselves rather than go through some other service, where their malicious workflow could be broken. – Gray Oct 03 '15 at 20:26
  • Except for a reputational boost. If you can send an email through my system to my users, my users might trust me and not you, so they may be more likely to click on links or whatever in emails *from my system* than they would be if it came from some odd fella on the interwebs. From a technological standpoint, your answer is as far as I can tell (which admittedly doesn't mean much) to the point. From a "would I use this way of thinking to build a system of my own" standpoint, he** no. I would limit my users to writing basic text, at most something rendered using Markdown, and leave it at that. – Lasse V. Karlsen Oct 03 '15 at 20:29
  • That's not completely true. Including a "file:///" link will create a security issue also for desktop applications. Not to mention that sending an email from a system creates an impersonation issue which is hard to solve (No links have to be there to attack, an attack can be also through a message inside the text). The fact that free text emails can be sent from a system is a security risk by itself. – Cesar Jan 11 '23 at 10:57
0

When you send an email, you can specify whether it's going to be a plain-text or an HTML email. 

MailMessage mail = new MailMessage("you@yourcompany.com", "user@hotmail.com");
mail.IsBodyHtml = false;
...

This adds a header instructing the email client how to display the email content. Modern email clients will respect this setting.

So if you are sending a plain-text email, don't do anything to escape HTML values.

If you are sending an HTML email, you'll want to HTML-encode any user-provided values. This is not a security matter, so much as a matter of correctness: If your user inputs "Bruce Lee<Chuck Norris", even if it's not maliciously, you don't want the rest of the email after that point to be interpreted as a giant HTML tag, making it effectively invisible to users.

If you do end up sending an HTML-bodied email, you won't want the overall template to be in plain-text. You may want to consider using a Razor template, which will give you better tooling support for constructing the HTML for the email, and cause model-based values to be HTML-encoded by default:

@model WelcomEmailModel

<p>Dear @Model.CompanyName,</p>

<p>...
Community
  • 1
  • 1
StriplingWarrior
  • 151,543
  • 27
  • 246
  • 315