带有令牌参数的 https URL：安全性如何？
在我们的网站上，我们根据用户的私人信息（通过表格提供）向用户提供模拟。 我们希望允许他们稍后返回模拟结果，但不强迫他们创建登录/密码帐户。
我们考虑过向他们发送一封带有链接的电子邮件，他们可以从中获取结果。 但是，自然地，我们必须保护这个 URL，因为私人数据受到威胁。
因此，我们打算在 URL 中传递一个令牌（例如 40 个字母和数字的字符组合，或 MD5 哈希值）并使用 SSL。
最后，他们会收到这样一封电子邮件：
嗨，
返回您的结果 https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn
你觉得怎么样关于它？ 它足够安全吗？ 对于代币生成，您有什么建议？ 在 https 请求中传递 URL 参数怎么样？
On our site, we provide to users a simulation based on their private information (given through a form). We would like to allow them to get back on their simulation results later, but without forcing them to create a login/password account.
We have thought of sending them an email with a link, from which they could get back their results. But, naturally, we have to secure this URL, because private data is at stake.
So we're intending to pass a token (like a 40 characters combination of letters and digit, or a MD5 Hash) in the URL and to use SSL.
Finally, they would receive an email like that:
Hi,
Get back your results on
https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn
What do you think about it? Is it secure enough? What would you advise me for the token generation? What about passing URL parameters in a https request?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
SSL 将保护传输中的查询参数； 然而，电子邮件本身并不安全，并且电子邮件在到达目的地之前可能会经过任意数量的服务器。
另外，根据您的 Web 服务器，完整的 URL 可能会记录在其日志文件中。 根据数据的敏感程度，您可能不希望 IT 人员访问所有令牌。
此外，带有查询字符串的 URL 将保存在您的用户历史记录中，从而允许同一计算机上的其他用户访问该 URL。
最后，导致这种情况非常不安全的是，URL 是在对任何资源（甚至是第三方资源）的所有请求的 Referer 标头中发送的。 例如，如果您使用 Google Analytics，您将向 Google 发送 URL 令牌以及所有内容。
在我看来这是一个坏主意。
SSL will protect the query parameters in transit; however, email itself is not secure, and the email could bounce along any number of servers before getting to its destination.
Also depending on your web server the full URL might get logged in its log files. Depending on how sensitive the data is you might not want your IT people having access to all the tokens.
Additionally the URL with the query string would be saved in your user's history, allowing other users of the same machine to access the URL.
Finally and what makes this very insecure is, the URL is sent in the Referer header of all requests for any resource, even third party resources. So if you're using Google Analytics for example, you will send Google the URL token in and all to them.
In my opinion this is a bad idea.
我会为此使用 cookie。 工作流程应该是这样的：
现在，用户想在不同的机器上使用不同的浏览器。 在这种情况下，提供一个“转移”按钮。 当用户点击这个按钮时，她将获得一个“令牌”。 她可以在另一台计算机上使用此令牌来重置 cookie。 这样，用户就可以决定她想要传输令牌的安全程度。
I'd use a cookie for that. The workflow should be like this:
Now, the user wants to use a different browser on a different machine. In this case, offer a "transfer" button. When the user clicks on this button, she will get a "token". She can use this token on another computer to reset the cookie. This way, the user decide how secure she wants to transfer the token.
SSL 可以保护传输中数据的内容，但我不确定 URL。
无论如何，减轻攻击者重复使用该 URL 令牌的一种方法是确保每个令牌只能使用一次。 您甚至可以设置一个 cookie，以便合法用户可以继续使用该链接，但在第一次访问后，它只对拥有 cookie 的人有效。
如果用户的电子邮件被泄露并且攻击者首先获得了链接，那么您就完蛋了。 但用户也有更大的问题。
SSL secures the contents of the data in transit, but I'm not sure about the URL.
Regardless, one way to mitigate an attacker reusing that URL token is to make sure each token can only be used once. You could even set a cookie so that the legitimate user can continue to use the link, but after the first access it will only work for someone with the cookie.
If the user's email is compromised and an attacker gets the link first, well, you're hosed. But the user also has bigger problems.
电子邮件本质上是不安全的。 如果任何人都可以单击该链接并获取数据，那么您并没有真正保护它。
E-mail is inherently insecure. If anyone can click on that link and get to the data, you're not really protecting it.
通过 SSL 传递时，令牌是安全的。 您将遇到的问题是，人们（那些不适合它的人）可以通过查看 URL 来使用它。
如果是像 SSN 这样的私人信息，我想我不会通过电子邮件发送 URL。 我宁愿让他们为该网站创建用户名和密码。 对于您和他们来说，含有此类信息的电子邮件很容易被泄露。 如果某人的账户被泄露，那么这到底是谁的错就会受到质疑。 从严格的 CYA 角度来看，越安全越好。
Well the token is secure when being passed through SSL. The problem you are going to have is that it is avilable to people (those who it is not intended for) by being able to view the URL.
If it's private information like SSN I don't think I would send a URL through email. I would rather have them create a username and password for the site. It's too easy to compromise an email with that kind of information at stake for you and for them. If someone's account is comprimised it will come into quesion whose fault it really is. The more secure the better you are from a strictly CYA standpoint.
您是否知道，如果任何黑客能够访问您的数据库，则可以免费提供大量个人信息？
之后我会说这个主意还不错。 我不会使用 MD5 或 SHA1，因为它们对于散列来说不是很安全。 它们可以很容易地“解密”（我知道这不是加密）。
否则我可能会使用不会通过电子邮件发送的第二个信息（例如密码）。 原因很简单，如果有人可以访问用户的电子邮件（如果您不终止会话，则使用 hotmail 很容易），他将可以访问用户发送的任何信息。
请注意，HTTPS 将对从您的站点发送到最终用户的数据进行保护和加密。 别的不说，就把它当作一个安全隧道。 不多也不少。
You are aware that if any hacker get access to your database a lot of personnal information can be freely given ?
After that I would say that this is not bad as idea. I would not use MD5 or SHA1 as they are not very secure for hashing. They can be "decrypted" (I know it's not encryption) quite easily.
Otherwise I would maybe use a second information that would not be sent by email kind of a password. The reason is quite simple, if someone get access to the user's email (quite easy with hotmail if you don't kill your session) he will have access to any informations the user have sent.
Note that the HTTPS will secure and crypt data sent from your site to the end user. Nothing else, take it as a secure tunel. Nothing more nothign less.
对于存在严重隐私问题的情况，我真的不认为这足够安全。 事实上，您在（可能是明文）电子邮件中发送 URL 是迄今为止最薄弱的链接。 之后是对令牌进行暴力攻击的风险，令牌（缺乏真正的身份验证机制的结构）可能比结构良好的用户名和密码设置更容易受到攻击。
顺便说一句，https 请求中的参数根本没有问题。
I really wouldn't that consider that secure enough for a situation where there are serious privacy issues. The fact that you're sending the URL in a (presumably cleartext) email is by far the weakest link. After that is the risk of brute force attacks on the tokens, which (lacking the structure of a real authentication mechanism) are likely to be more vulnerable than a well-constructed username and password setup.
There are no issues at all with the parameters in a https request, incidentally.
事实上，这将是一个坏主意。 您将通过简单的使用来牺牲安全性。 如前所述，SSL 只会保护服务器和客户端浏览器之间的信息传输，并且只会防止中间人攻击。 电子邮件风险很大且不安全。
最好是通过用户名和密码身份验证来访问信息。
我或多或少喜欢饼干的想法。 您还应该对 cookie 信息进行加密。
您还应该生成带有盐和关键短语的令牌以及 $_SERVER['HTTP_USER_AGENT'] 以限制攻击的可能性。 在 cookie 中存储尽可能多的有关客户端的非敏感信息以供验证使用。
关键短语可以存储在 cookie 中以便于使用，但请记住 cookie 也可能被窃取 =(。
最好让客户输入他提供的关键短语，该短语也与他的数据一起存储在数据库中。
或者，如果该人使用 $_SERVER['HTTP_USER_AGENT'] 参数不同或只是错过 cookie，则可以使用该密钥，因此
还可以确保敏感数据已加密 。你永远不知道数据库。
As it is, it would be a bad idea. You will scarify security with easy usage. As said before SSL will only protect the transfer of information between the server and client browser and will only prevent the middle man attack. Emails are very risky and insecure.
The best would be a User name and password authentication to access the information.
I like the cookie idea more or less. You should encrypt the cookie information as well.
You should also generate the token with salt and key phrase plus the $_SERVER['HTTP_USER_AGENT'] to limit the probability of an attack. Store as much nonsensitive information about the client in the cookie for verification usage.
The key phrase could be stored in the cookie for easy usage but keep in mind that also cookie can be stolen =(.
Better let the client type the key phrase that he provided, which is also stored in the database along with his data.
Or, the key can be used in case the person uses a different machine which differs in the $_SERVER['HTTP_USER_AGENT'] parameters or simply misses the cookie. So the cookie can be transfered or set.
Also make sure that sensitive data is encrypted in the database. You never know ;)
根据我对你的想法的理解，理论上有人可以输入随机的 40 个字符的字符串或 MD5 哈希值并获取其他人的详细信息。 虽然这种情况不太可能发生，但它只需要发生一次。
更好的解决方案可能是向用户发送一个令牌，然后要求他们输入一些详细信息，例如他们的姓名、邮政编码、ssn 或这些的组合。
From what I understand of your idea, in theory someone could type in a random 40 character string or MD5 hash and get someone elses details. Whilst this may be highly unlikely it only needs to happen once.
A better soloution might be to send the user a token then ask them to enter some of the details, such as their name, post code, ssn or a combination of these.