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把輸入的參數原樣輸出到頁面，攻擊者通過修改輸入參數而達到欺騙用戶的目的。
此文轉載