1，SQL注入
 2，XSS
 3，CSRF
 4.檔案上傳漏洞

1，SQL注入：
這個比較常見，可能大家也聽說過，就是URL裡面如果有對資料庫進行操作的引數時，要做一下特殊的處理，
否則被別有用心的人利用的話就可能釀成大錯，輕則使用者資訊洩露，重則資料庫被刪

如果有如下URL，查詢分頁，且程式碼裡面沒有特殊處理
http://www.baidu.com/abc.asp?page=1

則在URL後面加入如下語句可以判斷有無注入點
; and 1=1 and 1=2

更多其它操作請自行百度，解決方式有很多種，關鍵是要知道這種注入

(1) 防止系統敏感資訊洩露。設定php.ini選項display_errors=off，防止php指令碼出錯之後，在web頁面輸出敏感資訊錯誤，讓攻擊者有機可乘。
(
 
2) 資料轉義。設定php.ini選項magic_quotes_gpc=on，它會將提交的變數中所有的’(單引號)，”(雙引號)，\(反斜槓)，空白字元等都在前面自動加上\。或者採用mysql_real_escape()函式或addslashes()函式進行輸入引數的轉義。
(3) 增加黑名單或者白名單驗證。白名單驗證一般指，檢查使用者輸入是否是符合預期的型別、長度、數值範圍或者其他格式標準。黑名單驗證是指，若在使用者輸入中，包含明顯的惡意內容則拒絕該條使用者請求。在使用白名單驗證時，一般會配合黑名單驗證。 

2，XSS 全稱跨站指令碼攻擊

這個大家都做過處理，但是並不一定知道名字，（Cross Site Scripting, 安全專家們通常將其縮寫成XSS,原本應當是css，但為了和層疊樣式表（Cascading Style Sheet,CSS ）有所區分，故稱XSS）,

這種問題通常是由於對使用者的輸入沒有嚴格的加以過濾導致的

論壇A有一個評論的功能，但是並沒有過濾HTML標籤，導致使用者可以隨意的通過評論在這個帖子中新增圖片和指令碼，
輕則影響頁面樣式，重則危害網站的安全，如果別有用心的人插入非法指令碼，則頁面有可能出現廣告，
甚至丟失使用者資訊，進一步還能危害到整個站的安全

(1) 輸入過濾。永遠不要相信使用者的輸入，對使用者輸入的資料做一定的過濾。如輸入的資料是否符合預期的格式，比如日期格式，Email格式，電話號碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊指令碼。
因此，後臺伺服器需要在接收到使用者輸入的資料後，對特殊危險字元進行過濾或者轉義處理，然後再儲存到資料庫中。
(
 
2) 輸出編碼。伺服器端輸出到瀏覽器的資料，
可以使用系統的安全函式來進行編碼或轉義來防範XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函式可以滿足安全要求。相應的JavaScript的編碼方式可以使用JavascriptEncode。
(3) 安全編碼。開發需儘量避免Web客戶端文件重寫、重定向或其他敏感操作，同時要避免使用客戶端資料，這些操作需儘量在伺服器端使用動態頁面來實現。
(4) HttpOnly Cookie。預防XSS攻擊竊取使用者cookie最有效的防禦手段。Web應用程式在設定cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護使用者cookie資訊。
(5)WAF(Web Application Firewall)，Web應用防火牆，主要的功能是防範諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發，在企業環境中深受歡迎

3，CSRF （Cross-site request forgery）跨站請求偽造

這種問題一般是由於網站把重要的使用者資訊不加以處理就放在本地，如果使用者在訪問某重要網站時，比如網銀，假如使用者的唯一標識資訊被存在本地，

如果此時訪問了非法網站，在某些特殊情況下，就有可能丟失使用者重要資訊，進而威脅使用者安全

(1) 驗證碼。應用程式和使用者進行互動過程中，特別是賬戶交易這種核心步驟，強制使用者輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了使用者的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設定驗證碼。
(2) Referer Check。HTTP Referer是header的一部分，當瀏覽器向web伺服器傳送請求時，一般會帶上Referer資訊告訴伺服器是從哪個頁面連結過來的，伺服器籍此可以獲得一些資訊用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，伺服器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那麼攻擊者可以在其他網站注入惡意指令碼，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。
(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即傳送請求時在HTTP 請求中以引數的形式加入一個隨機產生的token，並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。這種方法相比Referer檢查要安全很多，token可以在使用者登陸後產生並放於session或cookie中，然後在每次請求時伺服器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單儲存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤

4 檔案上傳漏洞
上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許使用者上傳任意檔案可能會讓攻擊者注入危險內容或惡意程式碼，並在伺服器上執行。 檔案上傳漏洞的原理：由於檔案上傳功能實現程式碼沒有嚴格限制使用者上傳的檔案字尾以及檔案型別，導致允許攻擊者向某個可通過 Web 訪問的目錄上傳任意PHP檔案，並能夠將這些檔案傳遞給 PHP 直譯器，就可以在遠端伺服器上執行任意PHP指令碼。 

 (1)檢查伺服器是否判斷了上傳檔案型別及字尾。
 (2) 定義上傳檔案型別白名單，即只允許白名單裡面型別的檔案上傳。
 (3) 檔案上傳目錄禁止執行指令碼解析，避免攻擊者進行二次攻擊。  Info漏洞 Info漏洞就是CGI把輸入的引數原樣輸出到頁面，攻擊者通過修改輸入引數而達到欺騙使用者的目的。

此文轉載