通过SSL传递GET变量=安全吗？

Question

我有一个移动应用程序（iOS），它使用URL中的GET变量发送服务器请求。

现在所有请求都是SSL安全的，这意味着我们只对所有请求使用HTTPS。

现在它不在浏览器中，因此没有历史记录，也没有人真正看到URL，我们禁止对服务器上的服务器日志的所有访问权限（这两个事实与所有其他类似问题不同）。

话虽如此，假设传递的GET变量是安全的并且不能被“中间人”攻击攻击是否安全？

Answer 1

严格来说，“中间人”攻击仍然可以执行。最大的问题是它是否对最终用户透明。

中间的一个人仍然可以劫持最初的SSL握手并返回自己的SSL证书。证书可以是正确的域名等，但区别特征是它（希望）不会被可信任的源（即证书颁发机构（CA））签名。如果您的应用程序识别出这种情况并停止通信，那么您就可以了。另一方面，如果您的应用程序没有检查受信任的CA的真实性，那么您将与黑客协商会话，然后黑客可以查看您的流量，检查它，然后将其发送到真实服务器进行处理。来自真实服务器的所有响应也将对黑客可见。

如果黑客能够以某种方式使用受信任的CA密钥签署其欺诈性证书，则无法阻止他们。这种情况很少见，但CA可能会受到损害。

对于网络浏览器，此类攻击会向用户显示“停止，正在发生的事情”消息，这在以后的浏览器版本中变得更加明显。尽管如此，最终用户可以继续前进并接受不可信证书，从而有效地允许黑客窃听。如果您的应用程序（或iOS本身）允许这样做，那么除了尽可能地教育用户之外，您几乎无能为力。

总之，如果您的应用程序与目标服务器协商SSL通道并确保返回的证书由受信任的机构签名（并且不询问用户），那么您应该没问题。所有HTTP流量（包括之后的GET / POST动词和标题）都将被加密。还有两个警告词是有道理的。

• 这就是为什么设备（在这种情况下为iOS）必须非常小心地保护其受信任的权限文件（“root CAs”）
• 您需要使用安全密码进行底层通信。对于非关键数据（即非个人信息），RC4可能很好并且可能更快。对于任何个人（即银行业），尽你所能。如果它不是默认值，我建议使用AES-256。

Answer 2

SSL为您的请求提供加密通道，但是一旦请求到达目的地，您就会知道访问日志会记录纯文本变量。

如果您发送的信息是敏感的，那么您应该使用POST。这将防止Web服务器记录变量。它还会阻止您的安全请求从其他域（相同的原始策略）调用（如果那是您关注的内容）

Answer 3

不要忘记您的请求可能会通过代理，也会记录消息。