security - 小书签安全注意事项、CSRF、散列 key

Question

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

现在我想为我的网站启用 CSRF 保护，并且由于小书签基本上是非伪造的跨站点请求，因此我考虑如何将其与伪造的请求区分开来。
这不是一个高安全性的环境，但我对原理也很感兴趣。

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

原始想法

• 生成包含在小书签链接中的随 secret 钥。 key 的哈希值保存在数据库中。随 secret 钥仅允许访问插入此集合的权限，不能在其他任何地方使用。
• 小书签从我的服务器加载更长的脚本，因此我可以通过这种方式提供 CSRF 预防 token
• 要求用户登录

问题

• 如果我有小书签 key ，我是否需要反 CSRF token ？
• 如果用户在恶意网站上点击了他的小书签，有什么方法可以保护小书签 key 吗？
• 我不希望将用户名和密码存储在书签链接中，因为任何有权访问计算机的人都会获得密码，因此我决定使用随 secret 钥。
  • 但是如果我只存储哈希值，我就无法两次生成相同的小书签链接，因此当用户想要在另一浏览器/计算机中使用小书签时，他必须繁琐地从旧浏览器/计算机中导入链接或中断对旧浏览器/计算机的支持.
  • 但我不应该存储明文 key ，因为获得数据库访问权限的人可以使用此 key 将行插入不属于他的帐户中。
  • 可能的解决方案我可以要求用户在创建小书签时提供密码，并多次对密码进行哈希处理，然后将该哈希值放入 URL 中，然后将哈希值放入我的数据库的哈希值。但当然这会带来更严重的安全漏洞。
    • 我可以用“母亲的婚前姓名”之类的内容来代替
    • 由于随机盐，我无法使用 bcrypt 进行散列，对吧？什么哈希函数是正确的？或者你会否决整个想法？
• 如果我保留小书签 key ，恶意网站就可以简单地嵌入小书签并从中提取有效的 CSRF token ，对吗？

更好的想法？或者没有 F 就不能实现企业社会责任吗？

<小时/>

编辑，指定用例

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

我没有指定我的用例，所以是的，iframe 是上述问题的有效解决方案问题。

然而，实际上我的小书签目前确实在运行时与网站进行了一些基本交互(这意味着表单已经存在，用户可以在网站 DOM 中更改他的选择，这应该更改表单)。我准备在我的用例中放弃此功能，如果事实证明，没有相当安全的方法来区分伪造和非伪造的跨站点请求 - 但我仍然对理论层面感兴趣。

Answer 1

如果不消除伪造部分，就无法发出跨站点请求。但对于您的用例，我认为您不需要跨站点请求。

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

这就是我要解决这个问题的方法 -

1. 在您的域上创建一个具有标准 HTML 表单并具有常规 CSRF 保护的页面。该页面接受参数 {url, pagetitle}，但仅当用户明确单击“保存”按钮时才会保存此元组。
2. 小书签的工作是加载 iframe
3. iframe 加载后，即为正常的同源请求

这或多或少是 Google 阅读器作为其书签的一部分所做的事情。这是其书签的代码 - 请注意它没有任何 token

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 方法的交互。小书签在网站上下文中执行，因此它可以访问 DOM。您可以按照自己的意愿与网站进行交互。当您准备好保存时，打开 Iframe。 iframe 将是一种只有一个保存按钮的确认屏幕。

诀窍是延迟 iframe 的创建。仅当用户准备好保存时才创建 iframe。