为什么不在取消订阅链接中使用电子邮件地址
请告诉我几个为什么不以纯文本形式包含电子邮件地址以取消在我们的时事通讯中发送的取消订阅链接的原因。
现在是：
xyz.net/unsubscrible?uid=123&[email protected]
我正在推动：
xyz.net/unsubscrible?uid=123&key=(encrpted_email_md5hash).
我真的不喜欢以纯文本形式提供电子邮件地址的想法，但需要说服我的经理了解可能的威胁。
更新：虽然所有答案都建议我应该如何保护它，而不是为什么我应该保护它，但我发现 do-ob 的答案最合适。
Give me few reasons why NOT to include email addresses in plain text form for unsubscribe link that gets sent out in our newsletters.
Right now it's:
xyz.net/unsubscrible?uid=123&[email protected]
I am pushing for:
xyz.net/unsubscrible?uid=123&key=(encrpted_email_md5hash).
I don't really like the idea of throwing email addresses in plain text, but need to convince my manager for possible threats.
Update: While all the answers were suggesting how I should secure it and NOT reason why I should secure it, I find do-ob's answer most appropriate.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
因为这样您就可以取消订阅其他人。理想情况下，您只想使用一个密钥：
我不应该能够猜测 ID 和电子邮件并导致其他人执行某些操作。
Because then you can unsubscribe somebody else. Ideally you want to use only a key:
I shouldn't be able to guess at ids and emails and cause some action to occur for somebody else.
出于同样的原因，银行没有像
这样的链接很容易被拦截和解释。
For the same reason that banks don't have links like
it can easily be intercepted and interpreted.
我收到的几乎每份时事通讯底部都有免责声明，例如：
我发现时事通讯中明确列出我自己的电子邮件地址很有帮助。
电子邮件地址是否在取消订阅链接中，似乎与我无关。
假设您没有在消息的实际文本中或取消订阅链接中发布电子邮件地址。电子邮件地址仍在电子邮件标题中。因此，我并没有真正看到在取消订阅链接中隐藏它的必要性或理由。
Pretty much every newsletter I get has a disclaimer at the bottom, something like:
I find the explicit listing of my own email address in the newsletter to be helpful .
Whether the email addy is in the unsubscribe link or not, seems irrelevant to me.
Suppose you don't publish the email address in the actual text of the message, or in the unsubscribe link. The email address is still in the email message header. As a result, I don't really see the need or reasoning behind obscuring it within the unsubscribe link.
为什么不呢？不要包含它因为不需要。这些数据的用途是什么？建议我们不要在查询字符串中包含任何我们实际上不需要的内容。
唯一实际需要的是唯一标识符。看起来您在查询字符串中已经有了一个唯一标识符：
uid。一个潜在的问题：是什么阻止我自动创建取消订阅 URL 并点击
?uid=从 1 到 1000 万？建议：为表中的每个用户创建一个用户 GUID。使用它作为您的取消订阅令牌。它不会被猜测或容易受到自动攻击。
Why not? Don't include it because it's not needed. What is that data being used for? Suggest that we don't include anything that we don't actually need on the querystring.
The only thing actually required is a unique identifier. It looks like you've got a unique identifier in the querystring already:
uid.A potential problem: what's stopping me automatically creating unsubscribe URLs and hitting
?uid=from 1 to 10 million?Suggestion: create a user guid for each user in your table. Use that as your unsubscribe token. It won't be guessable or vulnerable to automated attacks.
我猜 uid 是“用户 ID”。如果您知道用户 ID，那么您应该能够从中确定电子邮件地址吧？似乎在网址中包含电子邮件没有任何作用。我想如果您不必包含个人信息，那么最好不要这样做。
I'm guessing that uid is 'user id'. If you know the user id, then you should be able to determine the email address from that right? Seems like having the email in the url doesn't do anything. I guess if you don't have to include personal info, then best not do it.
我同意，如果您有其他方法来唯一识别用户，则不需要电子邮件地址。唯一的原因可能是向用户指示他/她订阅的电子邮件地址，但它也已过时，因为他/她显然收到了电子邮件。
I agree that you do not need the email address if you have a different method of uniquely identifying the user. The only reason might be to indicate to the user the email address with which he/she is subscribed, but that it also obsolete since he/she obviously receives the email.
我可以给你一个非常棘手的答案，但你会发现拥有完整的电子邮件地址并不是一个坏主意。
恶意代理（即来自公共场所）可能会使用包含电子邮件地址的 URL 来存储地址并发送垃圾邮件。但如果我认为公共场所存在恶意行为，最好在公共计算机上安装键盘记录器，甚至做更坏的事情。
另一点可能是：如果您向有价值的客户发送电子邮件，攻击者可能会伪造电子邮件地址并取消订阅它们，这实际上会降低您的通信强度。为此，您可以在 URL 中添加加密校验和（不需要验证码，人们在取消订阅时不喜欢它），然后通过加密（或只是以不明显的方式编码）整个邮件地址，您可以解决不使用两个参数的问题。
I could give you a very tricky answer, but you will find that having the full email address is not a so bad idea.
Having a URL containing an email address could be used by malicious proxies (ie. from public places) to store addresses and send spam. But if I suppose the public place has something malicious, better install a keylogger on the public computer and do even more bad.
Another point could be: if you are sending emails to valuable customers, an attacker may forge email addresses and unsubscribe them, actually reducing your communication strength. For this, you can add a crypto checksum to your URL (don't require CAPTCHA, people don't like it when unsubscribing), but then by encrypting (or just encoding in a non obvious way) the whole mail address you could solve the problem without using two parameters.
由于您没有使用
https，因此可以窥探查询参数。对于移动用户以及在咖啡店等有免费 Wi-Fi 的地方使用笔记本电脑的用户来说，这是一个严重的问题。由于 uid 已经映射到电子邮件地址，因此您无需向窥探者公开电子邮件地址等身份信息。
您确实需要确保他们点击链接后不会立即取消订阅。这是一个应该是幂等的 GET URL（请参阅 9.1 部分）不应该有权更改底层数据库。
而且我不应该仅仅通过知道您的电子邮件地址就有权取消订阅您，如果 uid 可以猜测或不需要，我可以通过伪造 URL 来取消订阅。
Since you're not using
https, query parameters can be snooped on. This is a serious problem for mobile users, and users of laptops in places with free wi-fi like coffeeshops.And since uid already maps to the email address, you don't need to expose identifying information like an email address to snoopers.
You do need to make sure that the unsubscribe doesn't happen as soon as they click on a link. That's a GET URL which should be idempotent (see section 9.1) meaning it shouldn't have authority to change the underlying database.
And I shouldn't have authority to unsubscribe you just by knowing your email address which I could do by forging a URL if uid is either guessable or not required.