Https URL 带令牌参数: 安全性如何？

在我们的网站上，我们根据用户的私人信息(通过表单给出)为用户提供一个模拟。我们希望允许他们稍后返回他们的模拟结果，但不强制他们创建登录/密码帐户。

我们已经考虑给他们发送一封带有链接的电子邮件，从中他们可以得到他们的结果。但是，自然地，我们必须保护这个 URL，因为私人数据处于危险之中。

因此，我们打算在 URL 中传递一个令牌(比如40个字符的字母和数字组合，或 MD5散列)并使用 SSL。

最后，他们会收到这样一封电子邮件:

嗨,
结果出来了 Https://www.example.com/load_simulation?token=uzvtlbcwcw33rihvnbxtkxtxm2rkj7yjrwyuxhxn

你觉得怎么样？安全吗？对于象征性的一代，你有什么建议？在 https 请求中传递 URL 参数怎么样？

110992 次浏览
小开

E-mail is inherently insecure. If anyone can click on that link and get to the data, you're not really protecting it.

小开

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.

小开

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.

小开

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.

小开

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.

小开

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 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.

小开

I'd use a cookie for that. The workflow should be like this:

  1. User comes to your site for the first time.
  2. Site sets a cookie
  3. User enters data. Data is stored in the DB using some key that is stored in the cookie.
  4. When user leaves, you send them an email with a https: link
  5. When user comes back, site discovers the cookie and can present the user with the old data.

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.

小开

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 ;)


提交答案