这里我们首先解释一下浏览器是做什么的以及它们是如何做的。由于大多数客户将通过浏览器与Web应用程序交互,因此了解这些出色程序的基础知识至关重要。浏览器是一个渲染引擎,它的工作是下载网页并以人类可以理解的方式渲染它。虽然这几乎是过于简单化了,但这就是我们现在需要知道的全部。用户在浏览器栏中输入地址。浏览器从该URL下载“文档”并呈现它。您可能习惯使用其中一种流行的浏览器,例如Chrome、Firefox、Edge或Safari,但这并不意味着没有不同的浏览器。例如,lynx是一种轻型、基于文本的浏览器,可从命令行运行。lynx的核心原理与其他“主流”浏览器完全相同。用户输入一个网址(URL),浏览器获取文档并渲染它——唯一的区别是lynx不使用可视化渲染引擎,而是基于文本的界面,这使得像谷歌这样的网站看起来像this:这是对浏览器可以做什么的概述,但让我们仔细看看这些聪明的应用程序为我们采取的步骤。浏览器做什么?长话短说,浏览器的工作主要包括:DNS解析HTTP交换渲染重复以下步骤DNS解析这个过程确保一旦用户输入URL,浏览器就知道它必须连接到哪个服务器。浏览器联系DNS服务器,发现google.com转换为216.58.207.110,这是浏览器可以连接的IP地址。HTTP交换一旦浏览器确定了哪个服务器将为我们的请求提供服务,它就会启动一个TCP连接并开始HTTP交换。这只是浏览器向服务器传达它想要的内容以及服务器回复的一种方式。HTTP只是用于在Web上通信的协议的名称,浏览器通常通过HTTP与服务器通信。HTTP交换涉及客户端(我们的浏览器)发送请求和服务器回复响应。例如,当浏览器成功连接到google.com后面的服务器时,它会发送如下请求:GET/HTTP/1.1Host:google.comAccept:*/*让我们逐行分解请求:GET/HTTP/1.1:在第一行,并添加请求的其余部分将遵循HTTP/1.1协议(也可以使用1.0或2)Host:google.com:这是HTTP/1.1中必需的HTTP标头。因为服务器可能服务于多个域(google.com、google.co.uk)。这里客户端提到请求是针对特定主机的。Accept:*/*:一个可选的标头,浏览器告诉服务器接受任何类型的响应。服务器可以拥有JSON、XML或HTML格式的可用资源,因此它可以选择自己喜欢的格式。作为客户端的浏览器发出请求后,就轮到服务器响应了。响应格式如下:HTTP/1.1200OKCache-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-201918:25:04GMT;path=/;domain=.google。com;HttpOnly......哇,有很多信息需要消化。服务器让我们知道请求成功(200OK)并向响应信息,例如,它告诉我们哪个服务器处理了我们的请求(Server:gws),该响应的X-XSS-Protection策略是什么等等。现在,您不需要了解响应中的每一行,稍后在本系列文章中,我们将介绍HTTP协议及其标头等。现在,您只需了解客户端和服务器正在交换信息,并且它们是通过HTTP进行的。在响应正文中呈现...,由服务器指示,包括根据Content-Type标头的响应类型。在我们的例子中,内容类型设置为text/html,所以我们期望响应中有HTML标记——这正是我们将在文本中找到的内容。这是浏览器真正闪耀的地方。它解析HTML,加载标记中包含的其他资源(例如,它可能需要获取JavaScript文件或CSS文档)并尽快将它们呈现给用户。最终结果对于普通人来说是可以理解的:如果你想更详细地了解当我们在浏览器地址栏,我推荐阅读“Whathappenswhen...”,这是一个非常细粒度的尝试来解释过程背后的机制。由于这是一个专注于安全的系列文章,所以可以从什么地方提到一个提示我们刚刚了解到:攻击者可以轻松利用HTTP交换和渲染部分是为了谋生。漏洞和恶意用户也潜伏在其他地方,但是在这些级别上更好的安全方法可以让您在提高安全性方面取得进展。供应商4款非常流行的浏览器分属不同的公司:Google的ChromeMozilla的FirefoxApple的SafariMicrosoft的Edge除了相互竞争提高市场渗透率外,供应商还合作提高网络标准,这对浏览器的要求非常低。W3C是标准制定机构,但浏览器开发自己的功能并最终成为网络标准的情况并不少见,安全性也不例外。例如,Chrome51引入了SameSitecookie,该功能允许Web应用程序摆脱称为CSRF的功能(稍后会详细介绍)。其他供应商认为这是一个好主意并效仿,导致SameSite成为网络标准:Safari是迄今为止唯一不支持SameSitecookie的主要浏览器......这告诉我们两件事:Safari似乎并不关心用户安全性(开个玩笑:SameSitecookie将在Safari12中可用,在您阅读本文时它可能已经发布)修补一个浏览器上的错误并不意味着一切用户安全的第一点是在Safari上尝试(正如我提到的,开玩笑!),第二点非常重要。在开发Web应用程序时,我们不仅需要确保它们在不同浏览器中看起来相同,还需要确保我们的用户在不同平台上受到同等保护。您的网络安全政策应根据您的浏览器供应商允许我们执行的操作而有所不同。今天,大多数浏览器都支持相同的功能集并且很少偏离它们的通用路线图,但上述情况仍然会发生,并且是我们在定义安全策略时需要考虑的事情。在我们的案例中,如果我们决定仅通过SameSitecookie减轻CSRF攻击,我们应该意识到我们将Safari用户置于风险之中。我们的用户也应该知道这一点。然后,您应该记住,由您决定是否支持浏览器版本:支持每个浏览器版本是不切实际的(想想InternetExplorer6)。虽然确保支持主要浏览器的最后几个版本通常是一个不错的决定,但如果您不打算在特定平台上提供保护,通常建议让您的用户知道。专业提示:您永远不应该鼓励您的用户使用过时的浏览器,或者积极支持它们。虽然您可能已经采取了所有必要的预防措施,但其他Web开发人员可能没有。鼓励用户使用主要浏览器支持的更新版本。供应商或标准错误?普通用户通过第三方客户端(浏览器)访问我们的应用程序这一事实增加了另一层间接性:浏览器本身可能存在安全漏洞。“供应商通常会向能够发现浏览器本身漏洞的安全研究人员提供奖励(即漏洞赏金)。这些错误与您的实现无关,而是与浏览器本身处理安全性的方式有关。例如,Chrome赏金计划让安全工程师与Chrome安全团队联系,报告他们发现的漏洞。如果这些漏洞得到确认,就会发布补丁,通常会向公众发布安全建议通知,并且研究人员会从该程序中获得奖励(通常是经济上的)。像谷歌这样的公司在他们的漏洞赏金计划中投入了相对大量的资金,这使他们能够通过承诺如果发现他们的应用程序存在任何问题就获得经济利益来吸引研究人员。在漏洞赏金计划中,每个人都是赢家:供应商寻求提高其软件的安全能力,而研究人员则因此获得报酬。我们稍后会讨论这些计划,因为我相信漏洞赏金计划应该在安全领域有自己的部分。JakeArchibald是Google的一名开发人员,他最近发现了一个影响多个浏览器的漏洞。他在一篇有趣的博客文章中记录了他的努力、他如何接触不同的供应商以及他们的回应,我建议您阅读这篇文章。开发人员的浏览器现在我们应该了解一个非常简单但相当重要的概念:浏览器只是为普通网络冲浪者构建的HTTP客户端。它们肯定比平台的纯HTTP客户端更强大(例如考虑NodeJS的require('HTTP')),但归根结底,它们“只是”更简单的HTTP客户端的自然演变。作为开发人员,我们选择的HTTP客户端可能是DanielStenberg的cURL,它是Web开发人员每天使用的最流行的软件程序之一。它允许我们通过从命令行发送HTTP请求来实时执行HTTP交换:$curl-Ilocalhost:8080HTTP/1.1200OKserver:ecstatic-2.2.1Content-Type:text/htmletag:"23724049-4096-"2018-07-20T11:20:35.526Z""last-modified:Fri,20Jul201811:20:35GMTcache-control:max-age=3600Date:Fri,20Jul201811:21:02GMTConnection:keep-alive在上面的例子中,我们在本地主机上:在8080/上请求了一个文档,本地服务器响应成功。在这里,我们不在命令行上显示响应主体,而是使用-I标志,它告诉cURL我们只对响应标头感兴趣。更进一步,我们可以指示cURL显示更多信息,包括它执行的实际请求,以更好地了解整个HTTP交换。使用的选项是-v(verbose):$curl-I-vlocalhost:8080*RebuiltURLto:localhost:8080/*Trying127.0.0.1...*Connectedtolocalhost(127.0.0.1)port8080(#0)>HEAD/HTTP/1.1>Host:localhost:8080>User-Agent:curl/7.47.0>Accept:*/*>
