在 JAVA/Tomcat 网站中保护购物车的最佳方法是什么？

发布于 2024-08-03 09:10:00 字数 1078 浏览 2 评论 0原文

我正在寻找有关如何保护其他（相对）不安全网站的“购物车”部分的最佳实践解决方案。

站点中的现有设置使用不安全的 cookie，并且仅（通过 SSL）保护凭证交易。该网站的其余部分是通过 HTTP 访问的，因此数据传输不安全。不过，这对我们来说不是问题。

然而，现在我们正在向网站添加“购物车式”元素，并且我们希望确保结帐过程的安全。到目前为止，我的想法是：

依赖一个安全的 cookie（它将保存一个长随机“Base64 编码”字符串作为值），有效期为 15 分钟。
相同的值（和创建时间戳）将保存在 SESSION 中（当然是在服务器端！）。注意：我说的是常规的、不安全的会话。
只有当用户验证了自己的身份后，cookie 才会发送给用户。如果他已经登录 - 他将必须“重新进行身份验证”（除非他有一个仍然有效的 15 分钟安全 cookie）并再次向我们提供他的密码。
基本上，我想这与常规的 15 分钟长的安全“tomcat 会话”并没有太大不同。此会话中的凭据和数据均通过 HTTPS/SSL 传输。

注意和想法：

为了验证安全 cookie，时间戳和令牌密钥都将存储在服务器上的常规（不安全）会话对象上。但是 - 由于安全令牌仅通过 SSL 传输，因此（理论上）中间人无法拦截它。因此，即使攻击者设法窃取常规会话 ID 并伪造用户身份 - 他仍然需要知道与该用户的（常规会话 ID）关联的特定安全令牌 ）会话，以便访问他的信用卡详细信息。
15 分钟的 cookie 生命周期将在客户端和服务器端强制执行（通过保留创建时间戳）。
Cookie 本身（和安全令牌）不保存任何机密（加密或其他）信息。密钥只是一个长随机字符串。
为了生成令牌，我想到使用 java 的 SecureRandom，并对它生成的随机字节进行 Base64 编码，以便它只包含字母数字、“斜杠”和“加号”字符。我想过使用 512 个随机字节，但如果可以用更少的字节来完成，我会很高兴听到:)

这被认为是一个好的解决方案吗？在这种情况下是否有更好的做法可以应用？有没有什么办法可以进一步提高安全性而又不会“过度”？

提前致谢！汤姆

原文

I am looking for the best-practice solution regarding how to secure a "shopping-cart" part of an otherwise (relatively) unsecure website.

The existing setup in the site uses an unsecure-cookie, and only secures (via SSL) the transaction of credentials. The rest of the site is accessed via HTTP and thus, data is transmitted unsecurely. This is not a problem for us, though.

However, now we are adding a "shopping-cart-esque" element to the site, and we wish to secure the checkout process.
My idea so far was:

To rely on a secure cookie (that would hold a long random "Base64-encoded" string as a value) with a 15 minute expiration.
The same value (and a creation timestamp) would be saved in the SESSION (on the server-side of course!). Note: I'm talking about the regular, unsecure session.
The cookie would only be sent to the user if he authenticated himself. If he is already signed in - he would thus have to "re-authenticate" (unless he has a still-valid 15 minute secure cookie) and give us his password once more.
Basically, I guess this is not too dissimilar from a regular 15 minute long secure "tomcat session". Both the credentials AND the data in this session is transmitted via HTTPS/SSL.

Notes and thoughts:

To validate a secure-cookie, the timestamp and the token-key would both be stored on the regular (unsecure) session object on the server. BUT - Since the secure-token is only transmitted via SSL, there is (in theory) no way for a man-in-the-middle to intercept it. Therefore, even if the attacker manages to steal a regular session ID and forge a user's identity - he would still need to know the specific secure-token associated with this user's (regular) session in order to gain access to his credit card details.
The 15 minute cookie-lifetime would be enforced both in the client-side and on the server side (by keeping the creation-timestamp).
The cookie itself (and the secure token) do not hold any confidential (encrypted or otherwise) information. The key is just a long random string.
To generate the token I thought of using java's SecureRandom, and to Base64-encode the random bytes generated by it, so that it would only contain alpha-numeric, 'slash' and 'plus' characters. I thought of using 512 random bytes, but if it could be done with less I would be happy to hear :)

Is this considered a good solution? Is there a better practice that can be applied in this case? Is there anything that can be done to increase security even further without "over-doing" it?

Thanks in advance! Tom

分享到QQ

分享到微博