我正在开发一个利用面向服务架构的新网站，前端使用纯JavaScript，通过RESTful AJAX调用访问数据的Web服务。
它应该不是特别重要，但我的堆栈是：
来自this article一旦我在客户端（JavaScript）和服务器（通过Web API的REST服务）之间共享私钥，我就找到了保护我的Web服务调用的一些好方法。但是，我正在努力建立如何建立用于加密的私钥。
糟糕的想法＃1
最初的做法是将其设置为通过HTTPS进行的登录，然后将其存储在cookie中的客户端上以供重用。问题是我们的SSL证书适用于https://secure.example.com，而我们的网站位于http://www.example.com - 因此我无法从www.example.com访问secure.example.com Cookie。< / p>
糟糕的想法＃2
我的下一个想法是将其加密并通过URL登录从HTTPS登录到HTTP登录后页面进行签名，如下所示：
http://www.example.com/processLogin?key=[encryptedKey]&sig=[encryptedSig]&user=[userid]
encryptedKey和encryptedSig都将使用仅为该事务存在的另一个私钥加密。它将在登录时创建并分配给数据库中的该用户。在HTTP端，所有这些都被传递到解密它的服务器，验证签名，删除该私钥（以防止重放攻击 - 基本上是nonce）并返回解密的私钥（{{1解密）。
从那时起，[encryptedKey]的解密值将用于所有未来的交易。问题是解密的私钥必须通过HTTP发送到线路上，这很糟糕。
糟糕的想法＃3
我还简要地想到在JavaScript中有一个用于解密此值的硬编码密钥，但无论我如何尝试和混淆它，它都可以被黑客找到并使用。
糟糕的主意＃4
我在最初的握手时也考虑过使用公钥加密的某种key exchange，但正如elsewhere所述，你不能真正对客户端有信心在这次初始握手期间不要篡改，除非它是通过SSL - 让我回到原点。
重大问题
那么，如果没有一切通过HTTPS，你们如何管理这些事情呢？我 是否具有相同的HTTP和HTTPS域名，以便我可以将此私钥存储在Cookie中？
请注意，网站的非SSL部分不会共享信用卡或登录信息等。我只是不想让这个傻瓜大开。
答案 0 :(得分：2)
如果不实施SSL，您无法在javascript客户端和服务器之间进行安全和加密的通信。是不可能的。如果您真正想要实现的不是加密流量，而只是保证您正在与之交谈的客户端已经被授权提出请求而客户端不是模仿者，那么OAuth就足够了。有关标准OAuth .net实施，请参阅http://www.dotnetopenauth.net/。
如果OAuth不是您想要参与的内容，并且您只想构建已构建的内容，则应将令牌以及公钥和私钥分发到javascript客户端。公钥和令牌是针对每个请求来回发送的，而私钥永远不会来回发送，而是用于生成某种类型的签名哈希。每个请求都应该有此签名和基于时间的nonce以防止重放。您还应该经常使令牌过期，并要求客户端使用其签名和公钥请求“刷新”令牌。从本质上讲，我所描述的是OAuth 1.0a，如果你确实想要采用这条路线，我会回顾DotNet OpenAuth，而不是试图自己动手。
但是，重申一点，如果没有SSL，您仍然可能容易受到其他类型的攻击。此外，除非您对SSL加密初始令牌请求，否则黑客总是会嗅到令牌/公钥/私钥对的初始传递，因此，首先要消除您为确保事情安全所做的所有努力。
上述方法的替代方法是在客户端和REST API之间安装代理服务器。对API的请求只能通过代理服务器。客户端使用基本身份验证登录并从https://secure.example.com获取cookie。然后，客户端继续向secure.example.com发出请求，然后secure.example.com向您的API发出请求并将数据返回给客户端。
无论如何，希望有足够的信息让你有所思考。
答案 1 :(得分：1)
您可以通过查看以下答案来查看如何使用子域和Cookie：Creating a javascript cookie on a domain and reading it across sub domains
答案 2 :(得分：0)
关于糟糕的想法＃3：
我已经知道有一段时间我可以使用http://jsbeautifier.org使用http://dean.edwards.name/packer/使用“收缩变量”复选框＆amp; /或“Base62编码”复选框对任何混淆的内容进行反混淆处理。所以JavaScript是完全不安全的不应该依赖于保存任何类型的SSL加密，用户身份验证令牌以及浏览器中的可编辑帐户统计信息。否则，有人会尝试编辑他们的游戏帐户＆amp;给自己+10万游戏币。
当一切都通过SSL时，它只能防止“中间人”攻击。它实际上是一个“服务器机器人在中间”的攻击。它不会阻止最终用户自己成为黑客。
在下一个插图中，SSL将阻止服务器a到e看到从客户端传递到终端服务器的任何数据，但没有SSL服务器C会窃取数据。这就是服务器跳跃如何工作，没有加密，客户端+所有服务器都可以读取数据：
client > a > b > server c's bot sniffs http traffic > d > e > terminus server
服务器c的机器人记录了一个信用卡号，这是一个加密的银行帐号。 （大多数人都没有意识到信用卡号码是加密和转换后的银行帐号。如果信用卡号被泄露，银行很容易从银行帐号和放大器重新发出新的加密CC＃ ;通过邮件发送一张新卡。他们不必更改原来的银行帐号，也不必打印新的支票，这些支票的底部印有银行帐号。）
使用TLS / SSL / https加密的服务器跃点可以像这样工作，其中只有客户端＆amp;服务器可以读取任何内容：
client > all servers from a-e are blind & pass the data through > terminus server
服务器c的机器人看到垃圾如：as65a89as7df08而不是1234-5678-9012 -...，如果他们可以使用SSL读取任何内容。
关于iOS的一个很酷的地方是，当它与HTML 5和HTML一起使用时，它更难以阅读JS代码。 CSS。用户无法右键单击以在iPhone上进行检查，就像在桌面浏览器中一样。使用后端语言在终端服务器中隐藏密码很容易。
目前无法阻止JavaScript被最终用户（客户端）攻击。每个最终用户都可以成为黑客。如果我想出其他的东西，我可以在这里发布，供未来的开发人员阅读。