通俗地講，瀏覽器用一個或多個限定的文件來支持Cookie。這些文件在使用Windows操作系統的機器上叫做Cookie文件，在Macintosh機器上
叫做magic Cookie 文件，這些文件被網站用來在上面存儲Cookie數據。網站可以在這些Cookie文件中插入信息，這樣對有些網絡用戶就有些
副作用。有些用戶認為這造成了對個人隱私的侵犯，更糟的是，有些人認為Cookie是對個人空間的侵占，而且會對用戶的計算機帶來安全性的危
害。

目前有些Cookie是臨時的，另一些則是持續的。臨時的Cookie只在瀏覽器上保存一段規定的時間，一旦超過規定的時間該Cookie就會被系統清
除。例如在PHP中Cookie被用來跟蹤用戶進程直到用戶離開網站。持續的Cookie則保存在用戶的Cookie文件中，下一次用戶返回時，仍然可以
對它進行調用。

要了解Cookie，必不可少地要知道它的工作原理。一般來說，Cookie通過HTTP Headers從服務器端返回到瀏覽器上。首先，服務器端在響應
中利用Set-Cookie header來創建一個Cookie，然后，瀏覽器在它的請求中通過Cookie header包含這個已經創建的Cookie，并且反它返回
至服務器，從而完成瀏覽器的論證。 例如，我們創建了一個名字為login的Cookie來包含訪問者的信息，創建Cookie時，服務器端的Header如
下面所示，這里假設訪問者的注冊名是"Michael Jordan"，同時還對所創建的Cookie的屬性如path、domain、expires等進行了指定。

Set-Cookie:login=Michael Jordan;path=/;domain=msn.com;
expires=Monday,01-Mar-99 00:00:01 GMT

上面這個Header會自動在瀏覽器端計算機的Cookie文件中添加一條記錄。瀏覽器將變量名為"login"的Cookie賦值為"Michael Jordon"。注意
，在實際傳遞過程中這個Cookie的值是經過了URLEncode方法的URL編碼操作的。

這個含有Cookie值的HTTP Header被保存到瀏覽器的Cookie文件后，Header就通知瀏覽器將Cookie通過請求以忽略路徑的方式返回到服務器
，完成瀏覽器的認證操作。

此外，我們使用了Cookie的一些屬性來限定該Cookie的使用。例如Domain屬性能夠在瀏覽器端對Cookie發送進行限定，具體到上面的例子，
該Cookie只能傳達室到指定的服務器上，而決不會跑到其他的如www.hp.com的Web站點上去。Expires屬性則指定了該Cookie保存的時間期
限，例如上面的Cookie在瀏覽器上只保存到1999年3月1日1秒。當然，如果瀏覽器上Cookie太多，超過了系統所允許的范圍，瀏覽器將自動對
它進行刪除。至于屬性Path，用來指定Cookie將被發送到服務器的哪一個目錄路徑下。

說明：瀏覽器創建了一個Cookie后，對于每一個針對該網站的請求，都會在Header中帶著這個Cookie；不過，對于其他網站的請求Cookie是
絕對不會跟著發送的。而且瀏覽器會這樣一直發送，直到Cookie過期為止。

2.2.2 要點方法
setcookie-----送出 Cookie 信息到瀏覽器。
語法: int setcookie(string name, string value, int expire, string path, string domain, int secure);
返回值: 整數
本函數會跟著標識 Header 送出一段小信息字符串到瀏覽器。使用本函數要在送出 HTML 數據前，實際上 cookie 也算標識的一部份。本函數的
參數除了第一個 name 之外，都是可以省略的。參數 name 表示 cookie 的名稱；value 表示這個 cookie 的值，這個參數為空字符串則表示取
消瀏覽器中該 cookie 的數據；expire 表示該 cookie 的有效時間；path 為該 cookie 的相關路徑；domain 表示 cookie 的網站；secure 則
需在 https 的安全傳輸時才有效。想得到更多的 cookie 信息可以到 http://www.netscape.com/newsref/std/cookie_spec.html，由
cookie 原創者 Netscape 所提供的完整信息。

對于一個網站會員而言，經常存在需要一次注冊，多次認證的問題，例如我們經常接觸到的論壇、社區等，一般采用手段為cookie或 input
type=hidden來傳遞認證參數。這里面有幾點隱患：

I. setcookie內容必須完整包含帳號密碼，或類似的完整安全信息，如果只攜帶帳號信息或用某種權限標志來認證，極容易造成非法入侵。
例如某站點中的會員更新頁面中攜帶的認證信息是兩個，用戶名和Uid(均為明文傳送)已知Uid對于每個會員是唯一的。由于我們只需要知道對
方的帳號和Uid就可以更改對方信息（不需要知道密碼！），只要攻擊者知道Uid（攻擊者可以通過暴力猜測的方法來得到Uid，有時候站點本身
也會泄露用戶的Uid,例如在論壇等處）那么，攻擊者就可以通過遍歷攻擊完成對任意一個帳號的信息更改。

II. 必須所有需要權限操作的頁面都必須執行認證判斷的操作。如果任何一頁沒有進行這種認證判斷，都有可能給攻擊者以惡意入侵的機會。

III. 很多網站為了方便，將用戶名以及口令信息儲存在Cookie中，有的甚至以明文方式保存口令。如果攻擊者可以訪問到用戶的主機，就可能
通過保存的Cookie文件得到用戶名和口令。

3. 腳本保護的問題
3.1 概念介紹
在程序編寫時優秀的程序員都會知道，用有意義的變量名，文件名有助于增加程序的可讀性，具有良好的程序風格。這個非常好但在腳本語言不太
適合，為了不讓惡意用戶猜到你的變量或數據庫名等信息，必須改掉這些信息。動態的網頁在服務器端執行后返回給客戶的是執行后的代碼，這可
以保護服務器端的很多不想叫或不能叫瀏覽者知道的信息。安全是相對的，每天都在有新的安全漏洞被發現，如果惡意的用戶在你之前知道了一個
可以看你的腳本源代碼的漏洞或這個漏洞一時間無法修補怎么辦？
3.2 主意要點
建議用一些比較怪異的名字命名，刪掉腳本中的注釋。如果還需要保持程序的可讀性的話，可以建立一個映射，你可以寫個具有良好風格的腳本程
序，然后再做一個變量名映射建立一個具有較安全命名方法的腳本，去掉這個腳本中的注視和所有能去掉的信息，修改時作個同步就可以了
我們可以在程序的使用前對程序進行加密，以保護我們自己的程序再萬一的情況下部被泄漏。
3.3 保護方法

我看到過很多的對腳本的加密方法，都很不錯，有的是專門的加密軟件，有的是通過一些技巧加上利用語言的特性進行加密的，例如隨機生成一個
密匙，把密匙放在"不可見的"地方，通過一些算法對腳本進行加解密，就是由于某些系統漏洞導致你的腳本源代碼泄漏，也無濟于事。

4 .實例說明
下面這個例子是在網上經常被提到的，這是個非常經典的例子，所以在這里通過這個實例告訴大家可能存在的危險。
問題描述：
大部分網站把密碼放到數據庫中，在登陸驗證中用以下sql,(以asp為例）
sql="select * from user where username='"&username&"'and pass='"& pass &'"
此時，您只要根據sql構造一個特殊的用戶名和密碼，如：ben' or '1'='1
就可以進入本來你沒有特權的頁面。再來看看上面那個語句吧：
sql="select * from user where username='"&username&"'and pass='"& pass&'"
此時，您只要根據sql構造一個特殊的用戶名和密碼，如：ben' or '1'='1 這樣,程序將會變成這樣: sql="select*from username where
username="&ben'or'1'=1&"and pass="&pass&" or 是一個邏輯運算符,作用是在判斷兩個條件的時候,只要其中一個條件成立,那么等式
將會成立.而在語言中,是以1來代表真的(成立).那么在這行語句中,原語句的"and"驗證將不再繼續,而因為"1=1"和"or"令語句返回為真值.。

另外我們也可以構造以下的用戶名：
username='aa' or username<>'aa'
pass='aa' or pass<>'aa'
相應的在瀏覽器端的用戶名框內寫入：aa' or username<>'aa 口令框內寫入：aa' or pass<>'aa,注意這兩個字符串兩頭是沒有'的。這
樣就可以成功的騙過系統而進入。

具體實施是這樣的，首先我會到注冊的地方去收集信息，了解盡可能多的信息，例如目標數據庫中都有用戶的什么樣的信息，隨便的填寫信息然后
提交，當你要注冊的用戶名被注冊的是有系統會提示你已被注冊，有的網站做的更好的，就是他們專門給你設置的檢測是否有已經被注冊的功能，
通過這樣就會非常容易的找到目標--那個提示已被注冊的用戶，讓后你在這個注冊頁里填寫一些特殊的字符，如'，/，,等字符看系統如何提示，以
證明程序員是否注意到了應該過濾字符或懂得是否應該過濾那些字符，在這頁進行嘗試是因為有的網站在登錄的時候他會記錄你的ip地址，當然你
也可以找一個比你直接登錄要快的代理服務器來做跳板。后面你要做的就是察看登錄頁的html源代碼，看看是否有在客戶端的字符過濾，看看這個
程序員是用什么風格來編寫程序，盡可能多的了解程序編寫風格，這對你以后的某些判斷有好處。如果有在客戶端的過濾也不怕，你要搞清是什么
樣的過濾，能不能對攻擊造成威脅，不要一看有過濾就害怕，可以嘗試著用別的方法繞，就是使用自己精心打造的獨立腳本，進行攻擊。然后你要
看看form的action中的url是否可以直接提交，在瀏覽器地址欄里直接提交，看看返回什么，是否有來路檢測。還有很多細小的地方，你也應該可
以注意到，例如那些地方程序員的整體的編寫風格是什么，變量名定義的風格是什么等等，這個會幫我們"猜"到很多東西。還有別的其他什么，我
也記不太清楚了，臨場發揮吧。通過這些了解我們有如下幾種可能：
1.那個程序員非常善良相信全世界都是好人，什么都沒做，根本沒有任何檢測機制，我們直接用username='aa' or username<>'aa'，
pass='aa' or pass<>'aa'就可以搞定，現在這么善良的人少啦，可是你要是有耐心，找到這種人還是不難的。
2.這個程序員可能聽別人提起過一些安全問題，畢竟現在這個那里都有人說，很多書中都有提及，但是做得不夠好，他只進行了簡單的輸入過濾。
過濾有兩種方式，一種是在客戶端的過濾，一種是在服務器端的過濾。現在很多的程序員考慮到再服務器端進行過濾可能給服務器造成更多的負荷
，會把檢測過程放在客戶端。如果他在服務器端沒做任何事情，那么還是可以對其進行攻擊的，我可以將這個登錄頁的源代碼COPY下來，然后自
己建立一個文件把這些代碼PASTE進去，再對這個文件進行進一步的深加工，去掉原來頁的過濾機制，或者直接將攻擊代碼寫到這個文件中去，然
后將form中的action中的地址改成絕對地址，也就是將文件名改成"http://www.target.com/targer.php"這樣，然后就可以提交啦。但是如
果服務器端加上了"來路檢測"，你就白玩了。如果這樣還是不行，我再換一種方法，在瀏覽器的地址欄里用？來輸入參數，就好像
"http://www.targer.com/targer.php?username='aa' or username<>'aa'&pass='aa' or pass<>'aa' "然后敲回車吧，其實應該先
嘗試這種方法因為這用方法更簡單，防護起來也很簡單，這種提交方式不是post 而是get ，只要服務器端程序檢測你的提交方法，就可以kill掉這
個陰謀。如果單純的只檢測了"來路"，還是不太安全的，可以先正確的提交一次，在提交過程中馬上停止，就是保存這個環境，然后再構造請求。
（我做過幾次試驗得到的結果都不太一樣，應該是和終止的時機有關，歡迎大家來交流）。
3.一個很出色的程序員，安全意識非常高，他在服務器端做了如下檢測：檢測提交的方法；檢測提交的"來路"；檢測提交內容的長度；全面檢測提
交內容，這樣我們就很難通過上面的方法對其進行攻擊，那到保密的資料就已經不太可能了（如果各位還有什么好的辦法，請一定來信告訴小弟，
小弟在這里先謝了）。但是我還想說的是攻擊并不代表是非要入侵進去，拿到某些東西才叫入侵，對你的機器進行破壞也叫入侵啊，例如提交一些
錯誤的請求，腳本解釋程序就會非常規矩的給你返回錯誤信息，最淺顯的后果就是暴露物理路經，有的時候一些特殊的請求會使web服務宕掉，這
些個我認為絕對是屬于攻擊，絕對是危害，也許你認為暴露物理路徑沒有什么，是在單獨看來沒有什么，但要是在一個有計劃的攻擊里，這個就會
發揮很多作用，那時你可能還會莫名為什么他們找到了我的文件呢。也許有人認為這個是腳本解釋程序的bug，也許有的是，但是返回錯誤信息絕
對不是腳本解釋程序的錯誤，這個是每個解釋程序都要做到的，在我看來這個應該是還是程序員的問題，程序員沒有做好對錯誤的處理。每一本教
你如何編寫程序的書籍里基本都會有錯誤處理之類的章節，并且每種語言基本都有錯誤處理函數和方法，只不過你沒有想到罷了。至于究竟要怎么
處理那就要看你對cgi程序安全的熟悉程度了，那就要看你對這種腳本語言的特性熟悉多少了，說到底就是經驗，唯一的辦法就是多看多寫多想多
交流。
4.非常優秀的程序員，以上那些做的都非常好（也許就是你啊，畢竟不難嘛，加上很少的代碼就可以了），怎么辦？？怎么辦？！怎么辦！！在一
旁偷偷的佩服吧！哈哈。

5. 其它注意事項：思路和方法

指導思想：
I.嚴格控制程序與用戶交互的途徑
II.嚴格控制程序與用戶交互的內容
III.盡可能好的保護我們控制

基本思路：
I.為沒一個功能寫一個獨立的程序，程序頁
II.盡可能少的讓客戶了解你的服務器端信息
III.不要用"客戶應該這么寫"這個思路想問題
IV.盡可能多的想到不可能發生的事情

基本方法：
盡可能多的控制交互：
I.檢測提交的方法，就是控制他的post還是get；
II.檢測提交的"來路"，就是檢測一個環境變量HTTP_REFERER；
III.檢測提交內容的長度；
IV全面檢測提交內容；
積極-消極防護：
I.盡可能多的錯誤處理，例如當檢測到了不正確的輸入時，應該怎么做，是強制返回，還是發出警告；
II.充分發揮日志功用，例如在你檢測到了不正確的提交時，就記錄下客戶端的信息，例如IP，系統配置，請求等等，畢竟現在是技術飛躍的時代，
不能保證可以想到每一種可能，這也是我在這篇文章里不止一次提到"盡可能"這個詞的原因。充分的日志記錄不全是為了抓住入侵者（如果入侵者
使用了跳板，記錄了IP也是沒有用的），更重要的是為了能發現問題的所在，找到問題，改正問題，亡羊補牢，這個才是最重要的。
III.充分發揮你的想象力，用一種入侵者的思想考慮問題，用一種另類的思想考慮問題，盡可能想到不可能發生的事，把問題扼殺在萌芽里。

我們xundi哥說的好：掌握方法！！！現在腳本語言層出不窮，asp，perl，php，jsp等等，基本不可能精通每一種，（也許你厲害，都能精通，
我比較呆，會一個就不錯啦），但是要是掌握了方法就不同了啊，各位網絡的精英舉一反三觸類旁通，肯定是優秀的不得了。我寫腳本一共也沒多
少天，寫這個東西我知道肯定是班門弄斧了，錯誤之處還請各位大蝦抱著挽救和幫助的精神，告知小弟（方式、方法、態度不限），小弟我在這里
先謝了。寫這個東西，我只是想說說小弟的一些小的心得，與大家共勉，我想告訴大家的就是"領會精神"，嘿嘿，"領會精神"。大家要是有什么好
的方法，希望不要保留，充分發揮網絡的自用共享，拿出來，大家交流交流，不勝感激。
襲來的，這種東西小弟不敢自己寫（嘿嘿，實際還有不少懶的成分，哈哈），希望大家不要見怪。