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

Question

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

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

我以为我有办法做到这一点,但后来意识到它有很多问题.

创见

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

问题

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

好主意？或者你没有F而没有CSR吗？

---

编辑,指定用例

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

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

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

Answer 1

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

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

以下是我要解决的问题 -

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

这或多或少是谷歌读者作为其书签的一部分.这是它的书签的代码 - 注意它没有任何标记

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.