# 第七章 為 Cookie 服務和其他首部字段 > 作者：肖鵬-SpiritLing 時間：2019-01-30 > 包含 為 `Cookie` 服務的首部字段和其他首部字段 ## 第一節 為 Cookie 服務的首部字段 管理服務器與客戶端之間狀態的 `Cookie` ，雖然沒有被編入標準化 HTTP/1.1 的 RFC2616 中，但在 Web 網站方面得到廣泛的應用。 `Cookie` 的工作機制是用戶識別及狀態管理。web 網站為了管理用戶的狀態會通過 web 游覽器，把一些數據臨時寫入用戶的計算機內。接著當用戶訪問該 web 網站時，可通過通信方式取回之前存放的 `Cookie` 。 調用 `Cookie` 時，由于可校驗 `Cookie` 的有效期，以及發送方的域、路徑、協議等信息，所以正規發布的 `Cookie` 內的數據不會因來自其他 web 站點和攻擊者的攻擊而泄露。 在目前使用最廣泛的 `Cookie` 標準卻不是 RFC 中定義的任何一個。而是在網景公司指定的標準上進行擴展后的產物。 下面是與 `Cookie` 有關的首部字段 | 首部字段名 | 說明 | 首部類型 | | --- | --- | --- | | Set-Cookie | 開始狀態管理所使用的 `Cookie` 信息 | 響應首部字段 | | Cookie | 服務器接收到的 `Cookie` 信息 | 請求首部字段 | ### 第一小節 Set-Cookie 字段 ```http Set-Cookie: status-enable; expires=Tue, 05 Jul 2018 02:01:22 GMT; path=/; domain=.example.com; ``` 當服務器準備開始管理客戶端的狀態時，會事先告知各種信息。下面表格列舉了 `Set-Cookie` 的字段值。 | 屬性 | 說明 | | --- | --- | | NAME=VALUE | 賦予 `Cookie` 的名稱和其值（必須項） | | expires=DATE | `Cookie` 的有效期（若不明確指定則默認為游覽器關閉前為止） | | path=PATH | 將服務器上的文件目錄作為 `Cookie` 的適用對象（若不指定則默認文檔所在的文件目錄） | | domain=域名 | 作為 `Cookie` 適用對象的域名（若不指定則默認為創建 `Cookie` 的服務器域名） | | Secure | 僅在 HTTPS 安全通信時才會發送 `Cookie` | | HttpOnly | 加以限制，使 `Cookie` 不能被 JavaScript 腳本訪問 | * **expires 屬性** `Cookie` 的 `expires` 屬性指定游覽器可發送 `Cookie` 的有效期。 當省略 `expires` 屬性時，其有效期僅限于維持游覽器會話（Session）時間段內。這通常限于游覽器應用程序被關閉之前。 另外，一旦 `Cookie` 從服務器端發送至客戶端，服務器端就不存在可以顯示刪除 `Cookie` 的方法。但可以通過覆蓋已過期的 `Cookie` ，實現對客戶端 `Cookie` 的實質性刪除操作。 * **path 屬性** `Cookie` 的 `path` 屬性可用于限制指定 `Cookie` 的發送范圍的文件目錄。不過另有辦法避開這項限制，看來對其作為安全機制的效果不能報有期待。 * **domain 屬性** 通過 `Cookie` 的 `domain` 屬性指定的域名可做到與結尾匹配一致。比如，當指定 `example.com` 后，除 `example.com` 以外，`www.example.com` 或 `www2.example.com` 等都可以發送 `Cookie` 。 因此，除了針對具體指定的多個域發送 `Cookie` 之外，不指定 `domain` 屬性顯得更安全。 * **secure 屬性** `Cookie` 的 `secure` 屬性用于限制 web 頁面僅在 HTTPS 安全連接時，才可以發送 `Cookie` 。 發送 `Cookie` 時，指定 `secure` 屬性的方法如下所示。 ```http Set-Cokkie: name=VALUE; secure ``` 以上例子僅當在 `https://www........`（HTTPS）安全連接的情況下才會進行 `Cookie` 的回收，也就是說，即使域名相同，`http://www......`（HTTP）也不會發生 `Cookie` 的回收行為。 當省略 `secure` 屬性時，不論 HTTP 還是 HTTPS ，都會對 `Cookie` 進行回收。 * **HttpOnly 屬性** `Cookie` 的 `HttpOnly` 屬性是 `Cookie` 的擴展功能，它使 JavaScript 腳本無法獲得 `Cookie` 。其主要目的為防止跨站腳本攻擊（Cross-sitescripting，XSS）對 `Cookie` 的信息竊取。 發送指定 `HttpOnly` 屬性的 `Cookie` 的方法如下所示。 ```http Set-Cookie: name=value; HttpOnly ``` 通過上述設置，通常從 web 頁面內還可以對 `Cookie` 進行讀取操作。但使用 JavaScript 的 document.cookie 就無法讀取附加 `HttpOnly` 屬性后的 `Cookie` 的內容了。因此，也就無法在 XSS 中利用 JavaScript 劫持 `Cookie` 了。 雖然是獨立的擴展功能，但 Internet Explorer 6 SP1 以上版本等當下的主流游覽器都已經支持該擴展了。另外順帶一提，該擴展并非是為了防止 XSS 而開發的。 ### 第二小節 Cookie 字段 ```http Cookie: status=enable ``` 首部字段 `Cookie` 會告知服務器，當客戶端想獲得 HTTP 狀態管理支持時，就會在請求中包含從服務器接受到的 `Cookie` 。接受到多個 `Cookie` 時，同樣可以以多個 `Cookie` 形式發送。 ## 第二節 其他首部字段 HTTP 首部字段是可以自行擴展的。所以在 Web 服務器和游覽器的應用上，會出現各種非標準的首部字段。 下面是一些比較常用的首部字段/ * X-Frame-Options * X-XSS-Protection * DNT * P3P ### 第一小節 X-Frame-Options 字段 ```http X-Frame-Options: DENY ``` 首部字段 `X-Frame-Options` 屬于 HTTP 響應首部，用于控制網站內容在其他 web 網站的 Frame 標簽內顯示問題。其主要目的是為了防止點擊劫持（clickjacking）攻擊。 首部字段 `X-Frame-Options` 有以下兩個可指定的字段值。 * **DENY** 拒絕 * **SAMEORIGIN** 僅同源域名下的頁面（Top-level-browsing-context）匹配時許可。 支持該首部字段的游覽器有：Internet Explorer 8、Firefox 3.6.9+、Chrome 4.1.249.1042+、Safari 4+ 和 Opera 10.50+ 等。現在主流的游覽器都已經支持。 能在所有的 web 服務端預先設定好 `X-Frame-Options` 字段值是最理想的狀態。 當然版本不支持的以及其不放心時可以參考[這篇文章](https://www.cnblogs.com/bella-lin/p/9266994.html) ### 第二小節 X-XSS-Protection 字段 ```http X-XSS-Protection: 1 ``` 首部字段 `X-XSS-Protection` 屬于 HTTP 響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用于控制游覽器 `XSS` 防護機制的開關。 首部字段 `X-XSS-Protection` 可指定的字段值如下： * 0：將 `XSS` 過濾設置成無效狀態 * 1：將 `XSS` 過濾設置成有效狀態 ### 第三小節 DNT 字段 ```http DNT: 1 ``` 首部字段 `DNT` 屬于HTTP 請求首部，其中 `DNT` 是 `Do Not Track` 的簡稱，意為拒絕個人信息被手機，是表示拒絕被精準廣告追蹤的一種方法。 首部字段 `DNT` 可指定的字段值如下。 * 0：同意被追蹤 * 1：拒絕被追蹤 由于首部字段 `DNT` 的功能具備有效性，所以 web 服務器需要對 `DNT` 做出對應的支持。 ### 第四小節 P3P字段 ```http P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND UNI COM NAV INT" ``` 首部字段 `P3P` 屬于HTTP響應首部，通過利用P3P ( The Platform for Privacy Preferences,在線隱私偏好平臺)技術，可以讓Web網站上 的個人隱私變成種僅供程序可理解的形式， 以達到保護用戶隱私的 目的。 要進行 `P3P`的設定，需按以下步驟進行。 * 步驟一：創建 `P3P` 隱私 * 步驟二：創建 `P3P` 隱私對照文件后，保存命名在 `/w3c/p3p.xml` * 步驟三：從 `P3P` 隱私中新建 `Compact policies` 后，輸出到 HTTP 響應中 關于 `P3P` 的詳細規范請查看下面鏈接。 https://www.w3.org/TR/P3P/ > 作者：肖鵬-SpiritLing 時間：2019-01-30