让我们开始一系列有关Web应用程序安全性的文章，并解释浏览器的功能以及它们的工作方式。 由于大多数客户将通过浏览器与Web应用程序进行交互，因此您需要了解这些出色程序的工作原理。
铬和山猫浏览器是
渲染引擎 。 他的工作是下载网页并以可读的方式呈现。
尽管这几乎是一种犯罪简化，但是现在这是我们目前所需要知道的。
- 用户在浏览器输入行中输入地址。
- 浏览器在此URL上下载“文档”并显示它。
您可能已经习惯了使用最流行的浏览器之一，例如Chrome，Firefox，Edge或Safari，但这并不意味着世界上没有其他浏览器。
例如，
lynx是轻量级的命令行文本浏览器。 lynx的核心是与其他主流浏览器相同的原理。 用户输入网址（URL），浏览器下载文档并显示它-唯一的区别是lynx不使用图形渲染引擎，而是文本界面，这要归功于像Google这样的网站：
通常，我们对浏览器的功能有所了解，但让我们仔细研究一下这些巧妙的应用程序为我们执行的操作。
浏览器做什么？
简而言之，浏览器基本上包括
DNS解析
此过程可帮助浏览器在用户输入URL时知道应连接到哪个服务器。 浏览器联系DNS服务器，并检测到
google.com与数字集
216.58.207.110相匹配-浏览器可以连接到的IP地址。
HTTP交换
一旦浏览器确定哪个服务器将满足我们的请求，它将与之建立TCP连接并开始
HTTP交换 。 这仅是浏览器与所需服务器之间通信的一种方式，对于服务器而言，它是响应浏览器请求的方式。
HTTP只是网络上最流行的通信协议的名称，浏览器在与服务器通信时大多选择HTTP。 HTTP交换意味着客户端（我们的浏览器）发送
请求 ，而服务器发送
响应 。
例如，浏览器成功连接到服务
google.com的服务器后，它将发送如下所示的请求
GET / HTTP/1.1
Host: google.com
Accept让我们逐行解析查询：
- GET / HTTP / 1.1 ：在第一行中，浏览器要求服务器从/位置检索文档，然后添加其余请求将通过HTTP / 1.1进行（或者也可以使用1.0或2版本）
- 主机：google.com ： 这是HTTP / 1.1协议所需的唯一HTTP标头 。 由于服务器可以服务多个域（google.com，google.co.uk等），因此客户端在此处提到该请求是针对该特定主机的。
- 接受：* / * ：一个可选的标头，浏览器在其中告诉服务器它将接受任何响应。 服务器可以具有JSON，XML或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文档以进行加载），并尽快将其呈现给用户。
再一次，最终结果应该是普通Vasya可以访问的结果。
如果您需要更详细的说明，当我们按浏览器地址栏中的Enter键时实际发生的情况，我建议您阅读文章
“当...时发生的情况” ，这是一种非常细致的尝试，试图解释构成此过程基础的机制。
由于本系列文章专门讨论安全性，因此我将向您提供一些有关我们刚刚发现的信息：攻击者可以轻松地从
HTTP交换和呈现方面的漏洞中谋生。 漏洞，恶意用户和其他奇特的生物在其他地方可以找到，但是在上述级别提供保护的更有效方法已经可以使您成功改善安全状态。
供应商
最受欢迎的4种浏览器属于不同的供应商：
- 谷歌浏览器
- Mozilla的Firefox
- 苹果Safari
- 微软Edge
除了相互竞争以提高其市场渗透率外，供应商还相互交流以提高Web标准，这是浏览器的一种“最低要求”。
W3C是标准开发的基石，但是浏览器经常开发自己的功能，这些功能最终变成Web标准，安全性也不例外。
例如，Chrome 51中引入了
SameSite cookie ，该功能使Web应用程序摆脱了称为CSRF的某种类型的漏洞（稍后会详细介绍）。 其他制造商认为这是个好主意，因此也效仿，这导致SameSite方法成为Web标准：Safari当前是唯一不
支持SameSite cookie的主要浏览器。
这告诉我们两件事：
- Safari似乎不太关心用户的安全性（开个玩笑：SameSite cookie将在Safari 12中可用，在阅读本文时可能已经发布了）
- 修复一个浏览器中的漏洞并不意味着您所有的用户都是安全的
第一点是在Safari上拍摄（正如我说的那样，我在开玩笑！），第二点真的很重要。 在开发Web应用程序时，我们不仅需要确保它们在不同的浏览器中看起来相同，还需要为不同平台上的用户提供相同的保护。
您的网络安全策略应根据浏览器供应商为我们提供的功能而有所不同。 当前，大多数浏览器都支持相同的功能集，并且很少偏离其总体路线图，但是仍会发生上述情况，这是在定义安全策略时应考虑的问题。
在我们的案例中，如果我们决定仅使用SameSite Cookie来抵消CSRF攻击，那么我们应该知道我们正在使Safari用户面临风险。 我们的用户也应该知道这一点。
最后但并非最不重要的一点是，您必须记住，可以决定是否支持浏览器版本：对每个浏览器版本的支持都是不切实际的（请记住Internet Explorer 6）。 尽管如此，对主要浏览器的多个最新版本的可靠支持通常是一个很好的解决方案。 但是，如果您不打算在任何特定平台上提供保护，则强烈建议您的用户知道这一点。
给专业人士的提示 ：永远不要鼓励您的用户使用过时的浏览器或积极支持它们。 即使您采取了所有必要的预防措施，其他Web开发人员也没有采取任何措施。 鼓励用户使用其主要浏览器之一的最新受支持版本。
供应商还是标准错误？
普通用户通过第三方客户端软件（浏览器）访问我们的应用程序这一事实增加了另一个层次，使通向便捷，安全的Web浏览的路径变得复杂：浏览器本身可能是安全漏洞的来源。
供应商通常会向可能在浏览器本身中寻找漏洞的安全研究人员提供奖励（也称为漏洞赏金）。 这些错误与您的Web应用程序无关，而与浏览器如何独立管理安全性有关。
例如，
Chrome奖励计划允许安全研究人员联系Chrome安全小组，以报告他们发现的漏洞。 如果确认存在漏洞，将发布修复程序，并且通常会发布安全通知，研究人员将从该程序中获得（通常是财务上的）报酬。
诸如Google之类的公司已经在其Bug赏金计划中投入了大量资金，因为这使公司能够吸引许多研究人员，并向他们保证，如果发现经过测试的软件有任何问题，便会带来经济利益。
每个人都将赢得Bug赏金计划：提供者设法提高其软件的安全性，研究人员为此得到了报酬。 我们相信，Bug Bounty的计划值得在安全领域中单独讨论，我们将在以后讨论这些程序。
杰克·阿奇博尔德（Jake Archibald）是一位Google 倡导者 ，他发现了一个影响多个浏览器的漏洞。 他在一篇有趣的博客文章 （我建议您阅读）中记录了他为检测该漏洞所做的努力，与受此漏洞影响的各个供应商联系的过程以及供应商代表的反应。
开发者浏览器
到目前为止，我们应该已经理解了一个非常简单但相当重要的概念：浏览器仅仅是为“普通” Internet用户创建的HTTP客户端。
对于任何平台，浏览器绝对比简单的HTTP客户端强大（例如，请记住，NodeJS
依赖于“ 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应用程序的安全性。
最后我要指出的是：
浏览器可以是任何东西。 如果您有一个通过HTTP使用API的移动应用程序，那么此应用程序就是您的浏览器-您只需按单个订单对其进行配置，该命令就只能识别某种类型的HTTP响应（来自您自己的API）。
HTTP潜水
正如我们已经提到的，我们将最详细地介绍
HTTP交换和
呈现的各个阶段，因为它们为攻击者提供了最多
的攻击媒介 。
在下一篇文章中，我们将仔细研究HTTP协议，并尝试了解应采取哪些措施来确保HTTP交换的安全性。
该翻译由面向大型客户的专业网站开发公司 EDISON Software以及C＃和.NET Web开发提供支持 。