這篇文章主要介紹了WEB前端常見(jiàn)受攻擊方式及解決辦法總結，端常文中講解非常細致，見(jiàn)受及解決辦結幫助大家更好的攻擊面對web攻擊，感興趣的式法總朋友可以了解下。
一個(gè)網(wǎng)站建立以后，端常如果不注意安全方(′?｀*)面的見(jiàn)受及解決辦結問(wèn)題，很容易被人攻擊，攻擊下面就討論一下幾種漏洞情況和防止攻擊的式法總辦法。
一、端常SQL注入
所謂SQL注入，見(jiàn)受及解決辦結??就是攻擊通過(guò)把SQL命令插入??到Web表單提交(jiao)或輸入域名或頁(yè)面請求的(de)查詢(xún)字符串，最終達到欺騙服務(wù)器執行惡(/ω＼)意的式法總SQL命令。具體來(lái)說(shuō)，端常它是見(jiàn)受及解決辦結利用現有應用程序，將（惡意）的攻擊SQL命令注入到后臺數據庫引擎執行的能力，它可以通過(guò)在Web表單中輸入（惡意）SQL語(yǔ)句得到一個(gè)存在安全漏(′?ω?`)洞的網(wǎng)站上的數據庫，而不是按照設計者意圖去執行SQL語(yǔ)句。比如先前的很多影視網(wǎng)站泄露VIP會(huì )員密碼大多就是通過(guò)WEB表單遞交查詢(xún)字符暴出的，這類(lèi)表單特別容易??受到SQL???注入(′?_?`)式攻擊。
原理：
SQL注入攻擊指的是通過(guò)構建特殊的輸入作為參數傳入??Web應用程序，(′；д；`)而這些輸入大都是SQL語(yǔ)法里的一ヾ(′?｀)?些組合，通過(guò)執行SQL語(yǔ)句進(jìn)而執行攻擊者所要的操作，其主要原因是程序沒(méi)有細致地過(guò)濾用戶(hù)輸入的數據，致使非法數據侵入系統。
根據相關(guān)技術(shù)原理，SQL(??ヮ?)?*:???注入可以分為平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致；后者主要是由于程序員對輸入未進(jìn)行細致地過(guò)濾，從而執行了非法的數據查詢(xún)?；诖?，SQL注入的產(chǎn)生原因通常表現在以下幾方面：
②不安全的數據庫配置；
③不合理的查詢(xún)集處理；
④不當的錯誤處理；
⑤轉義字符處理不合適；
⑥多個(gè)提交處理不當。
防護：
1.永遠不要信任用戶(hù)的輸入。對用戶(hù)的輸入進(jìn)行校驗，可以通過(guò)正則表達式，或限制長(cháng)度；對單引號和雙"-"進(jìn)行轉換等。
2.永遠不要ヽ(′▽?zhuān)?ノ使用動(dòng)態(tài)拼裝sql，可以使用參數化(O_O)的sql或者直接使用存儲過(guò)程進(jìn)行數據查詢(xún)存取。
3.ヽ(′▽?zhuān)?ノ永遠不要(yao)使用管理員權限的(de)數據(?Д?)庫連接，為每個(gè)應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能??少的提示，最好使用自定義的錯誤信息對原始錯誤信息進(jìn)行包裝
6.sql注入的檢測方法一般采取輔助軟件或網(wǎng)站平臺來(lái)檢測，軟件一般采用sql注入檢測工具jsky，MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入，XSS攻擊等。
二、跨站腳本攻ヾ(＾-＾)ノ擊(XSS，Cross-site scripting)
跨站腳本攻擊（XSS）是(╯°□°）╯︵ ┻━┻最常見(jiàn)和基本的攻擊WEB網(wǎng)站的方法。攻擊者在網(wǎng)頁(yè)上發(fā)布包含攻擊性代碼的數據。當瀏覽者看到此網(wǎng)頁(yè)時(shí)，特定的腳本就會(huì )(hui)以瀏覽者用戶(hù)的??身份和權限來(lái)執行。通過(guò)XSS可以比較容易地修改用戶(hù)數據、竊取用戶(hù)信息，以及造成其它類(lèi)型的攻擊，例如CSRF攻擊。
出錯的頁(yè)面的漏洞也可能造成XSS攻擊，比如頁(yè)面/gi(′_｀)ft/giftList.htm?page=2找不到( ?ヮ?)。出錯頁(yè)面直接把該url原樣輸出，如果攻擊者在url后面加上攻擊代碼發(fā)給受害者，就有可能出現XSS攻擊
三、 跨站請求偽造攻擊（CSRF)
跨站請求偽造（CSRF，Cros??s-site request forgeヾ(＾-＾)ノry）是另一種常見(jiàn)的攻擊。攻擊者通過(guò)各種方法偽造一個(gè)請求，模仿用戶(hù)提交表單的行為，??從而達到修改用戶(hù)的數據，或者執行特定任務(wù)的目的。為了假冒用戶(hù)的??身份ヽ(′?｀)ノ，CSRF攻擊常常和XSS攻擊配合起來(lái)做，但也可以通過(guò)其它手段，例如誘使用戶(hù)點(diǎn)擊一個(gè)包含攻擊的鏈接。??(?_?;)
解決的思路有：
1.采用POST請求，增加攻擊的難度.用戶(hù)點(diǎn)擊一個(gè)(ge)鏈接就可以發(fā)起GET類(lèi)型的請求。而POST請求相對比較難，攻擊者往往需要借助javascript才能實(shí)現
2.對請求進(jìn)行認證，確保該請求確實(shí)是用戶(hù)本人填寫(xiě)表單并提交的，而不是第三者偽造的.具體可以在會(huì )話(huà)中增加token,確?？吹叫畔⒑吞峤恍畔⒌氖?shi)同一個(gè)人
四、Http Heads攻擊
凡是用瀏覽器查看任何WEB網(wǎng)站，無(wú)(wu)論你的WEB網(wǎng)站采用(yong)何種技術(shù)和框架，都用到了HTTP協(xié)議。HTTP協(xié)議在Response header和content之間，有一個(gè)空行，即兩組CRLF（0x0(′▽?zhuān)?D 0A）字符。這個(gè)空行標志??著(zhù)heade(′?｀)rs的結束(′ω｀)和content的開(kāi)始。“聰明”的攻擊者可以利用這一點(diǎn)。只要攻擊者有辦法將任意字符“注入”到 headers中，這種攻擊就可以發(fā)生。
以登陸為例：有這樣一個(gè)url：http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
HTTP/1.1 302 Moved Tempo(??-)?rarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passt(/ω＼)hrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
假如把URL修改一下，變成這個(gè)樣子：
http://localhost/login?page=http%3A%2F??%2Flocalhost%2Fcheckout%??0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E
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┐(′?｀)┌ mo┐(′д｀)┌d_bwlimited/1.4 Fr??ontPage/5.0.2.2635
Location: http://localhost??/??checkout<CRLF>
<CRLF>
<script>alert('hello')</scr??ipt&gヽ(′▽?zhuān)?ノt;
這個(gè)頁(yè)面可能會(huì )意外地執??行隱藏在URL中的javascript。類(lèi)似的情況不僅發(fā)生在(zai)重定向（L??(???)o??cation header）上，??也有可能發(fā)生在其它headers中，如Set-(?????)Cookie header。這種攻擊如果成功的話(huà)，可以做很多事，例如：執行腳本、設置額外的cookie（<CRLF>Set-Cookie: evil=value）等。
避免這種攻擊的方法，就是過(guò)濾所有(′ω｀)的response headers，除去header中出現的非法字符，尤其是CRLF。
服務(wù)器一般會(huì )限制request headers的大小。例如Ap??ache se??rver??默認限制request header為8K。如果超過(guò)8K，Aap??che Server將會(huì )返回400 Bad Request響應：
五、Cookie攻擊
通過(guò)JavaScript非常容易訪(fǎng)問(wèn)到當前網(wǎng)站(???)的cookie。你可以打開(kāi)任何網(wǎng)站，然后在瀏覽器地址欄中輸入：javascript:alert(doucment.cookie),立刻就可以看到當前站點(diǎn)的cookie（如果有的話(huà)）。攻擊者可以利用這個(gè)特性來(lái)取得你的關(guān)鍵信息。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的JavaScript腳本，取得你的cookie。假設這個(gè)網(wǎng)站(′▽?zhuān)?僅依賴(lài)cookiヽ(′ー｀)ノe來(lái)驗證用戶(hù)身份，那么攻擊者就??可以假冒你的身份來(lái)做一些事情。
現在多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡有這個(gè)標志的cookie(′?｀)就無(wú)法通過(guò)J??avaScript來(lái)取得,如果能在關(guān)鍵cookie上打上這個(gè)標(′▽?zhuān)?)記，就會(huì )大大增強cookie的安全性
六、重定向攻擊
一種常用的??攻擊手(shou)段是&ldqヽ(′ー｀)ノuo;釣魚(yú)”。釣??魚(yú)攻擊者，通常會(huì )發(fā)送給受害者一個(gè)合法鏈接，當鏈接被點(diǎn)擊時(shí)，用戶(hù)被導向一個(gè)似是而非的非法網(wǎng)站，從而達到騙取用戶(hù)信任、竊取用戶(hù)資料的目的。為防止( ?° ?? ?°)這種行為，我們必須(xu)對所有的重定向操作進(jìn)行審核，以避免重定向到一個(gè)危險的地方。常見(jiàn)解決方(fang)案是白名單，將合法的要重定向的u??r??l加到白名單中，非白名單上的域名重定向時(shí)拒之。第二種解決方案是重ヽ(′▽?zhuān)?ノ定向token，在合法的url上加上token，重定向時(shí)進(jìn)行驗證。
七、上傳文件攻擊
1.文件名攻擊，上傳的文件采用上傳之前的文件名，可能造成：客戶(hù)端和服務(wù)端字符碼不兼容，導致文件名亂碼問(wèn)題；文件名包含腳本，從而造成攻擊。
3.文件內容攻擊，IE6有一個(gè)很?chē)乐??的問(wèn)題，它不信任服務(wù)器所發(fā)送的content type(?????)，而是自動(dòng)根據文件內容來(lái)識別文件的類(lèi)型，并根據所識別的類(lèi)型來(lái)顯示或執行文件。如果上傳一個(gè)gif文件，在文件末尾放一段js攻擊腳本，就有可能被執行。這種攻擊，它的文件名和content type看起來(lái)都是合法的gif圖片，然而其內容卻包含腳本，這樣的攻擊無(wú)法用文件名過(guò)濾(???)來(lái)排??除，而是必須掃描其文件內容，才能識別。
以(yi)上就是WEB前端常見(jiàn)受攻擊方式及解決辦法總結的詳細內容，更多關(guān)于web??前端受攻擊及解決辦法的資料請關(guān)注腳本之家其它相關(guān)文章！
文章轉自腳本之家，原文鏈接：https://www.jb51.net/article/191635.htm
