時間:2021-08-27 點擊: 次 來源:網絡 作者:佚名 - 小 + 大
這篇文章主要介紹了WEB前端常見受攻擊方式及解決辦法總結,文中講解非常細致,幫助大家更好的面對web攻擊,感興趣的朋友可以了解下。 一個網站建立以后,如果不注意安全方面的問題,很容易被人攻擊,下面就討論一下幾種漏洞情況和防止攻擊的辦法。 一、SQL注入 所謂SQL注入,就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙服務器執行惡意的SQL命令。具體來說,它是利用現有應用程序,將(惡意)的SQL命令注入到后臺數據庫引擎執行的能力,它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的數據庫,而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字符暴出的,這類表單特別容易受到SQL注入式攻擊。 原理: SQL注入攻擊指的是通過構建特殊的輸入作為參數傳入Web應用程序,而這些輸入大都是SQL語法里的一些組合,通過執行SQL語句進而執行攻擊者所要的操作,其主要原因是程序沒有細致地過濾用戶輸入的數據,致使非法數據侵入系統。 根據相關技術原理,SQL注入可以分為平臺層注入和代碼層注入。前者由不安全的數據庫配置或數據庫平臺的漏洞所致;后者主要是由于程序員對輸入未進行細致地過濾,從而執行了非法的數據查詢。基于此,SQL注入的產生原因通常表現在以下幾方面: ①不當的類型處理; ②不安全的數據庫配置; ③不合理的查詢集處理; ④不當的錯誤處理; ⑤轉義字符處理不合適; ⑥多個提交處理不當。 防護: 1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗,可以通過正則表達式,或限制長度;對單引號和雙"-"進行轉換等。 2.永遠不要使用動態拼裝sql,可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。 3.永遠不要使用管理員權限的數據庫連接,為每個應用使用單獨的權限有限的數據庫連接。 4.不要把機密信息直接存放,加密或者hash掉密碼和敏感的信息。 5.應用的異常信息應該給出盡可能少的提示,最好使用自定義的錯誤信息對原始錯誤信息進行包裝 6.sql注入的檢測方法一般采取輔助軟件或網站平臺來檢測,軟件一般采用sql注入檢測工具jsky,MDCSOFT SCAN等。采用MDCSOFT-IPS可以有效的防御SQL注入,XSS攻擊等。 二、跨站腳本攻擊(XSS,Cross-site scripting) 跨站腳本攻擊(XSS)是最常見和基本的攻擊WEB網站的方法。攻擊者在網頁上發布包含攻擊性代碼的數據。當瀏覽者看到此網頁時,特定的腳本就會以瀏覽者用戶的身份和權限來執行。通過XSS可以比較容易地修改用戶數據、竊取用戶信息,以及造成其它類型的攻擊,例如CSRF攻擊。 常見解決辦法:確保輸出到HTML頁面的數據以HTML的方式被轉義 出錯的頁面的漏洞也可能造成XSS攻擊,比如頁面/gift/giftList.htm?page=2找不到。出錯頁面直接把該url原樣輸出,如果攻擊者在url后面加上攻擊代碼發給受害者,就有可能出現XSS攻擊 三、 跨站請求偽造攻擊(CSRF) 跨站請求偽造(CSRF,Cross-site request forgery)是另一種常見的攻擊。攻擊者通過各種方法偽造一個請求,模仿用戶提交表單的行為,從而達到修改用戶的數據,或者執行特定任務的目的。為了假冒用戶的身份,CSRF攻擊常常和XSS攻擊配合起來做,但也可以通過其它手段,例如誘使用戶點擊一個包含攻擊的鏈接。 解決的思路有: 1.采用POST請求,增加攻擊的難度.用戶點擊一個鏈接就可以發起GET類型的請求。而POST請求相對比較難,攻擊者往往需要借助javascript才能實現 2.對請求進行認證,確保該請求確實是用戶本人填寫表單并提交的,而不是第三者偽造的.具體可以在會話中增加token,確保看到信息和提交信息的是同一個人 四、Http Heads攻擊 凡是用瀏覽器查看任何WEB網站,無論你的WEB網站采用何種技術和框架,都用到了HTTP協議。HTTP協議在Response header和content之間,有一個空行,即兩組CRLF(0x0D 0A)字符。這個空行標志著headers的結束和content的開始。“聰明”的攻擊者可以利用這一點。只要攻擊者有辦法將任意字符“注入”到 headers中,這種攻擊就可以發生。 以登陸為例:有這樣一個url:http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex 當登錄成功以后,需要重定向回page參數所指定的頁面。下面是重定向發生時的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修改一下,變成這個樣子: http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E 那么重定向發生時的reponse會變成下面的樣子: 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/checkout<CRLF> <CRLF> <script>alert('hello')</script> 這個頁面可能會意外地執行隱藏在URL中的javascript。類似的情況不僅發生在重定向(Location header)上,也有可能發生在其它headers中,如Set-Cookie header。這種攻擊如果成功的話,可以做很多事,例如:執行腳本、設置額外的cookie(<CRLF>Set-Cookie: evil=value)等。 避免這種攻擊的方法,就是過濾所有的response headers,除去header中出現的非法字符,尤其是CRLF。 服務器一般會限制request headers的大小。例如Apache server默認限制request header為8K。如果超過8K,Aapche Server將會返回400 Bad Request響應: 對于大多數情況,8K是足夠大的。假設應用程序把用戶輸入的某內容保存在cookie中,就有可能超過8K.攻擊者把超過8k的header鏈接發給受害 者,就會被服務器拒絕訪問.解決辦法就是檢查cookie的大小,限制新cookie的總大寫,減少因header過大而產生的拒絕訪問攻擊。 五、Cookie攻擊 通過JavaScript非常容易訪問到當前網站的cookie。你可以打開任何網站,然后在瀏覽器地址欄中輸入:javascript:alert(doucment.cookie),立刻就可以看到當前站點的cookie(如果有的話)。攻擊者可以利用這個特性來取得你的關鍵信息。例如,和XSS攻擊相配合,攻擊者在你的瀏覽器上執行特定的JavaScript腳本,取得你的cookie。假設這個網站僅依賴cookie來驗證用戶身份,那么攻擊者就可以假冒你的身份來做一些事情。 現在多數瀏覽器都支持在cookie上打上HttpOnly的標記,凡有這個標志的cookie就無法通過JavaScript來取得,如果能在關鍵cookie上打上這個標記,就會大大增強cookie的安全性 六、重定向攻擊 一種常用的攻擊手段是“釣魚”。釣魚攻擊者,通常會發送給受害者一個合法鏈接,當鏈接被點擊時,用戶被導向一個似是而非的非法網站,從而達到騙取用戶信任、竊取用戶資料的目的。為防止這種行為,我們必須對所有的重定向操作進行審核,以避免重定向到一個危險的地方。常見解決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之。第二種解決方案是重定向token,在合法的url上加上token,重定向時進行驗證。 七、上傳文件攻擊 1.文件名攻擊,上傳的文件采用上傳之前的文件名,可能造成:客戶端和服務端字符碼不兼容,導致文件名亂碼問題;文件名包含腳本,從而造成攻擊。 2.文件后綴攻擊,上傳的文件的后綴可能是exe可執行程序、js腳本等文件,這些程序可能被執行于受害者的客戶端,甚至可能執行于服務器上。因此我們必須過濾文件名后綴,排除那些不被許可的文件名后綴。 3.文件內容攻擊,IE6有一個很嚴重的問題,它不信任服務器所發送的content type,而是自動根據文件內容來識別文件的類型,并根據所識別的類型來顯示或執行文件。如果上傳一個gif文件,在文件末尾放一段js攻擊腳本,就有可能被執行。這種攻擊,它的文件名和content type看起來都是合法的gif圖片,然而其內容卻包含腳本,這樣的攻擊無法用文件名過濾來排除,而是必須掃描其文件內容,才能識別。
|
上一篇:扁平化設計與Material Design區別在哪里?
下一篇:沒有了