基本思路：
為沒一個功能寫一個獨立的程序，程序頁
盡可能少的讓客戶了解你的服務器端信息
不要用"客戶應該這麼寫"這個思路想問題
盡可能多的想到不可能發生的事情
1.關於交互式動態網頁可能存在的問題
1.1 form類型的交互
1.1.1 概念介紹
在我們和浏覽者進行交互時，最常用到的就是form(post/get/put方法)，雖然非常方便，但是很多問題也是因他而起。
form表單中input標志
用來接受用戶輸入的信息，例如：用戶名、密碼、email等。如果你沒有對用戶輸入進行很好的檢查的話，一個惡意的用戶會屏蔽掉一些安全機制，繞過安全認證。例如，輸入標准的HTML語句或者Javascript語句會改變輸出結果 ，在輸入框中打入標准的HTML語句會得到什麼樣的結果呢？比如一個留言本，我們留言內容中打入：<font size=10>你好！</font> 如果你的程序中沒有屏蔽Html語句，那麼就會改變"你好"字體的大小。在留言本中改變字體大小和貼圖有時並不是什麼壞事，反而可以使留言本生動。但是如果在輸入框中寫個 Javascript 的死循環，比如：
<a herf="http://someurl" onMouSEOver="while(1) {window.close('/')}">第一萬個驚心動魄</a> 那麼其他查看該留言的客人只要移
動鼠標到"第一萬個驚心動魄"，上就會使用戶的浏覽器因死循環而死掉。
1.1.2 防范要點
(1)對特殊字符進行過濾
([\&;\`'\\\|"*?~<>^\(\)\[\]\{\}\$\n\r])/\\$1/g;)，這個是最基本的，在很多地方也已經不只一次提到過
<script language="vbscript">
sub uBotton_onclick
if form1.uUserName.value=""then
msgbox"您的姓名不能為空！",0+32,"哦！還不行"
form1.uUserName.focus
exit sub
end if
if form1.uPassWord.value=""then
msgbox"您的密碼不能為空！",0+32,"哦！還不行"
form1.uPassWord.focus
exit sub
end if
if form1.uUserName.value=""then
msgbox"您的姓名不能為空！",0+32,"哦！還不行"
form1.uUserName.focus
exit sub
end if
form1.submit
end sub
</script>
function isEmpty(objname)
{
var str = document.inputform[objname].value
var tmpstr = str.replace([\&;\`'\\\|"*?~<>^\(\)\[\]\{\}\$\n\r])/\\$1/g;,"")
var tmpstr = tmpstr.replace([\&;\`'\\\|"*?~<>^\(\)\[\]\{\}\$\n\r])/\\$1/g;,"")
return (tmpstr.length==0)
}
function check()
{
tf=document.inputform
errors=""
if (isEmpty("username")) errors += "用戶名不能為空。\n";
if (isEmpty("passWord")) errors += "密碼不能為空！\n"
if (errors!="")
alert(errors);
return (errors=="")
}
(2) 對輸入的字符長度進行限制
(3) 進行盡可能多的錯誤出理和錯誤陷阱
(4) 盡可能多的使用以下這些標志，減少用戶輸入的機會
<input type="checkbox" name="checkbox" value="checkbox">
<select name="select"> </select>
<input type="radio" name="radiobutton" value="radiobutton">
1.2 post/get類型的交互
1.2.1 概念介紹
這種類型的問題主要是浏覽者可以通過浏覽器的地址欄對腳本頁通過添加參數來和服務器進行交互，這些參數已經繞過放在客戶端提交頁的輸入檢查了，還有就是可以通過地址欄輸入較長的參數或惡意編造的代碼造成服務器異常運算錯誤，導致服務器宕機或緩沖區溢出。
1.2.2 防范要點
(1) 盡量不要讓浏覽者了解到你的運算提交頁
(2) 不允許地址欄提交參數
例如ASP程序中的request.serverVariables(QUERY_STRING)檢測是否有參數，如果有則使用response.redirect()強制返回指定頁，可以
是首頁，或者你自己做的警告頁。
(3) 腳本頁間傳遞參數不要再浏覽器欄顯示，盡可能少的讓浏覽者了解你的程序規則、參數等例如ASP中的Request.form和Request.QueryString這兩個數據集合分別使用的是post和get方法，我們盡量不要是用Request.QueryString這個數據集合，盡可能少的讓浏覽者有和你交互的機會，
2. 安全認證的問題
2.1 需要安全認證密碼認證的可能存在的問題
2.1.1 概念介紹
現在流行的CGI應用程序傾向於收集信用卡信息。數據收集是CGI 應用程序的一個簡單的任務，但是敏感信息的收集需要一個將信息從浏覽器傳送給服務器和CGI程序的安全途徑。
舉個例子，假設我要通過Internet來銷售書。我可能在浏覽器上建立一個表單，允許要購書的顧客通過表單提交它的個人信息和信用卡號碼。受到這些信息後，我會將它們存儲到我的計算機作為商業記錄。
如果有人侵入我的商業計算機，那麼他可能會訪問存放顧客信息和信用卡號碼的機密數據。為了避免這種情況，我會審查我的計算機配置安全了，並確定用來接受表單的CGI腳本不會被惡意的操縱。換句話說，我，作為計算機的系統管理員和CGI程序員，要盡力控制住第一個問題：防止信息直接從我的計算機中被竊取。
然而，怎樣防止當信息由客戶端發往服務器過程中有人中途竊取呢？記住信息怎樣由Web服務器傳送到CGI程序了嗎？信息通過網絡由浏覽器先傳送到服務器，然後服務器將信息傳送給CGI程序。這些信息可能在由客戶機傳送到服務器時被中途竊取(如圖2)。注意，為了保護信息使其不會被中途竊取，必須在客戶和服務器之間進行加密。當然，如果你的客戶機不能識別的話，你不能執行特定CGI的加密。
由於Web處理的特點，使用你獨有的單獨通過CGI程序實現的安全處理協議的唯一途徑是:在表單信息通過浏覽器傳送到服務器之前將其加密。這個方案如。
之前，發展你自己的安全處理協議幾乎是不可能的。感謝Java這樣的語言,最近在客戶端處理所作的創新，使得這個發展變成可能。 方法是產生一個標准Html格式擴展的Java接口。當Java的提交按鈕被選擇時，Java Applet會在利用標准的POST HTTP請求將它發送到Web服務器前先將值加密。
使用Java作為客戶機來發送和接收加密的數據將允許你使用自己定制的加密方案，而不需要一個昂貴的商業服務器。
因此，在網絡上安全保密地傳送數據信息需要調整浏覽器和服務器之間的通信路徑，有一些是不能僅僅靠CGI就能夠控制的。目前有兩種加密客戶機/服務器信息處理的建議：SSL(Secure Sockets Layer)和SHTTP(Secure HTTP),分別由Netscape和EIT(EnterPRise Integrations Technology)提議。關於這點，目前還不清楚哪一個將成為標准；很多公司在他們的服務器中兩種都采用了。因此，知道如何在這兩者中編寫CGI程序是很有用的。
SSL是一個協議獨立的加密方案，在網絡信息包的應用層和傳輸層之間提供了安全的通道(參照圖5)。簡單說來，就是HTML或CGI經過了幕後的服務器進行了加密處理，然而對Html和CGI的作者來說是透明的。
因為客戶端和服務器端網絡程序處理加密過程，幾乎你的所有的CGI腳本不需要進行安全事務的修正。有一個顯著的例外。一個nph(no-parse-header)的CGI程序繞過服務器而直接與客戶端進行通信。因此，nph的CGI腳本不會經過加密處理，因為信息未得到加密。受此影響的一個值得注意的CGI應用程序是Netscape服務器推動的動態實現(Netscape server-push animations)。我懷疑這是主要應該值得注意的，然而，更有可能因為要安全的傳輸敏感信息而犧牲頁面中的動畫。
SHTTP采用一種和SSL不同的方法。它通過擴展HTTP協議(應用層)來運作，優於一個較低層。因此，盡管SSL可以應用於所有的網絡服務，然而SHTTP是一個特定的Web協議。
另外，還有其它的優點。作為HTTP的擴展集，SHTTP全兼容於HTTP和SHTTP的浏覽器和服務器。為了使用SSL,你必須有一個支持SSL的浏覽器和服務器。另外，SHTTP是一個更靈活的協議。例如，這個服務器可以指定首選的加密方案。
SHTTP處理依賴於附加的HTTP頭。因此，如果你想讓你的CGI程序采用SHTTP的加密處理，你需要包含適當的頭。例如，替換簡單返回HTTP頭
。
Content-type:text/Html
當一個SHTTP服務器從CGI應用程序中收到這個信息，它會知道在將其發送到浏覽器之前將信息加密。一個非SHTTP的浏覽器將忽略附加的頭。
關於使用SHTTP的更多的信息，請參照SHTTP的說明書:
http://www.commerce.net/information/standards/drafts/shttp.txt
2.1.3 腳本解析
下面是我以前寫的一段ASP腳本，做了一些修改，把他貼出來，讓大家看看我加入了設置，那裡做的不夠好。我在這裡就不多說了，有興趣可以到我的論壇來大家討論。
<!--#include file="conn.ASP"-->
<%
dim errmsg
if request.form("username")="" then
ErrMsg="用戶名不能為空"
foundError=True
else
UserName=request.form("UserName")
end if
if request.form("passWord")="" then
ErrMsg="密碼不能為空"
foundError=True
else
PassWord=request.form("PassWord")
end if
if FoundError=true then
showAnnounce(ErrMsg)
else
set rstmp=server.createobject("adodb.recordset")
if Request.ServerVariables("REQUEST_METHOD") = "POST" then
rstmp.open "Select * from User Where userName='" & UserName & "'",conn,3,3
if rstmp.bof then
session.contents("UserName")=UserName
rstmp.addnew
rstmp("username")=username
rstmp("userpassword")=passWord
rstmp("logins")=1
rstmp("online")=1
rstmp.update
response.redirect("index.ASP")
elseif PassWord<>rstmp("userpassWord") then
ErrMsg="密碼錯啦"
foundError=True
showAnnounce(ErrMsg)
else
session.contents("UserName")=UserName
rstmp("logins")=rstmp("logins")+1
rstmp("online")=1
rstmp.update
rstmp.close
Set rstmp=nothing
response.redirect("index.ASP")
end if
else
if session.contents("UserName")<>"" then
rstmp.open "Select * from User Where userName='"&session.contents("UserName")&"'",conn,3,3
rstmp("logins")=rstmp("logins")+1
rstmp("online")=1
rstmp.update
rstmp.close
Set rstmp=nothing
conn.close
set conn=nothing
response.redirect("index.ASP")
end if
end if
end if
%>
<Html>
<head>
<title></title>
<link rel="stylesheet" type="text/CSS" href="forum.CSS">
</head>
<body>
<%
function showAnnounce(ErrMsg)
on error resume next
response.write "<p align=center><font color='red'><strong><Big>哈哈</big></strong></font><BR><font
color='#0000FF'>"+ErrMsg+"</font><BR>"+chr(13)+chr(10)
%>
<tr>
<td width="100%">
<p align="center"><br>
<form action="login.ASP" method="post">
輸入<INPUT name=username size=8 class='smallInput'>
<BR>哈哈<INPUT name=password size=8 class='smallInput' type=passWord>
</td>
</tr>
<tr>
<td width="100%">
<p align="center"><br>
<INPUT type="submit" name="B12" class='buttonface' value=μ???>
<font color="#FF0000"><br> <br>
*</font>錯了
</td> </form>
</tr>
<%
end function
%>
###---checklogin.ASP
<%
dim adname
dim passwd
adname=Request.Form("adname")
passwd=Request.Form("passwd")
if adname="" then
response.redirect "login.ASP"
end if
if passwd="" then
response.redirect "login.ASP"
end if
if adname="focus-admin" and passwd="1" then
response.redirect "manage.ASP"
else
response.redirect "login.ASP"
end if
%>
###---checklogin.ASP----end
###---manage.ASP
<%
dim where
dim where1
dim refererURL
dim refererURL2
dim refererURL3
refererURL=phyURL&"login.as"
refererURL2=phyURL&"edit.ASP"
refererURL3=phyURL&"manage.a"
refererURL4=phyURL&"savearti"
where=Request.ServerVariables("HTTP_REFERER")
where=left(where,(len(phyURL)+8))
if where<>refererURL and where<> refererURL2 and where<>refererURL3 and where<>refererURL4 then
Response.Redirect "login.ASP"
end if
const MaxPerPage=20
dim totalPut
dim CurrentPage
dim TotalPages
dim i,j
if not isempty(request("page")) then
currentPage=cint(request("page"))
else
currentPage=1
end if
%>
###---manage.ASP-----end
2.2 cookIE的問題
2.2.1 概念介紹
按照Netscape官方文檔中的定義，Cookie是在HTTP協議下，服務器或腳本可以維護客戶工作站上信息的一種方式。CookIE是由Web服務器保存在用戶浏覽器上的小廣西文件，它可以包含有關用戶的信息（如身份識別號碼、密碼、用戶在Web站點購物的方式或用戶訪問該站點的次數）。無論何時用戶鏈接到服務器，Web站點都可以訪問CookIE信息。
通俗地講，浏覽器用一個或多個限定的文件來支持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等等，基本不可能精通每一種，（也許你厲害，都能精通，我比較呆，會一個就不錯啦），但是要是掌握了方法就不同了啊，各位網絡的精英舉一反三觸類旁通，肯定是優秀的不得了。我寫腳本一共也沒多少天，寫這個東西我知道肯定是班門弄斧了，錯誤之處還請各位大蝦抱著挽救和幫助的精神，告知小弟（方式、方法、態度不限），小弟我在這裡先謝了。寫這個東西，我只是想說說小弟的一些小的心得，與大家共勉，我想告訴大家的就是"領會精神"，嘿嘿，"領會精神"。大家要是有什麼好的方法，希望不要保留，充分發揮網絡的自用共享，拿出來，大家交流交流，不勝感激。襲來的，這種東西小弟不敢自己寫（嘿嘿，實際還有不少懶的成分，哈哈），希望大家不要見怪。
