浏览器工作流程_浏览器如何工作

浏览器工作流程

by Alex Nadalin

通过亚历克斯·纳达林

浏览器如何工作 (How Browsers Work)

Web应用程序安全性简介 (An Introduction to Web Application Security)

Let’s open this series on Web Application Security with an explanation of what browsers do and how they do it. Since most of your customers will interact with your web application through a browser, it’s imperative to understand the basics of these wonderful programs.

让我们打开有关Web应用程序安全性的系列文章，其中解释了浏览器的工作方式以及它们的工作方式。 由于大多数客户将通过浏览器与Web应用程序进行交互，因此必须了解这些出色程序的基础。

The browser is a rendering engine. Its job is to download a web page and render it in a way that’s understandable by a human being.

浏览器是渲染引擎 。 它的工作是下载网页并以人类可以理解的方式呈现它。

Even though this is an almost-criminal oversimplification, it’s all we need to know for now.

即使这几乎是一种犯罪性的过分简化，但这也是我们现在所需要知道的。

• The user enters an address in the browser bar.
  用户在浏览器栏中输入一个地址。
• The browser downloads the “document” at that URL and renders it.
  浏览器通过该URL下载“文档”并进行呈现。

You might be used to working with one of the most popular browsers such as Chrome, Firefox, Edge or Safari, but that does not mean that there aren’t different browsers out there.

您可能已经习惯了使用最流行的浏览器之一，例如Chrome，Firefox，Edge或Safari，但这并不意味着没有其他浏览器。

lynx, for example, is a lightweight, text-based browser that works from your command line. At the heart of lynx lies the same exact principles that you would find in any other “mainstream” browsers. A user enters a web address (URL), the browser fetches the document and renders it — the only difference being the fact that lynx does not use a visual rendering engine but rather a text-based interface, which makes websites like Google look like this:

例如， lynx是一种轻量级的基于文本的浏览器，可从您的命令行运行。 lynx的核心是您在任何其他“主流”浏览器中都可以找到的相同原理。 用户输入网址(URL)，浏览器将获取文档并进行呈现-唯一的区别是，lynx不使用视觉呈现引擎，而是使用基于文本的界面，这使得类似Google的网站看起来像这样：

We broadly understand what a browser does, but let’s take a closer look at the steps these ingenious applications do for us.

我们大致了解浏览器的功能，但让我们仔细看看这些巧妙的应用程序为我们执行的步骤。

浏览器做什么？ (What does a browser do?)

Long story short, a browser’s job mainly consists of:

长话短说，浏览器的工作主要包括：

• DNS resolution
  DNS解析
• HTTP exchange
  HTTP交换
• Rendering
  渲染图
• Rinse and repeat
  冲洗并重复

DNS解析 (DNS Resolution)

This process makes sure that once the user enters a URL, the browser knows which server it has to connect to. The browser contacts a DNS server to find that google.com translates to 216.58.207.110, an IP address the browser can connect to.

此过程可确保一旦用户输入URL，浏览器就会知道它必须连接到哪个服务器。 浏览器联系DNS服务器，发现google.com转换为浏览器可以连接到的IP地址216.58.207.110 。

HTTP交换 (HTTP Exchange)

Once the browser has identified which server is going to serve our request, it will initiate a TCP connection with it and begin the HTTP exchange. This is nothing but a way for the browser to communicate with the server what it needs, and for the server to reply back.

一旦浏览器确定了哪个服务器将满足我们的请求，它将与之启动TCP连接并开始HTTP交换 。 这不过是浏览器与服务器进行通信以及服务器进行回复的一种方式。

HTTP is simply the name of the most popular protocol for communicating on the web, and browsers mostly talk via HTTP when communicating with servers. An HTTP exchange involves the client (our browser) sending a request, and the server replying back with a response.

HTTP只是最流行的网络通信协议名称，浏览器在与服务器通信时大多通过HTTP进行通信。 HTTP交换涉及客户端(我们的浏览器)发送请求 ，而服务器则通过响应进行回复 。

For example, after the browser has successfully connected to the server behind google.com, it will send a request that looks like the following:

例如，浏览器成功连接到google.com后面的服务器后，它将发送如下请求：

GET / HTTP/1.1Host: google.comAccept: */*

Let’s break the request down, line by line:

让我们逐行细分请求：

• GET / HTTP/1.1: with this first line, the browser asks the server to retrieve the document at the location /, adding that the rest of the request will follow the HTTP/1.1 protocol (it could also use 1.0 or 2)

  GET / HTTP/1.1 ：在第一行中，浏览器要求服务器在/位置检索文档，并补充说，其余请求将遵循HTTP / 1.1协议(也可以使用1.0或2 )

• Host: google.com: this is the only HTTP header mandatory in HTTP/1.1. Since the server might serve multiple domains (google.com, google.co.uk, etc) the client here mentions that the request was for that specific host

  Host: google.com ：这是HTTP / 1.1中唯一必需的HTTP标头 。 由于服务器可能服务于多个域( google.com ， google.co.uk等)，因此此处的客户端提到请求是针对该特定主机的

• Accept: */*: an optional header, where the browser is telling the server that it will accept any kind of response back. The server could have a resource that’s available in JSON, XML or HTML formats, so it can pick whichever format it prefers

  Accept: */* ：一个可选的标头，浏览器告诉服务器它将接受任何形式的响应。 服务器可能具有JSON，XML或HTML格式的可用资源，因此它可以选择喜欢的任何格式

After the browser, which acts as a client, is done with its request, it’s the turn of the server to reply back. This is what a response looks like:

充当客户端的浏览器完成其请求后，该轮到服务器进行回复了。 响应如下所示：

HTTP/1.1 200 OKCache-Control: private, max-age=0Content-Type: text/html; charset=ISO-8859-1Server: gwsX-XSS-Protection: 1; mode=blockX-Frame-Options: SAMEORIGINSet-Cookie: NID=1234; expires=Fri, 18-Jan-2019 18:25:04 GMT; path=/; domain=.google.com; HttpOnly

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

Whoa, that’s a lot of information to digest. The server lets us know that the request was successful (200 OK) and adds a few headers to the response, for example, it advertises what server processed our request (Server: gws), what’s the X-XSS-Protection policy of this response and so on and so forth.

哇，这是很多要消化的信息。 服务器让我们知道请求已成功( 200 OK )并在响应中添加了一些标头，例如，它通告了服务器处理了我们的请求( Server: gws )，该响应的X-XSS-Protection策略是什么等等等等。

Right now, you do not need to understand each and every single line in the response. We’ll be covering the HTTP protocol, its headers, and so on later on in this series.

现在，您无需了解响应中的每一行。 在本系列的后面部分，我们将介绍HTTP协议，其标头等。

For now, all you need to understand is that the client and the server are exchanging information and that they do so via HTTP.

现在，您需要了解的是客户端和服务器正在通过HTTP进行信息交换。

渲染图 (Rendering)

Last, but not least, the rendering process. How good would a browser be if the only thing it would show to the user is a list of funny characters?

最后但并非最不重要的是渲染过程。 如果向用户显示的唯一内容是一系列有趣的字符，浏览器的性能如何？

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

In the body of the response, the server includes the representation of the response according to the Content-Type header. In our case, the content type was set to text/html, so we are expecting HTML markup in the response — which is exactly what we find in the body.

在响应的正文中，服务器根据Content-Type标头包含响应的表示形式。 在我们的例子中，内容类型设置为text/html ，因此我们期望响应中有HTML标记-这正是我们在正文中找到的内容。

This is where a browser truly shines. It parses the HTML, loads additional resources included in the markup (for example, there could be JavaScript files or CSS documents to fetch) and presents them to the user as soon as possible.

这是浏览器真正闪耀的地方。 它解析HTML，加载标记中包含的其他资源(例如，可能有JavaScript文件或CSS文档要提取)，并尽快将其呈现给用户。

Once more, the end result is something the average Joe can understand.

再一次，最终结果是Joe可以理解的。

For a more detailed version of what really happens when we hit enter in the address bar of a browser I would suggest to read “What happens when…”, a very elaborate attempt at explaining the mechanics behind the process.

有关我们在浏览器的地址栏中按下Enter键后实际发生的情况的更详细版本，我建议您阅读“ 当……时会发生什么 ”，这是一个非常详尽的尝试，旨在解释该过程背后的机制。

Since this is a series focused on security, I am going to drop a hint on what we’ve just learned: attackers easily make a living out of vulnerabilities in the HTTP exchange and rendering part. Vulnerabilities, and malicious users, lurk elsewhere as well, but a better security approach on those levels already allows you to make strides in improving your security posture.

由于本系列是关于安全性的系列文章，因此我将暗示一下我们刚刚学到的内容： 攻击者可以轻松地摆脱HTTP交换和呈现部分中的漏洞 。 漏洞和恶意用户也潜伏在其他地方，但是在这些级别上更好的安全性方法已经可以使您在改善安全性方面取得长足的进步。

供应商 (Vendors)

The 4 most popular browser out there belong to different vendors:

四种最受欢迎​​的浏览器属于不同的供应商：

• Chrome by Google
  Google Chrome
• Firefox by Mozilla
  Mozilla的Firefox
• Safari by Apple
  苹果的Safari
• Edge by Microsoft
  微软的优势

Beside battling each other in order to increase their market penetration, vendors also engage with each other in order to improve web standards, which are a sort of “minimum requirements” for browsers.

除了相互竞争以提高其市场渗透率外，供应商还相互合作以提高Web标准 ，这是浏览器的一种“最低要求”。

The W3C is the body behind the development of the standards, but it’s not unusual for browsers to develop their own features that eventually make it as web standards, and security is no exception to that.

W3C是标准制定的主体，但是浏览器开发自己的功能并最终使其成为Web标准并不少见，安全性也不例外。

Chrome 51, for example, introduced SameSite cookies, a feature that would allow web applications to get rid of a particular type of vulnerability known as CSRF (more on this later). Other vendors decided this was a good idea and followed suit, leading to SameSite being a web standard: as of now, Safari is the only major browser without SameSite cookie support.

例如，Chrome 51 引入了SameSite cookie ，该功能可以使Web应用程序摆脱一种称为CSRF的特定类型的漏洞(稍后会详细介绍)。 其他供应商认为这是个好主意，因此也效仿，使SameSite成为Web标准：到目前为止， Safari是唯一不支持SameSite cookie的主流浏览器 。

This tells us 2 things:

这告诉我们两件事：

• Safari does not seem to care enough about their users’ security (just kidding: SameSite cookies will be available in Safari 12, which might have already been released by the time you’re reading this article)
  Safari似乎对用户的安全性不太关心(开个玩笑：SameSite cookie将在Safari 12中可用，在您阅读本文时可能已经发布了)

• patching a vulnerability on one browser does not mean that all your users are safe

  在一个浏览器上修补漏洞并不意味着您所有的用户都是安全的

The first point is a shot at Safari (as I mentioned, just kidding!), while the second point is really important. When developing web applications, we don’t just need to make sure that they look the same across various browsers, but also that they ensure our users are protected in the same way across platforms.

第一点是对Safari的射击(正如我提到的，只是在开玩笑！)，而第二点确实很重要。 在开发Web应用程序时，我们不仅需要确保它们在各种浏览器中的外观相同，而且还需要确保我们的用户在不同平台上的保护方式相同。

Your strategy towards web security should vary according to what a browser’s vendor allows us to do. Nowadays, most browsers support the same set of features and rarely deviate from their common roadmap, but instances like the one above still happen, and it’s something we need to take into account when defining our security strategy.

您针对网络安全的策略应根据浏览器供应商允许我们执行的操作而有所不同 。 如今，大多数浏览器都支持相同的功能集，并且很少偏离其通用路线图，但是仍然出现上述情况，这是我们在定义安全策略时需要考虑的事项。

In our case, if we decide that we’re going to mitigate CSRF attacks only through SameSite cookies, we should be aware that we’re putting our Safari users at risk. And our users should know that too.

在我们的案例中，如果我们决定仅通过SameSite cookie来缓解CSRF攻击，那么我们应该意识到，我们将使Safari用户面临风险。 我们的用户也应该知道这一点。

Last but not least, you should remember that you can decide whether to support a browser version or not: supporting each and every browser version would be impractical (think of Internet Explorer 6). Making sure that the last few versions of the major browsers are supported, though, is generally a good decision. If you don’t plan to offer protection on a particular platform, though, it’s generally advisable to let your users know.

最后但并非最不重要的一点是，您应该记住，可以决定是否支持浏览器版本：支持每个浏览器版本都不切实际(请考虑使用Internet Explorer 6)。 不过，确保支持主要浏览器的最后几个版本通常是一个不错的决定。 但是，如果您不打算在特定平台上提供保护，通常建议让您的用户知道。

Pro Tip: You should never encourage your users to use outdated browsers, or actively support them. Even though you might have taken all the necessary precautions, other web developers may have not. Encourage users to use the latest supported version of one of the major browsers.

专家提示 ：您永远不应鼓励用户使用过时的浏览器或积极支持它们。 即使您可能已采取所有必要的预防措施，其他Web开发人员也可能没有。 鼓励用户使用一种主要浏览器的最新受支持版本。

供应商还是标准错误？ (Vendor or standard bug?)

The fact that the average user accesses our application through a 3rd party client (the browser) adds another level of indirection towards a clear, secure browsing experience: the browser itself might present a security vulnerability.

普通用户通过第三方客户端(浏览器)访问我们的应用程序这一事实为实现清晰，安全的浏览体验增加了另一种间接方式：浏览器本身可能存在安全漏洞。

Vendors generally provide rewards (aka bug bounties) to security researchers who can find a vulnerability on the browser itself. These bugs are not tied to your implementation, but rather to how the browser handles security on its own.

供应商通常会向能够在浏览器本身上发现漏洞的安全研究人员提供奖励(即漏洞赏金 )。 这些错误与您的实现无关，而与浏览器如何自行处理安全性有关。

The Chrome reward program, for example, lets security engineers reach out to the Chrome security team to report vulnerabilities they have found. If these vulnerabilities are confirmed, a patch is issued, a security advisory notice is generally released to the public, and the researcher receives a (usually financial) reward from the program.

例如， Chrome奖励计划使安全工程师可以与Chrome安全团队联系，以报告他们发现的漏洞。 如果确认了这些漏洞，则会发布补丁，通常会向公众发布安全建议通知，研究人员将从程序中获得(通常是财务上的)奖励。

Companies like Google invest a relatively good amount of capital into their Bug Bounty programs, as it allows them to attract researchers by promising a financial benefit should they find any problem with the application.

像Google这样的公司在其Bug赏金计划中投入了相对大量的资金，因为它允许他们发现应用程序有问题时，通过保证财务利益来吸引研究人员。

In a Bug Bounty program, everyone wins: the vendor manages to improve the security of its software, and researchers get paid for their findings. We will discuss these programs later on, as I believe Bug Bounty initiatives deserve their own section in the security landscape.

在漏洞赏金计划中，每个人都赢了：供应商设法提高其软件的安全性，研究人员因此而获得报酬。 我们稍后将讨论这些程序，因为我认为Bug Bounty计划在安全领域应有其一席之地。

Jake Archibald is a developer advocate at Google who recently discovered a vulnerability impacting more than one browser. He documented his efforts, how he approached different vendors, and their reactions in an interesting blog post that I’d recommend you read.

杰克·阿奇博尔德(Jake Archibald)是Google的开发人员拥护者，他最近发现了一个影响多个浏览器的漏洞。 他在一篇有趣的博客文章中记录了他的努力，他与不同供应商的接触方式以及他们的React，我建议您阅读。

开发人员浏览器 (A browser for developers)

By now, we should have understood a very simple but rather important concept: browsers are simply HTTP clients built for the average internet surfer.

到现在为止，我们应该已经理解了一个非常简单但相当重要的概念： 浏览器只是为普通互联网冲浪者构建的HTTP客户端 。

They are definitely more powerful than a platform’s bare HTTP client (think of NodeJS’s require('http'), for example), but at the end of the day, they’re “just” a natural evolution of simpler HTTP clients.

它们绝对比平台上的裸HTTP客户端(例如，想想NodeJS的require('http')更强大，但是到最后，它们“只是”简单HTTP客户端的自然演变。

As developers, our HTTP client of choice is probably cURL by Daniel Stenberg, one of the most popular software programs web developers use on a daily basis. It allows us to do an HTTP exchange on-the-fly, by sending an HTTP request from our command line:

作为开发人员，我们选择的HTTP客户端可能是Daniel Stenberg的cURL ，Daniel Stenberg是Web开发人员每天使用的最受欢迎的软件程序之一。 它允许我们通过从命令行发送HTTP请求来即时进行HTTP交换：

$ curl -I localhost:8080

HTTP/1.1 200 OKserver: ecstatic-2.2.1Content-Type: text/htmletag: "23724049-4096-"2018-07-20T11:20:35.526Z""last-modified: Fri, 20 Jul 2018 11:20:35 GMTcache-control: max-age=3600Date: Fri, 20 Jul 2018 11:21:02 GMTConnection: keep-alive

In the example above, we have requested the document at localhost:8080/, and a local server replied successfully.

在上面的示例中，我们在localhost:8080/处请求了文档，并且本地服务器已成功回复。

Rather than dumping the response’s body to the command line, here we’ve used the -I flag which tells cURL we’re only interested in the response headers. Taking it one step forward, we can instruct cURL to dump a little more information, including the actual request it performs, so that we can have a better look at this whole HTTP exchange. The option we need to use is -v (verbose):

而不是将响应的主体转储到命令行，这里我们使用了-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 OKHTTP/1.1 200 OK< server: ecstatic-2.2.1server: ecstatic-2.2.1< Content-Type: text/htmlContent-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 GMTlast-modified: Fri, 20 Jul 2018 11:20:35 GMT< cache-control: max-age=3600cache-control: max-age=3600< Date: Fri, 20 Jul 2018 11:25:55 GMTDate: Fri, 20 Jul 2018 11:25:55 GMT< Connection: keep-aliveConnection: keep-alive

<* Connection #0 to host localhost left intact

Just about the same information is available in mainstream browsers through their DevTools.

主流浏览器的DevTools可以提供几乎相同的信息。

As we’ve seen, browsers are nothing more than elaborate HTTP clients. Sure, they add an enormous amount of features (think of credential management, bookmarking, history, etc) but the truth is that they were born as HTTP clients for humans. This is important, as in most cases you don’t need a browser to test your web application’s security, as you can simply “curl it” and have a look at the response.

如我们所见，浏览器仅是精心设计的HTTP客户端。 当然，它们添加了大量功能(例如凭据管理，书签，历史记录等)，但事实是它们是作为人类的HTTP客户端而诞生的。 这很重要，因为在大多数情况下，您不需要浏览器即可测试Web应用程序的安全性，因为您可以简单地“卷曲”它并查看响应。

One final thing that I’d like to point out, is that anything can be a browser. If you have a mobile application that consumes APIs through the HTTP protocol, then the app is your browser — it just happens to be a highly customized one you built yourself, one that only understands a specific type of HTTP responses (from your own API).

我想指出的最后一件事是， 任何东西都可以是浏览器 。 如果您有一个通过HTTP协议使用API​​的移动应用程序，那么该应用程序就是您的浏览器-它恰好是您自己构建的高度定制的应用程序，仅能理解特定类型的HTTP响应(通过您自己的API) 。

进入HTTP协议 (Into the HTTP protocol)

As we mentioned, the HTTP exchange and rendering phases are the ones that we’re mostly going to cover, as they provide the largest number of attack vectors for malicious users.

如前所述， HTTP交换和呈现阶段是我们最主要要讨论的阶段，因为它们为恶意用户提供了最多数量的攻击媒介 。

In the next article, we’re going to take a deeper look at the HTTP protocol and try to understand what measures we should take in order to secure HTTP exchanges.

在下一篇文章中 ，我们将更深入地研究HTTP协议，并尝试了解应采取哪些措施来保护HTTP交换。

Originally published at odino.org (29 July 2018).You can follow me on Twitter - rants are welcome! ?

最初发布于odino.org (2018年7月29日)。 您可以在Twitter上关注我-欢迎咆哮！ ？

翻译自: https://www.freecodecamp.org/news/web-application-security-understanding-the-browser-5305ed2f1dac/

浏览器工作流程