我有一个移动应用程序 (iOS)，它使用 URL 中的 GET 变量发送服务器请求。
现在所有请求都是 SSL 安全的，这意味着我们只对所有请求使用 HTTPS。
现在它不在浏览器中，因此没有历史记录，也没有人真正看到 URL，我们禁用对服务器日志的所有访问（这两个事实使这个问题与所有其他类似问题不同）。
话虽如此，假设传递的 GET 变量是安全的并且不能被“中间人”攻击入侵，是否安全？
问问题
2135 次
3 回答
5
严格来说，“中间人”攻击仍然可以执行。最大的问题是它是否对最终用户透明。
中间人仍然可以劫持最初的 SSL 握手并返回自己的 SSL 证书。证书可以用于正确的域名等，但区别在于（希望）它不会由受信任的来源（即证书颁发机构 (CA)）签名。如果您的应用程序识别到这一点并停止通信，那么您就可以了。另一方面，如果您的应用程序没有通过受信任的 CA 检查真实性，那么您将与黑客协商会话，然后黑客可以看到您的流量，对其进行检查，然后将其发送到真实服务器进行处理。来自真实服务器的所有响应也对黑客可见。
如果黑客能够以某种方式使用可信 CA 的密钥签署他们的欺诈证书，那么就无法阻止他们。这种情况很少见，但 CA 可能会受到损害。
在 Web 浏览器的情况下，这样的攻击会向用户显示“停止，发生了一些可疑的事情”消息，这在以后的浏览器版本中变得更加明显。尽管如此，最终用户仍然可以继续前进并接受不受信任的证书，从而有效地允许黑客窃听。如果您的应用程序（或 iOS 本身）允许这样做，那么除了尽可能多地教育用户之外，您几乎无能为力。
总而言之，如果您的应用程序与目标服务器协商 SSL 通道并确保返回的证书由受信任的机构签名（并且不询问用户），那么您应该没问题。所有 HTTP 流量，包括之后的 GET/POST 动词和标头，都将被加密。还有两句警告是有道理的。
- 这就是为什么设备（在这种情况下为 iOS）必须非常小心地保护其受信任的权限文件（“根 CA”）
- 您需要使用安全密码进行底层通信。对于非关键数据（即非个人信息），RC4 可能很好并且可能更快。对于任何个人（即银行业务），尽你所能去。如果不是默认设置，我会推荐 AES-256。
于 2012-12-11T20:52:59.283 回答
1
SSL 为您的请求提供了一个加密通道，但是您知道，一旦请求到达其目的地，您的访问日志将记录纯文本变量。
如果您发送的信息在任何方面都是敏感的，那么您应该使用 POST。这将防止 Web 服务器记录变量。如果这与您有关，它还将阻止从其他域（同源策略）调用您的安全请求
于 2012-12-13T18:01:01.600 回答
0
不要忘记您的请求可能会通过代理，并且这些代理也会记录消息。
于 2012-12-11T20:39:58.993 回答