不知道大家知不知道其實(shí)web應(yīng)用也是非常脆弱的，所以對于web攻擊也是非常簡單的，下面小編就為大家介紹如何正確的防范web攻擊。

SQL注入攻擊

SQL注入攻擊，這個(gè)是最常聊到的話題，使用過Java的開發(fā)人員，第一個(gè)反應(yīng)就是一定要使用預(yù)編譯的PrepareStatement，是吧?

什么是SQL注入攻擊

攻擊者在HTTP請求中注入惡意的SQL代碼，服務(wù)器使用參數(shù)構(gòu)建數(shù)據(jù)庫SQL命令時(shí)，惡意SQL被一起構(gòu)造，并在數(shù)據(jù)庫中執(zhí)行。

用戶登錄，輸入用戶名 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時(shí)使用參數(shù)構(gòu)造的方式，就會出現(xiàn)

select * from user where name = 'lianggzone' and password = '' or '1'='1'

不管用戶名和密碼是什么內(nèi)容，使查詢出來的用戶列表不為空。

現(xiàn)在還會存在SQL注入攻擊么

這個(gè)問題在使用了預(yù)編譯的PrepareStatement后，安全性得到了很大的提高，但是真實(shí)情況下，很多同學(xué)并不重視，還是會留下漏洞的。舉個(gè)例子，看看，大家的代碼中對 sql 中 in 操作，使用了預(yù)編譯，還是仍然還是通過字符串拼接呢?

如何防范SQL注入攻擊

使用預(yù)編譯的PrepareStatement是必須的，但是一般我們會從兩個(gè)方面同時(shí)入手。

Web端 有效性檢驗(yàn)。 限制字符串輸入的長度。 服務(wù)端 不用拼接SQL字符串。 使用預(yù)編譯的PrepareStatement。 有效性檢驗(yàn)。(為什么服務(wù)端還要做有效性檢驗(yàn)?第一準(zhǔn)則，外部都是不可信的，防止攻擊者繞過Web端請求) 過濾SQL需要的參數(shù)中的特殊字符。比如單引號、雙引號。XSS攻擊什么是XSS攻擊

跨站點(diǎn)腳本攻擊，指攻擊者通過篡改網(wǎng)頁，嵌入惡意腳本程序，在用戶瀏覽網(wǎng)頁時(shí)，控制用戶瀏覽器進(jìn)行惡意操作的一種攻擊方式。

假設(shè)頁面上有一個(gè)表單

<input  type="text" name="name" value="梁桂釗"/>

如果，用戶輸入的不是一個(gè)正常的字符串，而是

"/><script>alert("haha")</script><!-

此時(shí)，頁面變成下面的內(nèi)容，在輸入框input的后面帶上了一段腳本代碼。

<input  type="text" name="name" value="梁桂釗"/><script>alert("haha")</script><!-"/>

這端腳本程序只是彈出一個(gè)消息框，并不會造成什么危害，攻擊的威力取決于用戶輸入了什么樣的腳本，只要稍微修改，便可使攻擊極具攻擊性。

XSS攻擊有多可怕

蠻早之前，我曾經(jīng)找了幾個(gè)網(wǎng)站做個(gè)測試，其實(shí)大家對XSS攻擊的防范還是不夠，都成功的注入了測試腳本。

甚至，還有攻擊者提交惡意的javascript代碼的評論信息或者反饋信息(這些信息，正?？蛻舳藳]有做xss校驗(yàn)，會存在客戶端注入問題)，所有訪問者訪問該內(nèi)容時(shí)，都會執(zhí)行這段惡意的javascript代碼。

如何防范XSS攻擊 前端，服務(wù)端，同時(shí)需要字符串輸入的長度限制。 前端，服務(wù)端，同時(shí)需要對HTML轉(zhuǎn)義處理。將其中的”<”,”>”等特殊字符進(jìn)行轉(zhuǎn)義編碼。CSRF攻擊什么是CSRF攻擊

跨站點(diǎn)請求偽造，指攻擊者通過跨站請求，以合法的用戶的身份進(jìn)行非法操作?？梢赃@么理解CSRF攻擊：攻擊者盜用你的身份，以你的名義向第三方網(wǎng)站發(fā)送惡意請求。CRSF能做的事情包括利用你的身份發(fā)郵件，發(fā)短信，進(jìn)行交易轉(zhuǎn)賬，甚至盜取賬號信息。

如何防范CSRF攻擊 安全框架，例如Spring Security。 token機(jī)制。在HTTP請求中進(jìn)行token驗(yàn)證，如果請求中沒有token或者token內(nèi)容不正確，則認(rèn)為CSRF攻擊而拒絕該請求。 驗(yàn)證碼。通常情況下，驗(yàn)證碼能夠很好的遏制CSRF攻擊，但是很多情況下，出于用戶體驗(yàn)考慮，驗(yàn)證碼只能作為一種輔助手段，而不是最主要的解決方案。 referer識別。在HTTP Header中有一個(gè)字段Referer，它記錄了HTTP請求的來源地址。如果Referer是其他網(wǎng)站，就有可能是CSRF攻擊，則拒絕該請求。但是，服務(wù)器并非都能取到Referer。很多用戶出于隱私保護(hù)的考慮，限制了Referer的發(fā)送。在某些情況下，瀏覽器也不會發(fā)送Referer，例如HTTPS跳轉(zhuǎn)到HTTP。文件上傳漏洞什么是文件上傳漏洞

文件上傳漏洞，指的是用戶上傳一個(gè)可執(zhí)行的腳本文件，并通過此腳本文件獲得了執(zhí)行服務(wù)端命令的能力。

許多第三方框架、服務(wù)，都曾經(jīng)被爆出文件上傳漏洞，比如很早之前的Struts2，以及富文本編輯器等等，可能被一旦被攻擊者上傳惡意代碼，有可能服務(wù)端就被人黑了。

如何防范文件上傳漏洞 文件上傳的目錄設(shè)置為不可執(zhí)行。 判斷文件類型。在判斷文件類型的時(shí)候，可以結(jié)合使用MIME Type，后綴檢查等方式。因?yàn)閷τ谏蟼魑募?，不能簡單地通過后綴名稱來判斷文件的類型，因?yàn)楣粽呖梢詫⒖蓤?zhí)行文件的后綴名稱改為圖片或其他后綴類型，誘導(dǎo)用戶執(zhí)行。 對上傳的文件類型進(jìn)行白名單校驗(yàn)，只允許上傳可靠類型。 上傳的文件需要進(jìn)行重新命名，使攻擊者無法猜想上傳文件的訪問路徑，將極大地增加攻擊成本，同時(shí)向shell.php.rar.ara這種文件，因?yàn)橹孛鵁o法成功實(shí)施攻擊。 限制上傳文件的大小。 單獨(dú)設(shè)置文件服務(wù)器的域名。訪問控制

一般來說，“基于URL的訪問控制”是最常見的。

垂直權(quán)限管理

訪問控制實(shí)際上是建立用戶與權(quán)限之間的對應(yīng)關(guān)系，即“基于角色的訪問控制”，RBAC。不同角色的權(quán)限有高低之分。高權(quán)限角色訪問低權(quán)限角色的資源往往是被允許的，而低權(quán)限角色訪問高權(quán)限的資源往往被禁止的。在配置權(quán)限時(shí)，應(yīng)當(dāng)使用“最小權(quán)限原則”，并使用“默認(rèn)拒絕”的策略，只對有需要的主體單獨(dú)配置”允許”的策略，這在很多時(shí)候能夠避免發(fā)生“越權(quán)訪問”。

例如，Spring Security， Apache Shiro都可以建立垂直權(quán)限管理。

水平權(quán)限管理

水平權(quán)限問題在同一個(gè)角色上，系統(tǒng)只驗(yàn)證了訪問數(shù)據(jù)的角色，沒有對角色內(nèi)的用戶做細(xì)分，由于水平權(quán)限管理是系統(tǒng)缺乏一個(gè)數(shù)據(jù)級的訪問控制所造成的，因此水平權(quán)限管理又可以稱之為“基于數(shù)據(jù)的訪問控制”。

舉個(gè)理解，比如我們之前的一個(gè)助手產(chǎn)品，客戶端用戶刪除評論功能，如果沒有做水平權(quán)限管理，即設(shè)置只有本人才可以刪除自己的評論，那么用戶通過修改評論id就可以刪除別人的評論這個(gè)就存在危險(xiǎn)的越權(quán)操作。

這個(gè)層面，基本需要我們業(yè)務(wù)層面去處理，但是這個(gè)也是最為經(jīng)常遺落的安全點(diǎn)。

總結(jié)

上面列舉的幾個(gè)話題，都是我在開發(fā)過程中，遇到的比較常見的Web安全話題，以及一些防范方案，需要我們在開發(fā)過程中及時(shí)規(guī)避，而不是依靠安全人員或者真正用戶，甚至惡意的攻擊者幫我們?nèi)グl(fā)現(xiàn)問題。當(dāng)然，還有很多Web安全話題，例如遠(yuǎn)程執(zhí)行漏洞、拒絕服務(wù)攻擊、Session保持攻擊等等，如果讀者對于安全方面有興趣，可以閱讀 吳翰清 的 《白帽子講Web安全》， 值得推薦。

推薦文章：

多層防護(hù)機(jī)制應(yīng)對防范勒索軟件的威脅

詳解網(wǎng)絡(luò)安全：不僅要通過去，還要曉未來

詳解與DirectAccess有關(guān)的10件事情

最新評論