Web应用安全性: 浏览器是如何工作的
|
例如，Chrome 51 引入了 SameSite cookie，该功能允许 Web 应用程序摆脱称为 CSRF 的特定类型的漏洞（稍后将详细介绍）。其他供应商认为这是一个好主意，并纷纷效仿，导致 SameSite 成为 web 标准:到目前为止，Safari 是唯一没有 SameSite cookie 支持的主流浏览器。 这告诉我们两件事:
第一点是对 Safari 的一次尝试(正如我提到的，开玩笑的!)，而第二点非常重要。在开发web应用程序时，我们不仅需要确保它们在不同的浏览器中看起来是相同的，还需要确保我们的用户在不同的平台上受到相同的保护。 你的网络安全策略应根据浏览器供应商允许我们执行的操作而有所不同。 如今，大多数浏览器都支持相同的功能集，并且很少偏离其常见的路线图，但是上面的实例仍然会发生，这是我们在定义安全策略时需要考虑的事情。 在我们的例子中，如果我们决定只通过 SameSite cookie 来减轻 CSRF 攻击，那么我们应该意识到我们正在将 Safari 用户置于危险之中。我们的用户也应该知道这一点。 最后但并非最不重要,你应该记住,你可以决定是否支持浏览器版本:支持每一个浏览器版本将是不切实际的(想想 Internet Explorer 6)。虽然确保最近几个版本的主流浏览器的支持通常是一个好的决定，但是如果你不打算在特定的平台上提供保护，，一般建议让你的用户知道。 专业提示:你不应该鼓励你的用户使用过时的浏览器，或积极支持他们。尽管你可能已经采取了所有必要的预防措施，但是其他web开发人员可能没有。鼓励用户使用主流浏览器支持的最新版本。 供应商还是标准bug? 普通用户通过第三方客户端（浏览器）访问我们的应用程序这一事实增加了另一层次的间接性：浏览器本身可能存在安全漏洞。‘ 供应商通常会向能够发现浏览器自身漏洞的安全研究人员提供奖励(即 bug奖金)。这些bug与你的实现无关，而是与浏览器本身处理安全性的方式有关。 例如，Chrome 奖励计划可让安全工程师与 Chrome 安全团队联系，报告他们发现的漏洞。 如果确认了这些漏洞，则会发布补丁，通常会向公众发布安全建议通知，研究人员会从该计划中获得（通常是财务上的）奖励。 像谷歌这样的公司在他们的Bug赏金项目中投入了相对较多的资金，这使得他们能够通过承诺在发现应用程序的任何问题时获得经济利益来吸引研究人员。 在一个漏洞赏金计划中，每个人都是赢家:供应商设法提高其软件的安全性，研究人员也因此获得报酬。我们将在后面讨论这些程序，因为我相信Bug赏金计划应该在安全领域有自己的一节。 Jake Archibald 是谷歌的一名开发人员，他最近发现了一个影响多个浏览器的漏洞。他在一篇有趣的博客文章中记录了他的努力，他如何接触不同的供应商，以及他们的反应，建议你阅读 这篇文章。 开发人员的浏览器 到目前为止，我们应该理解一个非常简单但相当重要的概念：浏览器只是为普通网络冲浪者构建的 HTTP 客户端。 它们肯定比平台的纯HTTP客户端更强大(例如，考虑NodeJS的require(‘HTTP’))，但归根结底，它们“只是”更简单的 HTTP客户端的自然演化。 作为开发人员，我们选择的HTTP客户机可能是 Daniel Stenberg 的 cURL，他是 web 开发人员每天使用的最流行的软件程序之一。它允许我们通过从命令行发送 HTTP 请求来实时执行 HTTP 交换:
在上面的示例中，我们在 localhost:8080/ 上请求了文档，本地服务器成功响应。 在这里，我们没有将响应的主体显示在命令行，而是使用了 -I 标志，它告诉 cURL 我们只对响应头感兴趣。更进一步，我们可以指示 cURL 显示更多的信息，包括它执行的实际请求，以便更好地查看整个HTTP交换。需要使用的选项是-v(详细):
主流浏览器通过它们的 DevTools 可以获得几乎相同的信息。 （编辑：东莞站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
