1 跨站腳本攻擊(XSS攻擊)

XSS(Cross Site Scripting)，跨站腳本攻擊。XSS是常見的Web攻擊技術(shù)之一.所謂的跨站腳本攻擊指得是:惡意攻擊者往Web頁面里注入惡意Script代碼，用戶瀏覽這些網(wǎng)頁時(shí)，就會(huì)執(zhí)行其中的惡意代碼，可對(duì)用戶進(jìn)行盜取cookie信息、會(huì)話劫持等各種攻擊. 解決方案: (1) 輸入過濾。永遠(yuǎn)不要相信用戶的輸入，對(duì)用戶輸入的數(shù)據(jù)做一定的過濾。如輸入的數(shù)據(jù)是否符合預(yù)期的格式，比如日期格式，Email格式，電話號(hào) 碼格式等等。這樣可以初步對(duì)XSS漏洞進(jìn)行防御。上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊腳本。 因此，后臺(tái)服務(wù)器需要在接收到用戶輸入的數(shù)據(jù)后，對(duì)特殊危險(xiǎn)字符進(jìn)行過濾或者轉(zhuǎn)義處理，然后再存儲(chǔ)到數(shù)據(jù)庫中。(2) 輸出編碼。服務(wù)器端輸出到瀏覽器的數(shù)據(jù)， 可以使用系統(tǒng)的安全函數(shù)來進(jìn)行編碼或轉(zhuǎn)義來防范XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個(gè)函數(shù)可以滿足安全要求。相應(yīng)的JavaScript的編 碼方式可以使用JavascriptEncode。(3) 安全編碼。開發(fā)需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作，同時(shí)要避免使用客戶端數(shù)據(jù)，這些操作需盡量在服 務(wù)器端使用動(dòng)態(tài)頁面來實(shí)現(xiàn)。(4) HttpOnly Cookie。預(yù)防XSS攻擊竊取用戶cookie最有效的防御手段。Web應(yīng)用程序在設(shè)置cookie時(shí)，將其屬性設(shè)為HttpOnly， 就可以避免該網(wǎng)頁的cookie被客戶端惡意JavaScript竊取，保護(hù)用戶cookie信息。(5)WAF(Web Application Firewall)，Web應(yīng)用防火墻，主要的功能是防范諸如網(wǎng)頁木馬、 XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發(fā)，在企業(yè)環(huán)境中深受歡迎。

2 跨站請求偽造(CSRF攻擊)

CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，但很多開發(fā)者對(duì)它很陌生。CSRF也是Web安全中最容易被忽略的一種 網(wǎng)站攻擊 CSRF攻擊的原理:CSRF攻擊過程的受害者用戶登錄網(wǎng)站A，輸入個(gè)人信息，在本地保存服務(wù)器生成的cookie。然后在A網(wǎng)站點(diǎn)擊由攻擊者構(gòu)建一條惡意鏈接跳轉(zhuǎn)到 B網(wǎng)站, 然后B網(wǎng)站攜帶著的用戶cookie信息去訪問B網(wǎng)站.讓A網(wǎng)站造成是用戶自己訪問的假相,從而來進(jìn)行一些列的操作,常見的就是轉(zhuǎn)賬. 解決方案: (1) 驗(yàn)證碼。應(yīng)用程序和用戶進(jìn)行交互過程中，特別是賬戶交易這種核心步驟，強(qiáng)制用戶輸入驗(yàn)證碼，才能完成最終請求。在通常情況下，驗(yàn)證碼夠很好地遏制 CSRF攻擊。但增加驗(yàn)證碼降低了用戶的體驗(yàn)，網(wǎng)站不能給所有的操作都加上驗(yàn)證碼。所以只能將驗(yàn)證碼作為一種輔助手段，在關(guān)鍵業(yè)務(wù)點(diǎn)設(shè)置驗(yàn)證碼。(2) Referer Check。 HTTP Referer是header的一部分，當(dāng)瀏覽器向web服務(wù)器發(fā)送請求時(shí)，一般會(huì)帶上Referer信息告訴服務(wù)器是從哪個(gè)頁面鏈接過來的，服務(wù)器籍此可以獲得一些信息用于處 理。可以通過檢查請求的來源來防御CSRF攻擊。正常請求的referer具有一定規(guī)律，如在提交表單的referer必定是在該頁面發(fā)起的請求。所以通過檢查http包頭referer的值 是不是這個(gè)頁面，來判斷是不是CSRF攻擊。但在某些情況下如從https跳轉(zhuǎn)到http，瀏覽器處于安全考慮，不會(huì)發(fā)送referer，服務(wù)器就無法進(jìn)行check了。若與該網(wǎng)站同域的 其他網(wǎng)站有XSS漏洞，那么攻擊者可以在其他網(wǎng)站注入惡意腳本，受害者進(jìn)入了此類同域的網(wǎng)址，也會(huì)遭受攻擊。出于以上原因，無法完全依賴Referer Check作為防御CSRF 的主要手段。但是可以通過Referer Check來監(jiān)控CSRF攻擊的發(fā)生。(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即發(fā)送請求時(shí)在HTTP 請 求中以參數(shù)的形式加入一個(gè)隨機(jī)產(chǎn)生的token，并在服務(wù)器建立一個(gè)攔截器來驗(yàn)證這個(gè)token。服務(wù)器讀取瀏覽器當(dāng)前域cookie中這個(gè)token值，會(huì)進(jìn)行校驗(yàn)該請求當(dāng)中的token 和cookie當(dāng)中的token值是否都存在且相等，才認(rèn)為這是合法的請求。否則認(rèn)為這次請求是違法的，拒絕該次服務(wù)。這種方法相比Referer檢查要安全很多，token可以在用戶 登陸后產(chǎn)生并放于session或cookie中，然后在每次請求時(shí)服務(wù)器把token從session或cookie中拿出，與本次請求中的token 進(jìn)行比對(duì)。由于token的存在，攻擊者無法再構(gòu)造 出一個(gè)完整的URL實(shí)施CSRF攻擊。但在處理多個(gè)頁面共存問題時(shí)，當(dāng)某個(gè)頁面消耗掉token后，其他頁面的表單保存的還是被消耗掉的那個(gè)token，其他頁面的表單提交時(shí)會(huì)出 現(xiàn)token錯(cuò)誤。

3 SQL注入攻擊

SQL注入(SQL Injection)，應(yīng)用程序在向后臺(tái)數(shù)據(jù)庫傳遞SQL(Structured Query Language，結(jié)構(gòu)化查詢語言)時(shí)，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令.
解決方案: (1) 防止系統(tǒng)敏感信息泄露。設(shè)置php.ini選項(xiàng)display_errors=off，防止php腳本出錯(cuò)之后，在web頁面輸出敏感信息錯(cuò)誤，讓攻擊者有機(jī)可乘。(2) 數(shù)據(jù)轉(zhuǎn)義。設(shè)置php.ini選項(xiàng)magic_quotes_gpc=on，它會(huì)將提交的變量中所有的’(單引號(hào))，”(雙引號(hào))，\(反斜杠)，空白字符等都在前面自動(dòng)加上\?；蛘卟捎胢ysql_real_escape()函數(shù)或addslashes()函數(shù)進(jìn)行輸入?yún)?shù)的轉(zhuǎn)義。(3) 增加黑名單或者白名單驗(yàn)證。白名單驗(yàn)證一般指，檢查用戶輸入是否是符合預(yù)期的類型、長度、數(shù)值范圍或者其他格式標(biāo)準(zhǔn)。黑名單驗(yàn)證是指，若在用戶輸入中，包含明顯的惡意內(nèi)容則拒絕該條用戶請求。在使用白名單驗(yàn)證時(shí)，一般會(huì)配合黑名單驗(yàn)證。

4 文件上傳漏洞

上傳漏洞在DVBBS6.0時(shí)代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級(jí)超級(jí)高，現(xiàn)在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會(huì)讓攻擊者注入危險(xiǎn)內(nèi)容或惡意代碼，并在服務(wù)器上運(yùn)行。 文件上傳漏洞的原理：由于文件上傳功能實(shí)現(xiàn)代碼沒有嚴(yán)格限制用戶上傳的文件后綴以及文件類型，導(dǎo)致允許攻擊者向某個(gè)可通過 Web 訪問的目錄上傳任意PHP文件，并能夠?qū)⑦@些文件傳遞給 PHP 解釋器，就可以在遠(yuǎn)程服務(wù)器上執(zhí)行任意PHP腳本。 解決方案： (1)檢查服務(wù)器是否判斷了上傳文件類型及后綴。 (2) 定義上傳文件類型白名單，即只允許白名單里面類型的文件上傳。 (3) 文件上傳目錄禁止執(zhí)行腳本解析，避免攻擊者進(jìn)行二次攻擊。 Info漏洞 Info漏洞就是CGI把輸入的參數(shù)原樣輸出到頁面，攻擊者通過修改輸入?yún)?shù)而達(dá)到欺騙用戶的目的。