在浏览器中破解JavaScript有多容易？

我的问题与JavaScript安全性有关。

假设您使用的是Backbone或AngularJS之类的JavaScript框架的身份验证系统，并且您需要安全的端点。没问题，因为服务器始终是硬道理，并会检查您是否有权执行所需的操作。

但是，如果在不涉及服务器的情况下需要一点安全性怎么办？那可能吗？

例如，假设您有一个客户端路由系统，并且希望为登录用户保护一条具体的路由。因此，您对服务器执行ping操作，询问是否允许访问受保护的路由，然后继续。问题是，当您对服务器执行ping操作时，会将响应存储在一个变量中，因此，下次访问私有路由时，它将检查您是否已登录（不对服务器执行ping操作），并取决于响应会成功与否。

用户修改该变量并获得访问权限有多容易？

我的安全（和JavaScript）知识不是很好。但是，如果变量不在全局范围内并且在模块模式的私有部分中，该模式仅具有getter而没有setter，即使在这种情况下，您能否破解呢？

在阅读此答案之前，请先阅读Joachim的答案。他介绍了客户端漏洞背后的一般原因。现在，对于如何解决此问题的建议...

一种用于客户端-服务器通信的安全方案，而无需在每个请求上手动向服务器进行身份验证：

您仍然让服务器拥有最后发言权，服务器仍然必须验证客户端说的所有内容，但这是透明发生的。

假定使用HTTPS协议来防止中间人攻击（MITMA）。

• 客户端第一次与服务器握手，服务器使用非对称加密方案为客户端生成一个公共密钥，并保留一个私有密钥。客户端将服务器的“公钥”存储在本地存储中，并使用您不会在任何地方保存的安全密码进行加密。

• 客户端现在离线。客户端要执行受信任的操作。客户端输入他的密码并获取服务器的公共密钥。

• 基于其数据的知识，现在客户端进行操作，并在客户端加密每次与服务器的公钥进行操作的客户端。

• 当客户端在线时，客户端发送其客户端ID，并将客户端执行的所有操作发送到使用服务器的公钥加密的服务器。

• 服务器对动作进行解密，如果动作格式正确，它会相信动作起源于客户端。

注意：

• 您不能将客户端的密码存储在任何地方，否则攻击者将能够获取密钥并对其进行签名。该方案的安全性完全取决于服务器为客户端生成的密钥的完整性。要求密钥时，客户端仍需要通过服务器进行身份验证。

• 实际上，您仍然依靠服务器而不是客户端来确保安全性。客户端执行的每个操作都必须在服务器上进行验证。

• 可以在Web Worker中运行外部脚本。请记住，您现在拥有的每个 JSONP请求都是一个更大的安全问题。您需要不惜一切代价保护密钥。一旦丢失，攻击者就可以冒充用户。

• 这可以满足您执行“不对服务器执行ping操作”的要求。如果攻击者不知道密钥，就不能简单地使用伪造数据模仿HTTP请求。

• 约阿希姆的答案仍然是正确的。实际上，您仍然在服务器上执行所有身份验证。您在这里保存的唯一一件事是每次都需要使用服务器进行密码验证。现在，当您要提交或提取更新的数据时，只需要涉及服务器即可。我们在这里所做的只是在客户端保存一个受信任的密钥，然后让客户端重新验证它。

• 对于单页应用程序（例如，使用AngularJS），这是一种非常常见的方案。

• 我将服务器的公钥称为“ public”，因为在RSA之类的方案中这意味着什么，但实际上，它是方案中的敏感信息，应加以保护。

• 我不会将密码保留在内存中的任何位置。每当用户开始运行脱机代码时，我都会让用户提交“脱机”密码。

• 不要使用自己的加密技术 -使用Stanford's等已知库进行身份验证。

• 按原样接受此建议。在实际业务关键型应用程序中进行这种身份验证之前，请咨询安全专家。这是一个既痛苦又容易出错的严重问题。

这是至关重要的，没有其他的脚本访问该页面。这意味着您只允许Web Worker使用外部脚本。您不能相信用户输入密码时可能会截获密码的任何其他外部脚本。

如果不能完全确定并且不延迟其执行，请使用prompt而不是内联密码字段（也就是说，不应将其保留到事件只能访问同步代码才能访问事件的地步）。并且实际上不要将密码存储在变量中-再次，这仅在您相信用户的计算机没有受到损害时才有效（尽管对于服务器验证也是如此）。

我想再次补充一点，我们仍然不信任客户。您不能单单信任客户，我想Joachim的答案就是如此。我们仅获得了不必在开始工作之前对服务器进行ping操作的便利。

相关资料：

• 证书与用户名+密码。
• 为什么我们不能通过客户端进行安全保护？
• 不要推出自己的加密货币。
• 有关使JS安全进行加密操作的相关讨论

这很简单：当攻击者控制客户端时，任何依赖于客户端仅执行您要求的操作的安全机制都会受到损害。

您可以对客户端进行安全检查，但只能有效地充当“缓存”（如果客户端已经知道答案将为“否”，则避免进行昂贵的服务器往返））

如果要保留一组用户的信息，请确保这些用户的客户端永远不会获得该信息。如果将“秘密数据”与说明“一起发送，但请不要显示”，则禁用检查该请求的代码将变得很简单。

如您所见，此答案并未真正提及任何JavaScript /浏览器细节。这是因为无论您的客户是什么，这个概念都是相同的。不管是胖客户端（传统客户端/服务器应用程序），老式Web应用程序，还是具有大量客户端JavaScript的单页应用程序，都没有关系。

数据离开服务器后，您必须假定攻击者拥有对该服务器的完全访问权限。

游戏界有句谚语：“ 客户在敌人的手中“。在服务器等安全区域之外运行的任何代码都是易受攻击的。在最基本的情况下，易受攻击而无法首先运行。由客户决定实际运行您的“安全代码”，并且用户可能使用本机代码时，由于攻击者需要是一个很好的程序员来操纵它，因此您至少具有对组件的自动混淆和附加的保护层，而JS通常不会混淆并且是纯文本格式。进行攻击所需的只是诸如代理服务器和文本编辑器之类的原始工具，攻击者仍然需要一定程度的编程知识，但是使用任何文本编辑器修改脚本比将代码注入可执行文件更容易。

这不是黑客JavaScript的问题。如果我想攻击您的应用程序，我将使用一个私有代理，该代理将允许我捕获，修改和重播流量。您提议的安全方案似乎没有针对此的任何保护措施。

专门讲一下Angular：

保护路由客户端根本不存在。即使您“隐藏”该路线的按钮，用户始终可以输入该按钮，Angular也会抱怨，但是客户端可以对此进行编码。

在某个时候，您的控制器将不得不向您的服务器询问呈现视图所需的数据，如果用户无权访问该数据，则您将不会收到该数据，因为您已在服务器端保护了该数据，并且您的Angular应用应该可以正确处理401。

如果要保护原始数据，则不能在客户端，如果只希望特定用户只能以某种方式查看公共数据，请在服务器上创建数据“视图”而不是发送原始数据发送给客户端并对其进行重组（无论如何，出于性能原因，您应该已经这样做了）。

旁注：切勿在Angular请求的视图模板中内置任何敏感内容，只是不要这样做。如果出于某种疯狂的原因，则需要在服务器端保护这些视图模板，就像在进行服务器端渲染时一样。