隨著www服務的興起，越來越多的應用程式轉向了b/s結構，這樣只需要乙個瀏覽器就可以訪問各種各樣的web服務，但是這樣也越來越導致了越來越多的web安全問題。www服務依賴於http協議實現，http是無狀態的協議，所以為了在各個會話之間傳遞資訊，就不可避免地用到cookie或者session等技術來標記訪問者的狀態，而無論是cookie還是session，一般都是利用cookie來實現的(session其實是在瀏覽器的cookie裡帶了乙個token來標記，伺服器取得了這個token並且檢查合法性之後就把伺服器上儲存的對應的狀態和瀏覽器繫結)，這樣就不可避免地安全聚焦到了cookie上面，只要獲得這個cookie，就可以取得別人的身份，這對於入侵者是一件很美妙的事情，特別當獲得的cookie屬於管理員等高許可權身份者時，危害就更大了。在各種web安全問題裡，其中xss漏洞就因此顯得格外危險。
對於應用程式來說，一旦存在了xss漏洞就意味著別人可以在你的瀏覽器中執行任意的js指令碼，如果應用程式是開源的或者功能是公開的話，別人就可以利用ajax使用這些功能，但是過程往往很煩瑣，特別是想直接獲得別人身份做隨意瀏覽的話困難就更大。而對於不開源的應用程式，譬如某些大型站點的web後台(web2.0乙個顯著的特徵就是大量的互動，使用者往往需要跟後台的管理員互動，譬如bug匯報，或者資訊投遞等等)，儘管因為互動的存在可能存在跨站指令碼漏洞，但是因為對後台的不了解，無法構造完美的ajax**來利用，即使可以用js取得後台的**並回傳分析，但是過程同樣煩瑣而且不隱蔽。這個時候，利用xss漏洞獲得cookie或者session劫持就很有效了，具體分析應用程式的認證，然後使用某些技巧，甚至可以即使對方退出程式也一樣永久性獲得對方的身份。
那麼如何獲得cookie或者session劫持呢?在瀏覽器中的document物件中，就儲存了cookie的資訊，而利用js可以把這裡面的cookie給取出來，只要得到這個cookie就可以擁有別人的身份了。乙個很典型的xss攻擊語句如下：
一些應用程式考慮到這個問題所在，所以可能會採取瀏覽器繫結技術，譬如將cookie和瀏覽器的user-agent繫結，一旦發現修改就認為cookie失效。這種方法已經證明是無效的，因為當入侵者偷得cookie的同時他肯定已經同時獲得了user-agent。還有另外一種比較嚴格的是將cookie和remote-addr相繫結(其實就是和ip繫結，但是一些程式取得ip的方法有問題一樣導致饒過)，但是這樣就帶來很差的使用者體驗，更換ip是經常的事，譬如上班與家裡就是2個ip，所以這種方法往往也不給予採用。所以基於cookie的攻擊方式現在就非常流行，在一些web 2.0站點很容易就取到應用程式的管理員身份。
如何保障我們的敏感cookie安全呢?通過上面的分析，一般的cookie都是從document物件中獲得的，我們只要讓敏感cookies瀏覽器document中不可見就行了。很幸運，現在瀏覽器在設定cookie的時候一般都接受乙個叫做httponly的引數，跟domain等其他引數一樣，一旦這個httponly被設定，你在瀏覽器的document物件中就看不到cookie了，而瀏覽器在瀏覽的時候不受任何影響，因為cookie會被放在瀏覽器頭中傳送出去(包括ajax的時候)，應用程式也一般不會在js裡操作這些敏感cookie的，對於一些敏感的cookie我們採用httponly，對於一些需要在應用程式中用js操作的cookie我們就不予設定，這樣就保障了cookie資訊的安全也保證了應用。關於httponly說明可以參照
給瀏覽器設定cookie的頭如下：
以php為例，在php 5.2版本時就已經在setcookie函式加入了對httponly的支援，譬如：
setcookie("
abc","
test",
null
,null
,null
,null
,true);
就可以設定abc這個cookie，將其設定為httponly，document將不可見這個cookie。因為setcookie函式本質就是個header，所以一樣可以使用header來設定httponly。然後再使用document.cookie就可以看到已經取不到這個cookie了。我們用這種方法來保護利例如sessionid，如一些用於認證的auth-cookie，就不用擔心身份被人獲得了，這對於一些後台程式和webmail提公升安全性的意義是重大的。再次使用上面的攻擊手法時可以看到，已經不能獲取被我們設定為httponly的敏感cookie了。
但是，也可以看到httponly並不是萬能的，首先它並不能解決xss的問題，仍然不能抵制一些有耐心的黑客的攻擊，也不能防止入侵者做ajax提交，甚至一些基於xss的proxy也出現了，但是已經可以提高攻擊的門檻了，起碼xss攻擊不是每個指令碼小子都能完成的了，而且其他的那些攻擊手法因為一些環境和技術的限制，並不像cookie竊取這種手法一樣通用。
httponly也是可能利用一些漏洞或者配置bypass的，關鍵問題是只要能取到瀏覽器傳送的cookie頭就可以了。譬如以前出現的http trace攻擊就可以將你的header裡的cookie回顯出來，利用ajax或者flash就可以完成這種攻擊，這種手法也已經在ajax和flash中獲得修補。另外乙個關於配置或者應用程式上可能bypass的顯著例子就是phpinfo，大家知道phpinfo會將瀏覽器傳送的http頭回顯出來，其中就包括我們保護的auth資訊，而這個頁面經常存在在各種站點上，只要用ajax取phpinfo頁面，取出header頭對應的部分就可以獲得cookie了。一些應用程式的不完善也可能導致header頭的洩露，這種攻擊方式對於basic驗證保護的頁面一樣可以攻擊。
httponly在ie 6以上，firefox較新版本都得到了比較好的支援，並且在如hotmail等應用程式裡都有廣泛的使用，並且已經是取得了比較好的安全效果。
相關英文文章：httponly
相關博文：httpcookie.httponly vs cookie.httponly?(downmoon原創)
利用Httponly提公升應用程式安全性
隨著www服務的興起，越來越多的應用程式轉向了b s結構，這樣只需要乙個瀏覽器就可以訪問各種各樣的web服務，但是這樣也越來越導致了越來越多的web安全問題。www服務依賴於htpp協議實現，http是無狀態的協議，所以為了在各個會話之間傳遞資訊，就不可避免地用到cookie或者session等技術...
使用HttpOnly提公升Cookie安全性
在介紹httponly之前，我想跟大家聊聊cookie及xss。隨著b s的普及，我們平時上網都是依賴於http協議完成，而http是無狀態的，即同乙個會話的連續兩個請求互相不了解，他們由最新例項化的環境進行解析，除了應用本身可能已經儲存在全域性物件中的所有資訊外，該環境不儲存與會話有關的任何資訊，...
使用HttpOnly提公升Cookie安全性
隨著b s的普及，我們平時上網都是依賴於http協議完成，而http是無狀態的，即同乙個會話的連續兩個請求互相不了解，他們由最新例項化的環境進行解析，除了應用本身可能已經儲存在全域性物件中的所有資訊外，該環境不儲存與會話有關的任何資訊，http是不會為了下一次連線而維護這次連線所傳輸的資訊的。所以為...