HTTP cookie 詳細介紹
HTTP Cookie:
Cookie通常也叫做網站cookie,瀏覽器cookie或者httpcookie,是儲存在使用者瀏覽器端的，並在發出http請求時會預設攜帶的一段文字片段。它可以用來做使用者認證，伺服器校驗等通過文字資料可以處理的問題。
Cookie不是軟體，所以它不能被攜帶病毒，不能執行惡意指令碼，不能在使用者主機上安裝惡意軟體。但它們可以被間諜軟體用來跟蹤使用者的瀏覽行為。所以近年來，已經有是歐洲和美國的一些律師以保護使用者隱私之名對cookie的種植宣戰了。更嚴重的是，黑客可以通過偷取Cookie獲取受害者的帳號控制權。
1.Cookie的歷史
a.概念的產生：
Cookie原名是”magic cookie”,是用來描述程式接受並原樣發出的一組資料。（這裡可以拿生活中的情況舉例：比如說當我們在商場試穿衣服的時候，在試衣間門口店員會給你一個號碼牌表示你試穿衣服的件數。當你出來的時候，店員會檢查下拿著這個牌子和對應的衣服。）這個概念是一直就存在於計算機領域的.直到1994年，網景公司前僱員Lou Moutulli將magic cookie的概念引入到web,賦予了web記憶。
賣個關子。請大家設想一下，沒有cookie的網際網路將是一副什麼的場景。
1.每次訪問都像第一次訪問一樣，無法判斷使用者是否訪問過
2.任何的購買等互動、驗證行為都必須在一次訪問中完成
3.無任何記憶，均需要使用者重新點選或填寫
大家說的很好，在1994年6月的某天，24歲的，網景公司第九位工程師，moutulli，坐在鍵盤前，遇到和大家描述的一模一樣的困難，他憑藉著他高超的程式設計技能和思想設計出了一個五頁紙的方案來解決這些棘手的問題，這個五頁紙後來也就演變成了最初版本的Netscape Cookie規範。五頁紙的核心觀點就是在使用者的電腦上存放一個小的檔案來記錄使用者對網站的訪問情況。moutulli將其簡稱為cookie. 同年10月，Netscape瀏覽器就率先支援了Cookies，並在netscape官網上做了檢查統計使用者是否訪問過的功能。次年10月，微軟的IE2也開始支援Cookie。當然，微軟是要交“保護費”了，因為moutulli在1995年申請了專利，並在1998年獲得專利授權。整體來說，Cookie的引入對於網際網路來說，這是一個劃時代的轉折點，它將零散的訪問，無狀態的請求變得有序並富有記憶，給網際網路增添了更有趣味性的玩法。
b.隱私風險
1.1995年Q1，當時Cookie沒有受到廣泛的關注。但cookie不在使用者知曉的情況下可以預設種植引來人們的擔心。
2.1996年2月，金融時報（ft中文網就是翻譯此雜誌）釋出關於cookie的文章對公眾進行了認知的普及，並引起了媒體的廣泛關注和討論，尤其是在潛在的隱私風險上。
3.1996年-1997年，Cookie在美國聯邦貿易委員會聽證會持續討論。
c.規範的發展：
1.1994年，Montulli,聯合JohnGiannandrea寫了Netscape cookie規範。
2.1995年4月，在www-talk郵件組第一次開始討論正式統一的Cookie規範，並在IETF(Internet Engineering Task Force，網際網路工程任務組，主要目標是協調製定網際網路標準，幾乎所有重要的網路底層協議都是有IETF制定,EG:TCP,IP,HTTP and so on,可以毫不誇張的說，沒有IETF就沒有今天的網際網路，今年是IETF成立25週年，老外有很多文章專門回顧總結其光輝成就。IETF是由網民自發組織，自我管理的，任何人都和可以參加的，完全民主平等的，無投票機制的，充分體現了自由、開放、合作、共享的精神)裡成立了特別工作小組。兩種HTTP Cookie的方案被提議。
3.1996年2月，IETF認定第三方Cookie存在重大隱私風險。
4.1997年2月，IETF最終釋出了Cookie規範,RFC 2109,其中指出不允許設定第三方cookie或者不能預設支援第三方cookie
5.2000年10月，RFC 2965釋出，主要是由於廣告在RFC2109釋出時已經廣泛使用第三方Cookie,所以關於第三方cookie部分是沒有被Netscape和IE所跟隨。
6.2011年4月，RFC 6265釋出。現實版使用的Cookie規範終於誕生了。
2.Cookie的類別
a.Session Cookie
這個型別的cookie只在會話期間內有效，即當關閉瀏覽器的時候，它會被瀏覽器刪除。設定session cookie的辦法是：在建立cookie不設定Expires即可。
b.Persistent Cookie
持久型cookie顧名思義就是會長期在使用者會話中生效。當你設定cookie的屬性Max-Age為1個月的話，那麼在這個月裡每個相關URL的http請求中都會帶有這個cookie。所以它可以記錄很多使用者初始化或自定義化的資訊，比如什麼時候第一次登入及弱登入態等。
c.Secure cookie
安全cookie是在https訪問下的cookie形態，以確保cookie在從客戶端傳遞到Server的過程中始終加密的。這樣做大大的降低的cookie內容直接暴露在黑客面前及被盜取的概率。
d.HttpOnly Cookie
目前主流的瀏覽器已經都支援了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支援httponly的瀏覽器上，設定成httponly的cookie只能在http(https)請求上傳遞。也就是說httponlycookie對客戶端指令碼語言(javascript)無效，從而避免了跨站攻擊時JS偷取cookie的情況。當你使用javascript在設定同樣名字的cookie時，只有原來的httponly值會傳送到伺服器。
e.3rd-party cookie
第一方cookie是cookie種植在瀏覽器位址列的域名或子域名下的。第三方cookie則是種植在不同於瀏覽器位址列的域名下。例如：使用者訪問a.com時，在ad.google.com設定了個cookie，在訪問b.com的時候，也在ad.google.com設定了一個cookie。這種場景經常出現在google adsense，阿里媽媽之類的廣告服務商。廣告商就可以採集使用者的一些習慣和訪問歷史。
f.Super Cookie
超級cookie是設定公共域名字首上的cookie。通常a.b.com的cookie可以設定在a.b.com和b.com，而不允許設定在.com上，但是很不幸的是歷史上一些老版本的瀏覽器因為對新增字尾過濾不足導致過超級cookie的產生。
g.Zombie Cookie
殭屍cookie是指那些刪不掉的，刪掉會自動重建的cookie。殭屍cookie是依賴於其他的本地儲存方法，例如flash的share object,html5的local storages等，當用戶刪除cookie後，自動從其他本地儲存裡讀取出cookie的備份，並重新種植。
3.Cookie用途
a.會話管理
1.記錄使用者的登入狀態是cookie最常用的用途。通常web伺服器會在使用者登入成功後下發一個簽名來標記session的有效性，這樣免去了使用者多次認證和登入網站。
2.記錄使用者的訪問狀態，例如導航啊，使用者的註冊流程啊。
b.個性化資訊
1.Cookie也經常用來記憶使用者相關的資訊，以方便使用者在使用和自己相關的站點服務。例如：ptlogin會記憶上一次登入的使用者的QQ號碼，這樣在下次登入的時候會預設填寫好這個QQ號碼。
2.Cookie也被用來記憶使用者自定義的一些功能。使用者在設定自定義特徵的時候，僅僅是儲存在使用者的瀏覽器中，在下一次訪問的時候伺服器會根據使用者本地的cookie來表現使用者的設定。例如google將搜尋設定（使用語言、每頁的條數，以及開啟搜尋結果的方式等等）儲存在一個COOKIE裡。
c.記錄使用者的行為
最典型的是公司的TCSS系統。它使用Cookie來記錄使用者的點選流和某個產品或商業行為的操作率和流失率。當然功能可以通過IP或http header中的referrer實現，但是Cookie更精準一些。
4. Cookie的實現
Cookie是web server下發給瀏覽器的任意的一段文字，在後續的http 請求中，瀏覽器會將cookie帶回給Web Server。同時在瀏覽器允許指令碼執行的情況下，Cookie是可以被JavaScript等指令碼設定的。
a. 如何種植Cookie
http方式:以訪問http://www.webryan.net/index.php為例
Step1.客戶端發起http請求到Server
GET /index.php HTTP/1.1
Host: www.webryan.net
(這裡是省去了User-Agent,Accept等欄位)
Step2. 伺服器返回http response,其中可以包含Cookie設定
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09Jun 2021 10:18:14 GMT
(content of page)
Step3. 後續訪問webryan.net的相關頁面
GET /spec.html HTTP/1.1
Host: www.webryan.net
Cookie: name=value; name2=value2
Accept: */*
需要修改cookie的值的話，只需要Set-Cookie: name=newvalue即可，瀏覽器會用新的值將舊的替換掉。
指令碼方式種植 Cookie：
JavaScript或類似的寄宿在瀏覽器中的指令碼語言也可以設定Cookie。在JavaScript裡，可以通過document.cookie物件實現。例如：
document.cookie = “key=newvalue”;
b. Cookie屬性
除了name=value對以外，我們還可以設定Cookie其他屬性以支援更豐富的Cookie需求，這些屬性通常是瀏覽器用來判斷如何對待cookie，何時刪除、遮蔽或者如何傳送name-value對給Server。也就是說無論我們設定了某個cookie的多少屬性，這些Cookie屬性是不會被瀏覽器傳送回給Server的。
a) Domain and Path
作用：定義Cookie的生效作用域，只有當域名和路徑同時滿足的時候，瀏覽器才會將Cookie傳送給Server。如果沒有設定Domain和Path的話，他們會被預設為當前請求頁面對應值。舉例如下：
提問下：第一個和第三個Cookie有啥不一樣??
結論：瀏覽器優先匹配domain,而對於Path欄位則是以匹配的方式進行判斷。
對於 1.http://docs.foo.com/accounts/index.html
2.http://docs.foo.com/accountstest.html
1.會帶上Cookie1,2,3; 2會帶上1，2
b) Expires and Max-Age
作用：設定瀏覽器何時刪除Cookie
Expires的規定格式是：“Wdy,DD-Mon-YYYY HH:MM:SS GMT”。
相對於Expires的精準的時間設定，在RFC 2965中規範提供了一個替代方案：Max-Age:seconds,來設定cookie在設定後多長秒後失效。
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg;expires=Tue, 15-Jan-2013 21:47:38 GMT; path=/; domain=.foo.com; httponly
Set-Cookie: made_write_conn=1295214458;path=/; domain=.foo.com
Set-Cookie: reg_fb_gate=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.foo.com; httponly
第一個Cookie: 過期時間是2013年1月15日的精確時間；
第二個：沒有設定過期時間，為Session cookie.
第三個：刪除Cookie
C) Secure and HttpOnly
作用：設定Cookie的安全屬性
特質：Secure和HttpOnly都是沒有value欄位的。
Secure欄位告訴瀏覽器在https通道時，對Cookie進行安全加密，這樣即時有黑客監聽也無法獲取cookie內容。
HttpOnly欄位告訴瀏覽器，只有在HTTP協議下使用，對瀏覽器的指令碼不可見，所以跨站指令碼攻擊時也不會被竊取。從前面例子可以看到Google和Facebook都在使用HttpOnly的Cookie。
5. 瀏覽器相關
a) Cookie規範規定瀏覽器最少支援300個cookie，每個cookie 4kb；每個域名最少20個cookie。
b) 瀏覽器都支援刪除和禁用cookie
c) 在瀏覽器位址列輸入：javascript:alert(document.cookie)可以看到所有cookie
d) 預設情況下，IE瀏覽器僅支援設定有P3P “CP” (CompactPolicy) 標記的第三方Cookie.
測試方法：
javascript:for(vari=0;i<100;i++){document.cookie=’cookiename’+i+’=1aaa;’}document.cookie=’test=asdf;’;alert(document.cookie)
測試結論：ie8:每個域名50個，firefox:每個域名150個；chrome:每個域名170個；ie6、ie7:20個
測試方法：
javascript:vararr=[],i=5112;while(i){i–;arr.push(‘i’)}document.cookie=’test=’+arr.join(”)+’;’;alert($.cookie.get(‘test’).length)
測試結論：
ie8:5112+5 = 5117
但最多10個大欄位。欄位內容多了的話，導致伺服器無法響應。
6.Cookie竊取及會話劫持(hijacking)
相對很多Session驗證方法的缺點和不足，大多數網站都是把Cookie當作使用者的唯一標識。在這種情況下，黑客以可以通過竊取使用者的cookie來模擬使用者的請求行為，但對於伺服器來說是無法辨別到底是來自使用者還是黑客的。
下面給出Cookie作為使用者標識的風險和安全隱患：
a. 網路監聽
在網路上傳輸的資料都是會被監聽獲取的，尤其是在公共的、非加密的網路環境（free wifi）。這些資料也包括常規的http（非https加密通道）所有session，當然也就包括了HTTP 會話裡的Cookie。當黑客拿到明文的cookie之後就可以模擬使用者操作，比如改密碼、消費等行為。
解決這個問題的最根本方法是採取https協議，通過SSL通道對內容及cookie進行加密。此外還有一些二次保護的方法可以作為過渡和折中。
b. DNS cache異常及其他
通過DNS cache或者DNS服務商的一些漏洞問題（www.baidu.com），黑客可以通過將www.baidu.com的子域名hack.www.baidu.com指向到黑客自己的IP。這樣黑客就可以通過方式http://hack.www.baidu.com/a.png圖片到公共環境，從而可以獲取到baidu.com下的所有cookie，包括設定了HttpOnly屬性的Cookie。
解決辦法：1.減少dns無效配置 2.ISP服務商加強自我安全管理。3.通過HTTPS請求對請求進行加密和授權，這樣黑客很難從憑證管理中心獲得認證，那麼使用者在操作的時候會收到明顯的提示。
c. 跨站指令碼XSS—竊取Cookie
由於JavaScript等指令碼語言可以讀取頁面文件內的Cookie值，同時又可以向任意伺服器發出任意的請求。綜合起來，黑客可以通過指令碼將當前文件下的cookie據為己有。如果黑客使用的地址是https://attacker.com/stole.cgi,那麼Secure Cookie也將以明文的方式傳送個attacker.com.
跨站指令碼是web安全永久不變的話題。Web開發者有責任去過濾掉惡意程式碼。同時，HttpOnlyCookies不可以被客戶端指令碼讀取，這就大大降低了Cookie被盜取的風險。
d.跨站指令碼XSS—hijacking
當黑客可以在www.test.com上插入一段JS指令碼的話，那麼沒有禁用JS的使用者很輕易的會收到hijacking攻擊。黑客利用使用者的瀏覽器來發出HTTP請求到test.com本身，所以與使用者相關的所有cookie都會存在（包括HttpOnly和Secure Cookie）。例如：人人網發生的分享蠕蟲。
對於這種攻擊，除了避免跨站指令碼漏洞以外，可以採取驗證碼的方式進行一定程度上的規避。
e.跨站指令碼XSS—代理請求
老版本的瀏覽器允許使用者使用XMLHttpRequest發出代理請求，黑客可以通過設定代理將本地的cookie全量的發給代理伺服器，再從代理伺服器轉發給原始伺服器。當然這是很快被禁止了。
f.跨站請求偽造—CSRF
CSRF主要是黑客將偽造的請求URL放到一個圖片或者其他靜態資源裡，這種成本極低，且傳播性和形象力非常大。
舉例：Qzone的簽名的修改地址是：
http://qzone.qq.com/cgi-bin/modify?nick=123
那麼黑客將其並放到流量很大的論壇或者部落格裡。那麼很多人就在不知情的情況下就執行了某些操作。
7. Cookie的缺點和不足
a) 被討論最多的就是隱私問題
b) Cookie引入的各種安全問題
c) 與REST軟體架構相背離。
d) 狀態不一致，後退導致cookie不會重置。
c) 過多使用到是HTTP請求流量浪費
文章來源
http://m.blog.csdn.net/article/details?id=22174151
</div>
</div>
HTTP Cookie:
Cookie通常也叫做網站cookie,瀏覽器cookie或者httpcookie,是儲存在使用者瀏覽器端的，並在發出http請求時會預設攜帶的一段文字片段。它可以用來做使用者認證，伺服器校驗等通過文字資料可以處理的問題。
Cookie不是軟體，所以它不能被攜帶病毒，不能執行惡意指令碼，不能在使用者主機上安裝惡意軟體。但它們可以被間諜軟體用來跟蹤使用者的瀏覽行為。所以近年來，已經有是歐洲和美國的一些律師以保護使用者隱私之名對cookie的種植宣戰了。更嚴重的是，黑客可以通過偷取Cookie獲取受害者的帳號控制權。
1.Cookie的歷史
a.概念的產生：
Cookie原名是”magic cookie”,是用來描述程式接受並原樣發出的一組資料。（這裡可以拿生活中的情況舉例：比如說當我們在商場試穿衣服的時候，在試衣間門口店員會給你一個號碼牌表示你試穿衣服的件數。當你出來的時候，店員會檢查下拿著這個牌子和對應的衣服。）這個概念是一直就存在於計算機領域的.直到1994年，網景公司前僱員Lou Moutulli將magic cookie的概念引入到web,賦予了web記憶。
賣個關子。請大家設想一下，沒有cookie的網際網路將是一副什麼的場景。
1.每次訪問都像第一次訪問一樣，無法判斷使用者是否訪問過
2.任何的購買等互動、驗證行為都必須在一次訪問中完成
3.無任何記憶，均需要使用者重新點選或填寫
大家說的很好，在1994年6月的某天，24歲的，網景公司第九位工程師，moutulli，坐在鍵盤前，遇到和大家描述的一模一樣的困難，他憑藉著他高超的程式設計技能和思想設計出了一個五頁紙的方案來解決這些棘手的問題，這個五頁紙後來也就演變成了最初版本的Netscape Cookie規範。五頁紙的核心觀點就是在使用者的電腦上存放一個小的檔案來記錄使用者對網站的訪問情況。moutulli將其簡稱為cookie. 同年10月，Netscape瀏覽器就率先支援了Cookies，並在netscape官網上做了檢查統計使用者是否訪問過的功能。次年10月，微軟的IE2也開始支援Cookie。當然，微軟是要交“保護費”了，因為moutulli在1995年申請了專利，並在1998年獲得專利授權。整體來說，Cookie的引入對於網際網路來說，這是一個劃時代的轉折點，它將零散的訪問，無狀態的請求變得有序並富有記憶，給網際網路增添了更有趣味性的玩法。
b.隱私風險
1.1995年Q1，當時Cookie沒有受到廣泛的關注。但cookie不在使用者知曉的情況下可以預設種植引來人們的擔心。
2.1996年2月，金融時報（ft中文網就是翻譯此雜誌）釋出關於cookie的文章對公眾進行了認知的普及，並引起了媒體的廣泛關注和討論，尤其是在潛在的隱私風險上。
3.1996年-1997年，Cookie在美國聯邦貿易委員會聽證會持續討論。
c.規範的發展：
1.1994年，Montulli,聯合JohnGiannandrea寫了Netscape cookie規範。
2.1995年4月，在www-talk郵件組第一次開始討論正式統一的Cookie規範，並在IETF(Internet Engineering Task Force，網際網路工程任務組，主要目標是協調製定網際網路標準，幾乎所有重要的網路底層協議都是有IETF制定,EG:TCP,IP,HTTP and so on,可以毫不誇張的說，沒有IETF就沒有今天的網際網路，今年是IETF成立25週年，老外有很多文章專門回顧總結其光輝成就。IETF是由網民自發組織，自我管理的，任何人都和可以參加的，完全民主平等的，無投票機制的，充分體現了自由、開放、合作、共享的精神)裡成立了特別工作小組。兩種HTTP Cookie的方案被提議。
3.1996年2月，IETF認定第三方Cookie存在重大隱私風險。
4.1997年2月，IETF最終釋出了Cookie規範,RFC 2109,其中指出不允許設定第三方cookie或者不能預設支援第三方cookie
5.2000年10月，RFC 2965釋出，主要是由於廣告在RFC2109釋出時已經廣泛使用第三方Cookie,所以關於第三方cookie部分是沒有被Netscape和IE所跟隨。
6.2011年4月，RFC 6265釋出。現實版使用的Cookie規範終於誕生了。
2.Cookie的類別
a.Session Cookie
這個型別的cookie只在會話期間內有效，即當關閉瀏覽器的時候，它會被瀏覽器刪除。設定session cookie的辦法是：在建立cookie不設定Expires即可。
b.Persistent Cookie
持久型cookie顧名思義就是會長期在使用者會話中生效。當你設定cookie的屬性Max-Age為1個月的話，那麼在這個月裡每個相關URL的http請求中都會帶有這個cookie。所以它可以記錄很多使用者初始化或自定義化的資訊，比如什麼時候第一次登入及弱登入態等。
c.Secure cookie
安全cookie是在https訪問下的cookie形態，以確保cookie在從客戶端傳遞到Server的過程中始終加密的。這樣做大大的降低的cookie內容直接暴露在黑客面前及被盜取的概率。
d.HttpOnly Cookie
目前主流的瀏覽器已經都支援了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支援httponly的瀏覽器上，設定成httponly的cookie只能在http(https)請求上傳遞。也就是說httponlycookie對客戶端指令碼語言(javascript)無效，從而避免了跨站攻擊時JS偷取cookie的情況。當你使用javascript在設定同樣名字的cookie時，只有原來的httponly值會傳送到伺服器。
e.3rd-party cookie
第一方cookie是cookie種植在瀏覽器位址列的域名或子域名下的。第三方cookie則是種植在不同於瀏覽器位址列的域名下。例如：使用者訪問a.com時，在ad.google.com設定了個cookie，在訪問b.com的時候，也在ad.google.com設定了一個cookie。這種場景經常出現在google adsense，阿里媽媽之類的廣告服務商。廣告商就可以採集使用者的一些習慣和訪問歷史。
f.Super Cookie
超級cookie是設定公共域名字首上的cookie。通常a.b.com的cookie可以設定在a.b.com和b.com，而不允許設定在.com上，但是很不幸的是歷史上一些老版本的瀏覽器因為對新增字尾過濾不足導致過超級cookie的產生。
g.Zombie Cookie
殭屍cookie是指那些刪不掉的，刪掉會自動重建的cookie。殭屍cookie是依賴於其他的本地儲存方法，例如flash的share object,html5的local storages等，當用戶刪除cookie後，自動從其他本地儲存裡讀取出cookie的備份，並重新種植。
3.Cookie用途
a.會話管理
1.記錄使用者的登入狀態是cookie最常用的用途。通常web伺服器會在使用者登入成功後下發一個簽名來標記session的有效性，這樣免去了使用者多次認證和登入網站。
2.記錄使用者的訪問狀態，例如導航啊，使用者的註冊流程啊。
b.個性化資訊
1.Cookie也經常用來記憶使用者相關的資訊，以方便使用者在使用和自己相關的站點服務。例如：ptlogin會記憶上一次登入的使用者的QQ號碼，這樣在下次登入的時候會預設填寫好這個QQ號碼。
2.Cookie也被用來記憶使用者自定義的一些功能。使用者在設定自定義特徵的時候，僅僅是儲存在使用者的瀏覽器中，在下一次訪問的時候伺服器會根據使用者本地的cookie來表現使用者的設定。例如google將搜尋設定（使用語言、每頁的條數，以及開啟搜尋結果的方式等等）儲存在一個COOKIE裡。
c.記錄使用者的行為
最典型的是公司的TCSS系統。它使用Cookie來記錄使用者的點選流和某個產品或商業行為的操作率和流失率。當然功能可以通過IP或http header中的referrer實現，但是Cookie更精準一些。
4. Cookie的實現
Cookie是web server下發給瀏覽器的任意的一段文字，在後續的http 請求中，瀏覽器會將cookie帶回給Web Server。同時在瀏覽器允許指令碼執行的情況下，Cookie是可以被JavaScript等指令碼設定的。
a. 如何種植Cookie
http方式:以訪問http://www.webryan.net/index.php為例
Step1.客戶端發起http請求到Server
GET /index.php HTTP/1.1
Host: www.webryan.net
(這裡是省去了User-Agent,Accept等欄位)
Step2. 伺服器返回http response,其中可以包含Cookie設定
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed, 09Jun 2021 10:18:14 GMT
(content of page)
Step3. 後續訪問webryan.net的相關頁面
GET /spec.html HTTP/1.1
Host: www.webryan.net
Cookie: name=value; name2=value2
Accept: */*
需要修改cookie的值的話，只需要Set-Cookie: name=newvalue即可，瀏覽器會用新的值將舊的替換掉。
指令碼方式種植 Cookie：
JavaScript或類似的寄宿在瀏覽器中的指令碼語言也可以設定Cookie。在JavaScript裡，可以通過document.cookie物件實現。例如：
document.cookie = “key=newvalue”;
b. Cookie屬性
除了name=value對以外，我們還可以設定Cookie其他屬性以支援更豐富的Cookie需求，這些屬性通常是瀏覽器用來判斷如何對待cookie，何時刪除、遮蔽或者如何傳送name-value對給Server。也就是說無論我們設定了某個cookie的多少屬性，這些Cookie屬性是不會被瀏覽器傳送回給Server的。
a) Domain and Path
作用：定義Cookie的生效作用域，只有當域名和路徑同時滿足的時候，瀏覽器才會將Cookie傳送給Server。如果沒有設定Domain和Path的話，他們會被預設為當前請求頁面對應值。舉例如下：
提問下：第一個和第三個Cookie有啥不一樣??
結論：瀏覽器優先匹配domain,而對於Path欄位則是以匹配的方式進行判斷。
對於 1.http://docs.foo.com/accounts/index.html
2.http://docs.foo.com/accountstest.html
1.會帶上Cookie1,2,3; 2會帶上1，2
b) Expires and Max-Age
作用：設定瀏覽器何時刪除Cookie
Expires的規定格式是：“Wdy,DD-Mon-YYYY HH:MM:SS GMT”。
相對於Expires的精準的時間設定，在RFC 2965中規範提供了一個替代方案：Max-Age:seconds,來設定cookie在設定後多長秒後失效。
Set-Cookie: lu=Rg3vHJZnehYLjVg7qi3bZjzg;expires=Tue, 15-Jan-2013 21:47:38 GMT; path=/; domain=.foo.com; httponly
Set-Cookie: made_write_conn=1295214458;path=/; domain=.foo.com
Set-Cookie: reg_fb_gate=deleted;expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.foo.com; httponly
第一個Cookie: 過期時間是2013年1月15日的精確時間；
第二個：沒有設定過期時間，為Session cookie.
第三個：刪除Cookie
C) Secure and HttpOnly
作用：設定Cookie的安全屬性
特質：Secure和HttpOnly都是沒有value欄位的。
Secure欄位告訴瀏覽器在https通道時，對Cookie進行安全加密，這樣即時有黑客監聽也無法獲取cookie內容。
HttpOnly欄位告訴瀏覽器，只有在HTTP協議下使用，對瀏覽器的指令碼不可見，所以跨站指令碼攻擊時也不會被竊取。從前面例子可以看到Google和Facebook都在使用HttpOnly的Cookie。
5. 瀏覽器相關
a) Cookie規範規定瀏覽器最少支援300個cookie，每個cookie 4kb；每個域名最少20個cookie。
b) 瀏覽器都支援刪除和禁用cookie
c) 在瀏覽器位址列輸入：javascript:alert(document.cookie)可以看到所有cookie
d) 預設情況下，IE瀏覽器僅支援設定有P3P “CP” (CompactPolicy) 標記的第三方Cookie.
測試方法：
javascript:for(vari=0;i<100;i++){document.cookie=’cookiename’+i+’=1aaa;’}document.cookie=’test=asdf;’;alert(document.cookie)
測試結論：ie8:每個域名50個，firefox:每個域名150個；chrome:每個域名170個；ie6、ie7:20個
測試方法：
javascript:vararr=[],i=5112;while(i){i–;arr.push(‘i’)}document.cookie=’test=’+arr.join(”)+’;’;alert($.cookie.get(‘test’).length)
測試結論：
ie8:5112+5 = 5117
但最多10個大欄位。欄位內容多了的話，導致伺服器無法響應。
6.Cookie竊取及會話劫持(hijacking)
相對很多Session驗證方法的缺點和不足，大多數網站都是把Cookie當作使用者的唯一標識。在這種情況下，黑客以可以通過竊取使用者的cookie來模擬使用者的請求行為，但對於伺服器來說是無法辨別到底是來自使用者還是黑客的。
下面給出Cookie作為使用者標識的風險和安全隱患：
a. 網路監聽
在網路上傳輸的資料都是會被監聽獲取的，尤其是在公共的、非加密的網路環境（free wifi）。這些資料也包括常規的http（非https加密通道）所有session，當然也就包括了HTTP 會話裡的Cookie。當黑客拿到明文的cookie之後就可以模擬使用者操作，比如改密碼、消費等行為。
解決這個問題的最根本方法是採取https協議，通過SSL通道對內容及cookie進行加密。此外還有一些二次保護的方法可以作為過渡和折中。
b. DNS cache異常及其他
通過DNS cache或者DNS服務商的一些漏洞問題（www.baidu.com），黑客可以通過將www.baidu.com的子域名hack.www.baidu.com指向到黑客自己的IP。這樣黑客就可以通過方式http://hack.www.baidu.com/a.png圖片到公共環境，從而可以獲取到baidu.com下的所有cookie，包括設定了HttpOnly屬性的Cookie。
解決辦法：1.減少dns無效配置 2.ISP服務商加強自我安全管理。3.通過HTTPS請求對請求進行加密和授權，這樣黑客很難從憑證管理中心獲得認證，那麼使用者在操作的時候會收到明顯的提示。
c. 跨站指令碼XSS—竊取Cookie
由於JavaScript等指令碼語言可以讀取頁面文件內的Cookie值，同時又可以向任意伺服器發出任意的請求。綜合起來，黑客可以通過指令碼將當前文件下的cookie據為己有。如果黑客使用的地址是https://attacker.com/stole.cgi,那麼Secure Cookie也將以明文的方式傳送個attacker.com.
跨站指令碼是web安全永久不變的話題。Web開發者有責任去過濾掉惡意程式碼。同時，HttpOnlyCookies不可以被客戶端指令碼讀取，這就大大降低了Cookie被盜取的風險。
d.跨站指令碼XSS—hijacking
當黑客可以在www.test.com上插入一段JS指令碼的話，那麼沒有禁用JS的使用者很輕易的會收到hijacking攻擊。黑客利用使用者的瀏覽器來發出HTTP請求到test.com本身，所以與使用者相關的所有cookie都會存在（包括HttpOnly和Secure Cookie）。例如：人人網發生的分享蠕蟲。
對於這種攻擊，除了避免跨站指令碼漏洞以外，可以採取驗證碼的方式進行一定程度上的規避。
e.跨站指令碼XSS—代理請求
老版本的瀏覽器允許使用者使用XMLHttpRequest發出代理請求，黑客可以通過設定代理將本地的cookie全量的發給代理伺服器，再從代理伺服器轉發給原始伺服器。當然這是很快被禁止了。
f.跨站請求偽造—CSRF
CSRF主要是黑客將偽造的請求URL放到一個圖片或者其他靜態資源裡，這種成本極低，且傳播性和形象力非常大。
舉例：Qzone的簽名的修改地址是：
http://qzone.qq.com/cgi-bin/modify?nick=123
那麼黑客將其並放到流量很大的論壇或者部落格裡。那麼很多人就在不知情的情況下就執行了某些操作。
7. Cookie的缺點和不足
a) 被討論最多的就是隱私問題
b) Cookie引入的各種安全問題
c) 與REST軟體架構相背離。
d) 狀態不一致，後退導致cookie不會重置。
c) 過多使用到是HTTP請求流量浪費
文章來源
http://m.blog.csdn.net/article/details?id=22174151
</div>
</div>