【问题标题】:Client side javascript driven websites [closed]客户端javascript驱动的网站[关闭]
【发布时间】:2011-08-29 03:54:39
【问题描述】:

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

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

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

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

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

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

【问题讨论】:

  • 我希望我可以对这个问题两次投票。我对从客户端代码直接访问 CouchDB 的最佳实践特别感兴趣。
  • 这是安全与风险管理,如果你能付出代价,你就可以掷骰子。除此之外,您能否更准确地了解您迄今为止在此问题上调查或阅读的内容?这些东西可能非常先进,也许是下一代应用程序的方式;)在移动系统上,所有代码都在客户端上运行。那么为什么不在浏览器中呢?
  • @David 你看过couchapp吗?
  • @Pavel Veller:不,但请放心,它现在在我的队列中。谢谢!
  • 更新了我的答案,希望对您或其他人有所帮助。无论如何,我都赞成这个问题,以便在这里获得更多答案:)

标签: javascript security client-side database-driven


【解决方案1】:

首先,在客户端上运行代码以直接访问数据库听起来很麻烦;这似乎与 information hiding 的理念背道而驰,后者在设计更复杂的系统中非常有用。

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

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

但是,您可以在您的数据库中定义一个admin 角色和一个user 角色,为您的user 角色定义GRANT SELECT 权限,为您的@987654330 定义GRANT SELECT, UPDATE, INSERT 权限@角色。

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 用户从其他任何地方登录,因此您可以将 UPDATEINSERT 限制为特定的IP。

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

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

【讨论】:

    【解决方案2】:

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

    花哨的动画、AJAX、验证、计算,通常只是为了方便,考虑到有时使用客户端处理器而不是服务器处理器更好。当然,自 56k 互联网连接以来,每个人都希望实现“更快”这一事实。

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

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

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

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

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

    更新

    博客示例

    做你想做的事的三个真正要求。

    1. 身份验证(后端):这将是访问数据库、擦除 cmets 等所必需的。
    2. 验证和清理(后端):限制字符数量、转义恶意代码、禁止字词。
    3. 敏感数据处理(后端):使用哈希来获取密码...

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

    通常:如果你的后端失败,你的前端就会失败。反之亦然。 XSS 可以对 JavaScript 规则的网站(例如 Facebook)造成大量破坏。

    【讨论】:

      【解决方案3】:

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

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

      【讨论】:

      • 可以从客户端与数据库通信,即 sqlite3 或使用 html5 的本地存储。
      • It is not possible to talk to the database from the client-side. - 在某些情况下可能不推荐,但根据具体情况肯定是可能的并且非常有用。
      • @David,所以你不认为 sqlite3 是一个数据库?您听说过本地存储吗?
      • 问题中暗示了服务器端数据库似乎很明显。
      • @AntonioP:你从哪里推断出来的?我向@jriggs 指出,客户端数据库通信确实是可能的,无论是客户端数据库本身还是服务器端数据库(例如原始问题中的 CouchDB)。
      猜你喜欢
      • 2016-11-01
      • 1970-01-01
      • 1970-01-01
      • 2012-08-05
      • 1970-01-01
      • 2014-01-08
      • 1970-01-01
      • 2018-03-02
      • 2011-04-16
      相关资源
      最近更新 更多