消毒用於電子郵件的用戶輸入

我正在考慮從面向Internet的ASP.NET MVC5網站收集的用戶提供的輸入的xss消毒。在將這些輸入提交回瀏覽器時對這些輸入進行消毒處理是有充分文件記錄的。但是，在構建包含用戶提供的值的電子郵件的環境中，我還沒有找到如何最好地處理消毒的信譽指南。消毒用於電子郵件的用戶輸入

默認情況下，我將發送純文本消息，其中建議，我不需要對這些值進行HTML編碼。但是，我擔心的是現代的郵件客戶端將嘗試渲染任何事情看起來像 HTML 爲 HTML。

我可以的HTMLEncode一切，但後來我們考慮「公司名稱」，它可以很合理地包含「&」符號輸入，我並不熱衷於發送消息，上面寫着「Father &amp; Son Ltd.」

來源

2015-10-03 Neil Moss

我刪除了最後一行反擊近距離投票（我不同意）。 – Gray

因此，XSS可能存在於電子郵件中，並且在過去發生過，但它被認爲是電子郵件客戶端中的漏洞，與發件人無關。它幾乎只發生在基於網絡的電子郵件（如Gmail）而不是像Outlook一樣。電子郵件客戶端通常不會（也不應該）從電子郵件（特別是桌面客戶端）運行腳本。

所以，我要說，你真的不需要擔心這個問題。這將被視爲電子郵件客戶端中的一個漏洞，如果攻擊者知道這樣的漏洞，他們就不會打擾您使用您的奇怪客戶端，因爲他們可以通過發送郵件來準確製作電子郵件他們自己。

我只是從安全角度回答，如果您關注的是關於客戶端，包括款式/鏈接/等等，這是一個不同的問題。我會考慮任何電子郵件客戶端試圖呈現明文電子郵件，因爲HTML已被破壞，而不是您應該擔心的事情。

來源

2015-10-03 20:18:12 Gray

從安全角度來看，您的答案絕對正確。從聲譽的角度來看（如果「聲譽」甚至是一個詞），我會確保我的系統的用戶不能將它用作具有舊的未修補客戶端的毫無防備的用戶的攻擊媒介。如果我能做到的話。 –

@LasseV。卡爾森我可以看到這個觀點。我想我更傾向於減少發送錯誤格式電子郵件的機會（比如OP提到逃逸角色如何渲染）。我認爲這種情況下的聲譽損害仍然會落在客戶供應商身上。因爲，正如我所說的，惡意攻擊者寧願自己發送電子郵件，而不願意通過其他服務，這些服務可能會破壞他們的惡意工作流程。 – Gray

除聲譽提升外。如果您可以通過我的系統發送電子郵件給我的用戶，我的用戶可能會相信我而不是您，所以他們可能更有可能點擊鏈接或來自我的系統的任何電子郵件中的* *如果它來自某些用戶interwebs上的奇怪傢伙。從技術的角度來看，你的答案就我所能說的來說（無可否認，這並不意味着什麼）。從「我會用這種思維方式構建一個我自己的系統」的立場來看，他不會。我會限制我的用戶編寫基本文本，至多是使用Markdown呈現的東西，並將其留在那裏。 –

當您發送一封電子郵件，您可以指定是否將是一個純文本或HTML電子郵件。

MailMessage mail = new MailMessage("[email protected]", "[email protected]"); 
mail.IsBodyHtml = false; 
...

這會添加一個標題，指示電子郵件客戶端如何顯示電子郵件內容。現代電子郵件客戶端將尊重這一設置

因此，如果您發送的是純文本電子郵件，不要做任何逃避HTML值。

如果您發送的HTML電子郵件，你要HTML編碼任何用戶提供的值。這不是一個安全問題，而是一個正確的問題：如果您的用戶輸入"Bruce Lee<Chuck Norris"，即使它不是惡意的，您也不希望在該點之後的電子郵件的其餘部分被解釋爲一個巨大的HTML標記，使得它對用戶是有效的不可見的。

如果您確實最終發送了一個HTML體的電子郵件，您不會希望整個模板都是純文本格式。默認情況下，你可能要考慮using a Razor template，這將給你構建的HTML的電子郵件更好的工具支持，原因模型爲基礎的值是HTML編碼：

@model WelcomEmailModel 

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

<p>...

來源

2015-10-03 21:09:08 StriplingWarrior

消毒用於電子郵件的用戶輸入

回答

相關問題