Bookmarklet安全性考虑因素CSRF是关键所在

Question

我的书签可以从任何网站调用，基本上允许用户从远处插入一行 - 如果他已登录。

现在我想为我的网站启用CSRF保护，因为书签基本上是非伪造的跨网站请求，我想到了我如何区别于伪造的。） 这不是一个高安全性的环境，但我也对原则感兴趣。

我以为我有办法解决这个问题，但后来意识到它有很多问题。

最初的想法

• 生成包含在bookmarklet-link中的随机密钥。密钥的哈希值保存在数据库中。随机密钥只允许访问插入此集合的权限，不能在其他任何地方使用。
• bookmarklet从我的服务器加载一个更长的脚本，所以我可以这样提供一个CSRF预防令牌
• 要求用户登录

问题

• 如果我有书签键，我是否需要反CSRF令牌？
• 如果用户在恶意网站上点击他的书签，我有什么方法可以保护书签键吗？
• 我不希望用户名和密码存储在bookmarklet链接中，因为任何有权访问计算机的人都会获得密码，所以我决定使用随机密钥。
  • 但是如果我只存储哈希，我就无法生成相同的书签链接两次，所以当用户想要在另一个浏览器/计算机中使用书签时，他繁琐地必须从旧的链接导入链接或者断开对旧的链接的支持
  • 但我不应该存储明文密钥，因为有权访问数据库的人可以使用此密钥将行插入不属于他的帐户中。
  • 可能的解决方案我可以要求用户在创建书签时随时提供密码并将密码哈希多次次并将该哈希值放入网址并放入哈希值那个哈希我的数据库。但当然这会打开更糟糕的安全漏洞。
    • 我可以用“母亲的娘家姓”代替
    这样做
    • 由于随机盐，我无法使用bcrypt进行散列，对吧？什么哈希函数是正确的？或者你会忽略整个想法吗？
• 如果我将书签密钥丢失，恶意网站可以简单地嵌入书签并从中提取有效的CSRF令牌，对吗？

更好的想法？或者你不能没有F？

的CSR

---

编辑，指定用例

我根本没想到的一件事是Sripathi Krishnan建议使用iframe。

我没有指定我的用例，所以是的，iframe是前面提到的有效解决方案 问题

然而，实际上我的书签目前确实在运行时与网站进行了一些基本的交互（意味着表格已经存在，用户可以在网站DOM中更改他的选择，这应该改变表格）。我已经准备好为我的用例忽略这个功能，如果事实证明，没有合理安全的方式来区分伪造的非伪造跨站点请求 - 但我仍然对理论水平感兴趣。

Answer 1

在不删除伪造部分的情况下，您无法进行跨站点请求。但对于您的用例，我认为您不需要跨站点请求。

让我们假设您的服务允许用户为他希望的任何页面添加书签。 bookmarklet的工作是将{url，title}保存到数据库中。同时，您希望防止恶意网站自动为已登录的用户保存网址。

以下是我要解决的问题 -

1. 在您的域上创建一个具有常规CSRF保护的标准html表单的页面。此页面包含参数{url，pagetitle}，但仅在用户明确单击“保存”按钮时保存此元组。
2. bookmarklet的工作是加载iframe
3. 一旦iframe加载，它就是一个正常的同源请求

这或多或少是Google阅读器作为其书签的一部分。这是它的书签的代码 - 注意它没有任何标记

javascript:
var b=document.body;
var GR________bookmarklet_domain='http://www.google.com';
if(b&&!document.xmlVersion) {
  void(z=document.createElement('script'));
  void(z.src='http://www.google.com/reader/ui/link-bookmarklet.js');
  void(b.appendChild(z));
 }
 else{}

编辑： 您仍然可以支持与iframe方法的互动。 bookmarklet在网站的上下文中执行，因此它可以访问DOM。您可以随意与网站进行互动。准备好保存后，打开Iframe。 iframe将是一个只有一个保存按钮的排序确认屏幕。

诀窍是延迟iframe的创建。您只能在用户准备保存时创建iframe。

Answer 2

如果小书签存储在Web浏览器中，那么包含在数据库中散列的秘密密钥的想法是个好主意。这将阻止CSRF，虽然它并不理想，因为从某种意义上说，这是一个不会超时的会话ID。应该清楚的是，此令牌仅用于此bookmarklet操作。尽管有此限制，您不太可能遇到攻击。添加HTTPS会使其更强大，因为它更难以溢出此令牌。

如果小书签来自第三方网站，那么您无能为力。这是CSRF的定义。