一個(gè)網(wǎng)站建立以后，如果不注意安全方面的問題，很容易被人攻擊，下面就討論一下幾種漏洞情況和防止攻擊的辦法。

一、SQL注入

　　所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請(qǐng)求的查詢字符串，最終達(dá)到欺騙服務(wù)器執(zhí)行惡意的SQL命令。具體來說，它是利用現(xiàn)有應(yīng)用程序，將（惡意）的SQL命令注入到后臺(tái)數(shù)據(jù)庫(kù)引擎執(zhí)行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個(gè)存在安全漏洞的網(wǎng)站上的數(shù)據(jù)庫(kù)，而不是按照設(shè)計(jì)者意圖去執(zhí)行SQL語句。比如先前的很多影視網(wǎng)站泄露VIP會(huì)員密碼大多就是通過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊。

　　原理：

　　SQL注入攻擊指的是通過構(gòu)建特殊的輸入作為參數(shù)傳入Web應(yīng)用程序，而這些輸入大都是SQL語法里的一些組合，通過執(zhí)行SQL語句進(jìn)而執(zhí)行攻擊者所要的操作，其主要原因是程序沒有細(xì)致地過濾用戶輸入的數(shù)據(jù)，致使非法數(shù)據(jù)侵入系統(tǒng)。

　　根據(jù)相關(guān)技術(shù)原理，SQL注入可以分為平臺(tái)層注入和代碼層注入。前者由不安全的數(shù)據(jù)庫(kù)配置或數(shù)據(jù)庫(kù)平臺(tái)的漏洞所致；后者主要是由于程序員對(duì)輸入未進(jìn)行細(xì)致地過濾，從而執(zhí)行了非法的數(shù)據(jù)查詢?；诖?，SQL注入的產(chǎn)生原因通常表現(xiàn)在以下幾方面：

　?、俨划?dāng)?shù)念愋吞幚恚?/p>

　?、诓话踩臄?shù)據(jù)庫(kù)配置；

　?、鄄缓侠淼牟樵兗幚?；

　　④不當(dāng)?shù)腻e(cuò)誤處理；

　　⑤轉(zhuǎn)義字符處理不合適；

　　⑥多個(gè)提交處理不當(dāng)。

　　防護(hù)：

　　1.永遠(yuǎn)不要信任用戶的輸入。對(duì)用戶的輸入進(jìn)行校驗(yàn)，可以通過正則表達(dá)式，或限制長(zhǎng)度；對(duì)單引號(hào)和雙"-"進(jìn)行轉(zhuǎn)換等。

　　2.永遠(yuǎn)不要使用動(dòng)態(tài)拼裝sql，可以使用參數(shù)化的sql或者直接使用存儲(chǔ)過程進(jìn)行數(shù)據(jù)查詢存取。

　　3.永遠(yuǎn)不要使用管理員權(quán)限的數(shù)據(jù)庫(kù)連接，為每個(gè)應(yīng)用使用單獨(dú)的權(quán)限有限的數(shù)據(jù)庫(kù)連接。

　　4.不要把機(jī)密信息直接存放，加密或者h(yuǎn)ash掉密碼和敏感的信息。

　　5.應(yīng)用的異常信息應(yīng)該給出盡可能少的提示，最好使用自定義的錯(cuò)誤信息對(duì)原始錯(cuò)誤信息進(jìn)行包裝

　　6.sql注入的檢測(cè)方法一般采取輔助軟件或網(wǎng)站平臺(tái)來檢測(cè)，軟件一般采用sql注入檢測(cè)工具jsky，MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻擊等。

二、跨站腳本攻擊(XSS，Cross-site scripting)

　　跨站腳本攻擊（XSS）是最常見和基本的攻擊WEB網(wǎng)站的方法。攻擊者在網(wǎng)頁上發(fā)布包含攻擊性代碼的數(shù)據(jù)。當(dāng)瀏覽者看到此網(wǎng)頁時(shí)，特定的腳本就會(huì)以瀏覽者用戶的身份和權(quán)限來執(zhí)行。通過XSS可以比較容易地修改用戶數(shù)據(jù)、竊取用戶信息，以及造成其它類型的攻擊，例如CSRF攻擊。

　　常見解決辦法:確保輸出到HTML頁面的數(shù)據(jù)以HTML的方式被轉(zhuǎn)義

　　出錯(cuò)的頁面的漏洞也可能造成XSS攻擊，比如頁面/gift/giftList.htm?page=2找不到。出錯(cuò)頁面直接把該url原樣輸出，如果攻擊者在url后面加上攻擊代碼發(fā)給受害者，就有可能出現(xiàn)XSS攻擊

三、 跨站請(qǐng)求偽造攻擊（CSRF)

　　跨站請(qǐng)求偽造（CSRF，Cross-site request forgery）是另一種常見的攻擊。攻擊者通過各種方法偽造一個(gè)請(qǐng)求，模仿用戶提交表單的行為，從而達(dá)到修改用戶的數(shù)據(jù)，或者執(zhí)行特定任務(wù)的目的。為了假冒用戶的身份，CSRF攻擊常常和XSS攻擊配合起來做，但也可以通過其它手段，例如誘使用戶點(diǎn)擊一個(gè)包含攻擊的鏈接。

　　解決的思路有：

　　1.采用POST請(qǐng)求，增加攻擊的難度.用戶點(diǎn)擊一個(gè)鏈接就可以發(fā)起GET類型的請(qǐng)求。而POST請(qǐng)求相對(duì)比較難，攻擊者往往需要借助javascript才能實(shí)現(xiàn)

　　2.對(duì)請(qǐng)求進(jìn)行認(rèn)證，確保該請(qǐng)求確實(shí)是用戶本人填寫表單并提交的，而不是第三者偽造的.具體可以在會(huì)話中增加token,確?？吹叫畔⒑吞峤恍畔⒌氖峭粋€(gè)人

四、Http Heads攻擊

　　凡是用瀏覽器查看任何WEB網(wǎng)站，無論你的WEB網(wǎng)站采用何種技術(shù)和框架，都用到了HTTP協(xié)議。HTTP協(xié)議在Response header和content之間，有一個(gè)空行，即兩組CRLF（0x0D 0A）字符。這個(gè)空行標(biāo)志著headers的結(jié)束和content的開始?！奥斆鳌钡墓粽呖梢岳眠@一點(diǎn)。只要攻擊者有辦法將任意字符“注入”到 headers中，這種攻擊就可以發(fā)生。

　　以登陸為例：有這樣一個(gè)url：http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

　　當(dāng)?shù)卿洺晒σ院螅枰囟ㄏ蚧豴age參數(shù)所指定的頁面。下面是重定向發(fā)生時(shí)的response headers。

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index

　　假如把URL修改一下，變成這個(gè)樣子：

　　http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

　　那么重定向發(fā)生時(shí)的reponse會(huì)變成下面的樣子：

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkoutCRLF>
CRLF>
script>alert('hello')/script>

　　這個(gè)頁面可能會(huì)意外地執(zhí)行隱藏在URL中的javascript。類似的情況不僅發(fā)生在重定向（Location header）上，也有可能發(fā)生在其它headers中，如Set-Cookie header。這種攻擊如果成功的話，可以做很多事，例如：執(zhí)行腳本、設(shè)置額外的cookie（CRLF>Set-Cookie: evil=value）等。

　　避免這種攻擊的方法，就是過濾所有的response headers，除去header中出現(xiàn)的非法字符，尤其是CRLF。

　　服務(wù)器一般會(huì)限制request headers的大小。例如Apache server默認(rèn)限制request header為8K。如果超過8K，Aapche Server將會(huì)返回400 Bad Request響應(yīng)：

　　對(duì)于大多數(shù)情況，8K是足夠大的。假設(shè)應(yīng)用程序把用戶輸入的某內(nèi)容保存在cookie中,就有可能超過8K.攻擊者把超過8k的header鏈接發(fā)給受害 者,就會(huì)被服務(wù)器拒絕訪問.解決辦法就是檢查cookie的大小,限制新cookie的總大寫，減少因header過大而產(chǎn)生的拒絕訪問攻擊。

五、Cookie攻擊

　　通過JavaScript非常容易訪問到當(dāng)前網(wǎng)站的cookie。你可以打開任何網(wǎng)站，然后在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),立刻就可以看到當(dāng)前站點(diǎn)的cookie（如果有的話）。攻擊者可以利用這個(gè)特性來取得你的關(guān)鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執(zhí)行特定的JavaScript腳本，取得你的cookie。假設(shè)這個(gè)網(wǎng)站僅依賴cookie來驗(yàn)證用戶身份，那么攻擊者就可以假冒你的身份來做一些事情。

　　現(xiàn)在多數(shù)瀏覽器都支持在cookie上打上HttpOnly的標(biāo)記,凡有這個(gè)標(biāo)志的cookie就無法通過JavaScript來取得,如果能在關(guān)鍵cookie上打上這個(gè)標(biāo)記，就會(huì)大大增強(qiáng)cookie的安全性

六、重定向攻擊

　　一種常用的攻擊手段是“釣魚”。釣魚攻擊者，通常會(huì)發(fā)送給受害者一個(gè)合法鏈接，當(dāng)鏈接被點(diǎn)擊時(shí)，用戶被導(dǎo)向一個(gè)似是而非的非法網(wǎng)站，從而達(dá)到騙取用戶信任、竊取用戶資料的目的。為防止這種行為，我們必須對(duì)所有的重定向操作進(jìn)行審核，以避免重定向到一個(gè)危險(xiǎn)的地方。常見解決方案是白名單，將合法的要重定向的url加到白名單中，非白名單上的域名重定向時(shí)拒之。第二種解決方案是重定向token，在合法的url上加上token，重定向時(shí)進(jìn)行驗(yàn)證。

七、上傳文件攻擊

　　1.文件名攻擊，上傳的文件采用上傳之前的文件名，可能造成：客戶端和服務(wù)端字符碼不兼容，導(dǎo)致文件名亂碼問題；文件名包含腳本，從而造成攻擊。

　　2.文件后綴攻擊，上傳的文件的后綴可能是exe可執(zhí)行程序、js腳本等文件，這些程序可能被執(zhí)行于受害者的客戶端，甚至可能執(zhí)行于服務(wù)器上。因此我們必須過濾文件名后綴，排除那些不被許可的文件名后綴。

　　3.文件內(nèi)容攻擊，IE6有一個(gè)很嚴(yán)重的問題，它不信任服務(wù)器所發(fā)送的content type，而是自動(dòng)根據(jù)文件內(nèi)容來識(shí)別文件的類型，并根據(jù)所識(shí)別的類型來顯示或執(zhí)行文件。如果上傳一個(gè)gif文件，在文件末尾放一段js攻擊腳本，就有可能被執(zhí)行。這種攻擊，它的文件名和content type看起來都是合法的gif圖片，然而其內(nèi)容卻包含腳本，這樣的攻擊無法用文件名過濾來排除，而是必須掃描其文件內(nèi)容，才能識(shí)別。

以上就是WEB前端常見受攻擊方式及解決辦法總結(jié)的詳細(xì)內(nèi)容，更多關(guān)于web前端受攻擊及解決辦法的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！