邮件正文是否存在注入漏洞？
据我所知，当使用正确的用户数据时，只有电子邮件标题中存在漏洞？
我正在使用下面的函数来清理我的数据，但是我在页面和页面上有一些文本区域字段。因此这些可能包含换行符..所以想知道用户数据是否只会放入电子邮件正文中，是否可以不麻烦地进行清理 - 当然除了剥离 html 之外？
这是功能：
function is_injected($str) {
$injections = array('(\n+)',
'(\r+)',
'(\t+)',
'(%0A+)',
'(%0D+)',
'(%08+)',
'(%09+)'
);
$inject = join('|', $injections);
$inject = "/$inject/i";
if (preg_match($inject,$str)) {
return true;
} else {
return false;
}
}
作为旁注，令人惊讶的是目前没有邮件注入/电子邮件注入的标签。
AFAIK there is only a vulnerability within the HEADERS of an email when using user data correct?
I am using the below function to sanitize my data, however I have some textarea fields on the page & hence these may contain linebreaks.. so was wondering if that user data is only going to be put in the body of the email, can it not bother with being sanitized - apart from stripping html of course?
Here is the function:
function is_injected($str) {
$injections = array('(\n+)',
'(\r+)',
'(\t+)',
'(%0A+)',
'(%0D+)',
'(%08+)',
'(%09+)'
);
$inject = join('|', $injections);
$inject = "/$inject/i";
if (preg_match($inject,$str)) {
return true;
} else {
return false;
}
}
As a side note, surprised there wasn't currently a tag for mail-injection / email-injection.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您使用本机 SMTP 与邮件服务器通信，则可能会在正文中注入内容。
单个
.本身会终止 SMTP 中的当前正文，因此理论上您可以让用户提供如下输入：并且 SMTP 服务器可能允许第二条消息通过。
一些 SMTP 服务器可以配置为不允许 SMTP 命令通过管道传输（即要求客户端在允许下一个命令之前读取响应）来防止这种情况发生。
There's a possible injection in the body text if you're speaking native SMTP to the mail server.
A single
.on its own terminates the current body in SMTP, so in theory you could have user supplied input like this:and the SMTP server might allow the second message through.
Some SMTP servers can be configured to prevent this by not allowing SMTP commands to be pipelined (i.e. requiring the client to read the response before permitting the next command).
如果电子邮件是 HTML 邮件，特别是如果收件人要在基于 Web 的电子邮件（Hotmail、Gmail、Yahoo 等）或支持 HTML 视图的电子邮件客户端中查看它，则注入正文是绝对是一个问题——XSS 可能发生在任何地方。
If the email's an HTML mail, and particularly if the receiver's going to be viewing it in a web-based email (Hotmail, Gmail, Yahoo, etc...) or an email client that supports HTML views, then injection into the body is definitely a concern - XSS can happen anywhere.
动态 MIME 更改也可能发生。
当我们发送邮件时，我们通常在脚本中定义内容类型，例如：
问题是 - “Content-Type”标头可以重新定义为多部分/混合（或多部分/替代或多部分/相关），即使它是之前定义的。
示例 - 假设有人在您的联系页面上的电子邮件正文字段中输入以下内容：
这会做什么 - 当用户收到此消息时，他只会看到垃圾邮件发送者的消息（由“--frog”分隔的消息），根据 mime multipart /混合规格。开发人员可能硬编码的原始“联系”消息 - 也将包含在电子邮件内，但不会显示给收件人。
这样，垃圾邮件发送者就可以从其他人的域发送垃圾邮件。
特别是如果它是某种：“将其发送给你的朋友”。形式。
另外 - 在过滤邮件标题时，我使用（我猜比你那里的要短一点）：
Something that might also happen is dynamic MIME change.
When we send mail we usually define Content-type in our script, example:
The catch is - "Content-Type" header can be re-defined as multipart/mixed (or multipart/alternative or multipart/related), even though it was previosly defined.
Example - imagine that someone types this into email body field on your contact page:
What this will do - when user receives this message, he'll only see spammer's message ( the one delimited by "--frog"), as per mime multipart/mixed specification. Original "contact" message that developer perhaps hardcoded - will be inside of the email as well, but will not be displayed to the recipient.
This way spammers can send spam from other people's domains.
Especially if it's some sort of: "send it to your friend." form.
Also - when filtering mail headers, I use (a bit shorter I guess than what you have there):
如果边界不是随机的，您还可以将 MIME 边界注入多部分消息中。这样您就可以注入任意内容（例如带有恶意软件的附件）。
示例（不直接与电子邮件相关，但仍然）： https://bugzilla.mozilla.org/ show_bug.cgi?id=600464
You can also inject MIME boundary into multipart messages, if the boundary is not randomized. That way you can inject arbitrary content (e.g. attachements with malware).
Example (not directly email-related but still): https://bugzilla.mozilla.org/show_bug.cgi?id=600464