Web 应用安全性: 浏览器是如何工做的

时间 2019-11-08

标签 web 应用安全性浏览器如何栏目 HTML 繁體版

原文原文链接

这本系列的第一篇，先解释浏览器的功能以及执行方式。因为大多数客户将经过浏览器与 web 应用程序进行交互，所以必须了解这些出色程序的基础知识。html

想阅读更多优质文章请猛戳GitHub博客,一年百来篇优质文章等着你！前端

浏览器是一个渲染引擎，它的工做是下载一个web页面，并以人类可以理解的方式渲染它。git

虽然这几乎是一种过于简单的过度简化，但咱们如今须要知道的所有内容。github

用户在浏览器栏中输入一个地址。
浏览器从该 URL 下载“文档”并渲染它。

你可能习惯使用 Chrome，Firefox，Edge或Safari等流行的浏览器之一，但这并不意味着没有不一样的浏览器。web

例如，lynx 是一种轻量级的、基于文本的浏览器，能够在命令行中工做。lynx 的核心原理与其余“主流”浏览器的原理彻底相同。用户输入 web 地址(URL)，浏览器获取文档并呈现它——惟一的区别是 lynx 不使用可视化渲染引擎，而是使用基于文本的界面，这使得像谷歌这样的网站看起来像这样:chrome

咱们大体了解浏览器的功能，可是让咱们仔细看看这些机智的应用程序为咱们所作的步骤。segmentfault

浏览器作了什么?

长话短说，浏览器的工做主要包括:浏览器

DNS 解析
HTTP 交换
渲染
重复如下步骤

DNS 解析

这个过程确保一旦用户输入 URL，浏览器就知道它必须链接到哪一个服务器。浏览器联系 DNS 服务器，发现google.com 翻译成 216.58.207.110，这是一个浏览器能够链接的 IP 地址。安全

HTTP 交换

一旦浏览器肯定了哪一个服务器将为咱们的请求提供服务，它将启动与它的 TCP 链接并开始 HTTP 交换。这只是浏览器与服务器通讯所需内容以及服务器回复的一种方式。服务器

HTTP 只是用于在 Web 上进行通讯协议的名称，而浏览器通常经过 HTTP 与服务器进行通讯。 HTTP 交换涉及客户端（咱们的浏览器）发送请求，服务器回复响应。

例如，当浏览器成功链接到 google.com 背后的服务器后，它将发送一个以下所示的请求:

GET / HTTP/1.1
Host: google.com
Accept: */*

让咱们一行一行地把请求分解:

GET / HTTP/1.1:在第一行中，并补充说其他请求将遵循 HTTP/1.1 协议（它也可使用1.0或2）
Host: google.com：这是 HTTP/1.1 中惟一必须的 HTTP 报头。由于服务器可能服务多个域(google.com, google.co.uk) 。这里的客户端提到请求是针对特定的主机的。
Accept: */*：一个可选的标头，其中浏览器告诉服务器接受任何类型的响应。服务器能够拥有 JSON、XM L或HTML 格式的可用资源，所以它能够选择本身喜欢的格式。

做为客户端的浏览器发送请求以后，就轮到服务器进行响应了，这是响应的格式以下:

HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly
<!doctype html><html">
...
...
</html>

哇，有不少信息须要消化。服务器让咱们知道请求是成功的(200 OK)，并向响应中添加一些头部信息，例如，它告知哪一个服务器处理了咱们的请求(Server:gws)，该响应的 X-XSS-Protection 策略是什么，等等。

如今，你不须要理解响应中的每一行，在本系列后面的文章中，咱们将介绍 HTTP 协议及其头部等内容。

如今，你只须要了解客户端和服务器正在交换信息，而且它们是经过 HTTP 进行交换的。

渲染

<!doctype html><html">
...
...
</html>

在响应的主体中，服务器根据 Content-Type 头包括响应类型来表示。在咱们的例子中，内容类型设置为 text/ html，所以咱们期待响应中的 HTML 标记 - 这正是咱们在正文中找到的。

这才是浏览器真正的亮点所在。它解析 HTML，加载标记中包含的额外资源(例如，可能须要获取JavaScript文件或CSS文档)，并尽快将它们呈现给用户。

最终的结果是普通人可以理解的：

若是想要更详细地了解当咱们在浏览器地址栏中按回车键时会发生什么，建议阅读“What happens when…”，这是一个很是精细的尝试来解释该过程背后的机制。

因为这是一个关注安全性的系列文章，从刚刚了解到的内容能够提到提示:攻击者能够轻松地利用 HTTP 交换和渲染部分中的漏洞谋生。漏洞和恶意用户也潜伏在其余地方，可是这些级别上更好的安全方法已经容许你在改进安全性方面取得进展。

供应商

4 个最流行的浏览器属于不一样的公司:

谷歌的 Chrome
Mozilla 的火狐
苹果的 Safari
微软的 Edge

除了为了增长市场渗透率而相互竞争以外，供应商也为了提升 web 标准而相互合做，这是对浏览器的一种“最低要求”。

W3C是标准开发的主体，可是浏览器开发本身的特性并最终成为 web 标准的状况并很多见，安全性也不例外。

例如，Chrome 51 引入了 SameSite cookie，该功能容许 Web 应用程序摆脱称为 CSRF 的特定类型的漏洞（稍后将详细介绍）。其余供应商认为这是一个好主意，并纷纷效仿，致使 SameSite 成为 web 标准:到目前为止，Safari 是惟一没有 SameSite cookie 支持的主流浏览器。

这告诉咱们两件事:

Safari彷佛并不关心用户的安全性（开玩笑：Safari 12中将提供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 交换:

$ curl -I localhost:8080
HTTP/1.1 200 OK
server: ecstatic-2.2.1
Content-Type: text/html
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
cache-control: max-age=3600
Date: Fri, 20 Jul 2018 11:21:02 GMT
Connection: keep-alive

在上面的示例中，咱们在 localhost:8080/ 上请求了文档，本地服务器成功响应。

在这里，咱们没有将响应的主体显示在命令行，而是使用了 -I 标志，它告诉 cURL 咱们只对响应头感兴趣。更进一步，咱们能够指示 cURL 显示更多的信息，包括它执行的实际请求，以便更好地查看整个HTTP交换。须要使用的选项是-v(详细):

$ curl -I -v localhost:8080
* Rebuilt URL to: localhost:8080/
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> HEAD / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< server: ecstatic-2.2.1
server: ecstatic-2.2.1
< Content-Type: text/html
Content-Type: text/html
< etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
etag: "23724049-4096-"2018-07-20T11:20:35.526Z""
< last-modified: Fri, 20 Jul 2018 11:20:35 GMT
last-modified: Fri, 20 Jul 2018 11:20:35 GMT
< cache-control: max-age=3600
cache-control: max-age=3600
< Date: Fri, 20 Jul 2018 11:25:55 GMT
Date: Fri, 20 Jul 2018 11:25:55 GMT
< Connection: keep-alive
Connection: keep-alive
<
* Connection #0 to host localhost left intact

主流浏览器经过它们的 DevTools 能够得到几乎相同的信息。

正如咱们所见，浏览器只不过是精心设计的HTTP客户端。固然，他们添加了大量的功能（想到凭据管理，书签，历史等），但事实是，它们是做为人类的 HTTP 客户端而诞生的。这很重要，由于在大多数状况下，不须要使用浏览器来测试Web应用程序的安全性，由于你能够简单的经过 curl 命令来查看响应信息。

进入 HTTP 协议

正如咱们所提到的，HTTP交换和渲染阶段是咱们主要要涉及的阶段，由于它们为恶意用户提供了最大数量的攻击媒介。

在下一篇文章中，咱们将深刻研究HTTP协议，并尝试了解为了保护HTTP交换，咱们应该采起哪些措施。

原文：

https://medium.freecodecamp.o...

你的点赞是我持续分享好东西的动力，欢迎点赞！

交流

干货系列文章汇总以下，以为不错点个Star，欢迎加群互相学习。

https://github.com/qq44924588...

我是小智，公众号「大迁世界」做者，对前端技术保持学习爱好者。我会常常分享本身所学所看的干货，在进阶的路上，共勉！

关注公众号，后台回复福利，便可看到福利，你懂的。