5

是否可以使用客户端 javascript 作为关键点来构建动态 Web 应用程序？我不是在谈论服务器端 javascript（如节点），而是在谈论使用 javascript 处理大部分网站：模板、表单处理等。

当然，简短的回答是“是的，有可能”。但我主要关心的是数据库传统上位于服务器上时的数据库数据操作和安全性。理想情况下，客户端 javascript 驱动的应用程序应该几乎直接与数据库对话。我知道 Couchdb 允许这样做，但是如何防止用户提交旨在查看他们不应该看到的数据的查询？考虑到主要验证也应该是客户端并且很容易伪造，如何处理输入验证？

在我看来，这似乎很有趣，但并不真正可行，但也许有我不知道的解决方案，或者围绕一些数据库的微小安全层，或者我忽略的项目等。

我知道 CouchDb 独立应用程序 ( couchapp )，它是一种接近我所追求的技术，但它强制执行一种开放的方法，这使得它不适用于我能想到的所有场景。

欢迎对此主题提出任何建议。

编辑：由于需要示例，请参阅 simples 博客。我想在首页显示最后五个帖子。如果有人以非常简单的方式“入侵”该页面，他们可以检索较旧的帖子。没关系。但是当我想插入新帖子时怎么办？如果 javascript 对数据库具有开放访问权限，那么任何人都可以在我的博客中写帖子——我不想要它。此外，任何人都可以删除我的帖子或其他用户的评论，这是我想要的特权。如果我想避免超过 500 个字符并包含坏词的评论怎么办？同样，作为客户端的验证，用户可以绕过它。

4

3 回答 3

3

首先，在客户端上运行代码直接访问数据库听起来很麻烦；它似乎违背了信息隐藏的理念，这种理念在设计更复杂的系统中非常有用。

所以，我认为这大部分是学术练习。:)

大多数集中式数据库系统本身具有多个用户或角色；通常，我们为每个应用程序使用一个“用户帐户”，并允许应用程序以自己的方式定义用户。（这一直困扰着我，总觉得管理员和用户角色也应该在数据库中分开。但在我看来，我似乎是一个人。:)

但是，您可以在您的数据库中定义一个admin角色和一个角色、您的角色的权限以及您的角色的权限。userGRANT SELECTuserGRANT SELECT, UPDATE, INSERTadmin

PostgreSQL 至少有一个预定义PUBLIC可以代替user; 以下示例从http://www.postgresql.org/docs/9.0/static/sql-grant.html复制：

GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;

文件的正确配置pg_hba.conf可以允许admin用户从特定 IP 登录，并允许用户user从其他任何地方登录，因此您可以限制UPDATE特定INSERTIP。

现在的困难在于用 JavaScript 编写 PostgreSQL 客户端库。:) 老实说，我不知道基于浏览器的 JavaScript 虚拟机是否足够灵活，可以允许与远程主机进行任意套接字通信。（考虑到 WebSockets 是如何被如此热烈地接受的，我猜 JavaScript 非常卡在 HTTP 世界中。）

当然，您必须以某种方式将 HTML 页面提供给 Web 浏览器，这意味着拥有 HTTP 服务器。您不妨要求该服务器位于客户端和数据库之间。您还不如在服务器上执行一些处理任务，以避免向客户端发送冗余/不必要的数据......这正是我们今天的情况。:)

于 2011-05-19T23:31:04.327 回答
2

是的，有可能有一个严重依赖 JavaScript 的 Web 应用程序；然而，大多数时候这一层只是附加的；不是替代品。大多数开发人员认为 JavaScript 只是一个便利层，它使最终用户的交易“更容易”，你可以说这是安全方面的最佳方法。JavaScript 作为一种“权威”工具，将可延展数据清理到受信任的数据库中只是效率不高；除非您想将所有数据视为不安全的，并在每次显示它时对其进行清理，并从 JavaScript 本身处理它。

花哨的动画，AJAX，验证，计算，通常只是为了方便，考虑到有时使用客户端处理器而不是服务器处理器更好。当然，自从 56k 互联网连接以来，让事情变得“更快”一直是每个人都想要实现的目标。

安全方面，没有任何额外保护层可供最终用户使用的安全逻辑简直是疯了。将 JavaScript 视为额外的一手。JavaScript 能读到什么，用户就能读到。您不会在那里存储数据库凭据或密码散列密钥吗？特别是因为 JavaScript 可以在运行时使用调试器进行修改，并且几乎任何混淆代码都可以解决为人类可读的东西。

撇开插入和“安全”数据不谈，如果您的来源是安全的，那么获取公开可用信息应该不会有太多麻烦。

对于 javascript 前端，我推荐Backbone.js，它将为您在组织和交互方面提供坚实的基础：

Backbone 通过提供具有键值绑定和自定义事件的模型、具有可枚举函数的丰富 API 的集合、具有声明性事件处理的视图，并通过 RESTful JSON 接口将其全部连接到现有应用程序，从而为 JavaScript 繁重的应用程序提供结构。

唯一剩下的就是有一个薄层，可以放在您的数据库（甚至数据库本身）之上，以在插入时清理数据并存储/计算在任何情况下都无法暴露的敏感信息客户端。

更新

博客示例

做你想做的3个真正的要求。

  1. 身份验证（后端）：这将需要访问数据库、删除评论等。
  2. 验证和清理（后端）：限制字符数量，转义恶意代码，禁止单词。
  3. 敏感数据处理（后端）：使用哈希来获取密码......

注意：您几乎可以通过在显示时将所有数据视为不安全来绕过“验证和清理”；就像我提到的效率非常低，因为您需要客户端以某种方式对其进行解析以使其安全；而且它仍然很有可能会被绕过。另外两个，真的需要你有一种安全的方式来与你宝贵的数据库进行交互。

通常：如果你的后端失败，你的前端就会失败。反之亦然。XSS 可以对 JavaScript 规则的网站（例如 Facebook）造成严重破坏。

于 2011-05-19T19:37:25.520 回答
-3

无法从客户端与数据库通信。为了安全起见，您必须进行两次验证。一次在客户端，一次在服务器端。

您可以在客户端执行的任何操作都可能被恶意用户伪造。客户端验证主要是为了方便用户。提供数据库安全性的是服务器端验证。

于 2011-05-19T19:34:48.950 回答