0

因此，您不仅可以随意回答这个问题，还可以提出建议或改进。我以前从未组装过大型 Web 应用程序。这是我的思考过程：

  • 持久层：标准数据库（现在是 MySQL）
  • 业务逻辑层：类 REST 结构（PHP、Java Servlets 等...）
  • 表示层：Web 浏览器、Android 设备（应用程序而非浏览器）等

我选择这种架构的原因是，设备可以设计自己的自定义 UI，并通过使用 GET、POST 以及不与服务器交互的内容来利用类似 REST 的功能。

问题1：

问题是，您如何保护用户的信息？您可以通过 SSL 连接对用户进行身份验证并返回一个特殊的 HASH，以便用户可以操纵他们的帐户，但如果有人在网络上监听，他们所要做的就是监听 REST 调用并窃取 HASH。一种解决方案是所有类似 REST 的调用都必须通过 SSL，但这会导致另一个问题。

问题2：

如果 REST 程序在 SSL 中，则浏览器必须对所有内容使用 SSL，据我了解，这在不必要时可能会很慢而且很麻烦。此外，SOP 使得无法从不安全的浏览器对 REST 过程使用 SSL ajax 调用。HTTP 和 HTTPS 被认为是不同的来源，即使它的来源相同，协议不同。

这个解决方案可行吗？我将如何解决这两个问题？或者可能（可能）我应该为我的 Web 应用程序寻找更好的架构。提前感谢所有建议。

4

2 回答 2

0

如果你想保护你必须使用 SSL的信息，因为任何人都可以监听网络，并查看用户信息。如果要保护访问，请使用 HTTP 身份验证RFC2617。在 SSL 上，Basic 足够安全，但如果您不想对每个请求都使用 SSL，那么 Digest 是要走的路：

  • 您的应用程序可以是无状态的：即更安静，更容易负载平衡，...
  • 如果监听（没有会话劫持），认证令牌几乎不能被重用
  • 几乎每个 HTTP 客户端（浏览器或库）都可以使用基本或摘要 HTTP 身份验证。
于 2011-03-28T05:15:55.780 回答
0

事实证明，这个答案实际上没有很好的解决方案。您可以使用 SSL 保护所有内容，也可以设计自己的自制认证系统。一种常见的方法是向用户发送一个唯一的 HASH，将 HASH 存储在数据库和客户端机器上的 cookie 中。然后只有该用户的 IP、User-Agent 等将通过该 cookie 的身份验证。

所以答案是肯定的，解决方案是可行的。需要维护额外的安全预防措施，以防止帐户劫持。用于登录的 SSL 将保护密码。唯一的哈希将允许用户继续进行身份验证，而无需将密码泄露给帐户。存储大量有关用户的信息，例如 IP、浏览器代理等...将不允许轻易劫持帐户。

于 2011-04-02T21:01:13.397 回答