精选 Flexport 在 HackerOne 这一年 6 个有趣的安全漏洞
精选 Flexport 在 HackerOne 这一年 6 个有趣的安全漏洞
截至2017/6/27 HackerOne的统计
1
删除按钮中的XSS漏洞
当发起赏金计划时，我们没想到会收到有关 XSS 的有效报告，毕竟 React 中内置了防范这种漏洞的保护措施，不幸的是，我们收到的第一份不同寻常的报告就是关于存储型 XSS 漏洞的。
原因：
当时我们在使用 Bootbox 来显示错误消息并创建确认对话框。 Bootbox 独立于 React 管理 DOM 元素，因此不受 React 的 XSS 保护措施的影响。 所以，当将用户输入直接展示在确认对话框中时，就触发了攻击。
修复：
短期的修复方案是在用户输入传递给 Bootbox 展示之前，将所有可能和 XSS 相关的标签删除(JSXSS 提供了一个节点模块让这部分变得很简单)。正在筹备长期的解决方案是，从 Bootbox 转移到一个基于 React 的确认模块。
教训：
React 阻止了 XSS 不代表所有代码都是安全的。对所有在 React 之外工作的库都不能信任，并且要尽可能地避免使用它们。
2
Markdown 渲染中的 XSS 漏洞
在修复了 Bootbox 并检查了我们其它类似的库之后，我们收到了第二个 XSS 漏洞报告——这次存在于我们的 Markdown 渲染中。
原因：
我们的文本框中以 <div dangerouslySetInnerHtml={{__html: marked(text)}} /> 方式支持 Markdown，回想起来，这是一个坏主意。
修复：
将所有传递到 dangerouslySetInnerHtml 的文本都使用 XSS 过滤器，并创建一个 Lint 规则以在将来执行此操作。
教训：
使用任何带有 dangerous 的功能时，都要严肃对待……
3
Target=“_blank”
在所有从 HackerOne 中收到的报告中，最令人惊讶的是标准 HTML 标签的正常使用。
原因：
当你用新标签页打开一个链接（ <a target="_blank"> ），新打开的标签页可以利用 window.opener 属性访问初始标签并改变它的 location 对象。攻击者可以将原始页面设置为登录页面或其他任何内容。只能将 rel="noopener noreferrer" 添加到 a 标签中，来减轻这一类问题。
修复：
通过在使用 target="_blank" 时增加 rel="nofollow me noopener noreferrer" ，我们修复了该问题，这样新窗口就不能改变原始窗口的内容。另外，我们 向 ESLint 提交了一个 Lint 规则，防止以后大家犯同样的错误。
教训：
这个漏洞的关键点是，安全是很难的。我们很容易信任像 HTML 这样的准则，但保持警惕和怀疑同样重要。
4
Wordpress 的困境
修复完上述漏洞，我们没有收到更多与前端相关的漏洞，然而我们在 HackerOne 的赏金计划仍然在博客中延续。我们公司的博客在 Wordpress 上运行，也因此收到了各种各样基于此的漏洞报告。
原因：
每个博客漏洞都归结于同样的问题：过时的库很容易受攻击。 例如，JetPack 是一种广泛使用（300万次安装）和推荐的插件，它承诺“保护所有 WordPress 网站的安全，增加流量，吸引读者”，但在过去几年中已经有许多 XSS 和其他漏洞。
来源：https://wpvulndb.com
修复：
和所有软件一样，最不容易受攻击的是不存在的代码，其次是最新的代码。 我们删除了绝大多数的 Wordpress 插件（其中大部分都不知道何时安装过），更新了其余部分插件，并订阅 https://wpvulndb.com/ 以得到最新的报告。
5
暴力破解 2FA
转到我们的 Ruby on Rails 后端，我们收到了两份值得注意的报告，都涉及了我们的双重认证。一开始，我们收到一份报告，展示了如何通过暴力攻击来获得已泄露用户的访问权限。
原因：
我们使用 Authy 作为我们的 2FA 合作伙伴，他们的 rails gem 不包括任何内置的速率限制。
修复：
修复方法很简单：我们添加了速率限制，即在多次错误尝试后锁定账户。
6
绕过 2FA
最后，我们收到了一份报告，展示了对我们 2FA 的完全绕过，这使得第二重认证完全没有起作用。攻击者所要做的就是忽略 2FA 页面并导航到另一个链接。
原因：
在本文中所有的 bug 中，这一个是最难找到的。Authy rails gem hook 住 Devise (一个受欢迎的 rails 认证/用户管理库)，并在登录后使用以下代码要求 2FA:
def check_request_and_redirect_to_verify_token ... id = warden.session(resource_name)[:id] warden.logout warden.reset_session! session["#{resource_name}_id"] = id ... redirect_to verify_authy_path_for(resource_name) end
理论上说，这个代码在用户成功登录后会将其登出，并重新定向到第二重身份验证页面。 然而实际上，Devise 调用 authenticate? 检查用户是否进行了身份验证（在此处的代码之后运行）：
def authenticate?(*args) result = !!authenticate(*args) # Try to log the user in yield if result && block_given? result end
这会让用户重新登录。
修复：
将 warden.logout 行更改为 sign_out 可以解决这个问题，因为 sign_out 有其他代码来清除登录。 我们在本地解决了这个问题，并向 Authy 提出了一项请求，以便能帮助大家解决问题。
教训：
连信誉良好的安全公司有时也会出错，并且渗透测试也没有好的替代品。 对我们来说，最经济有效的方法仍然是 HackerOne。 我们发现这些报告对 Flexport 和我们的安全都具有很高的价值。
往 期 热 门
腾讯云开发者
