如何防范常見(jiàn)的 Web 攻擊

今天，從開(kāi)發(fā)人員的角度，并結(jié)合我在開(kāi)發(fā)過(guò)程中遇到的問(wèn)題，說(shuō)說(shuō)《如何防范常見(jiàn)的Web攻擊》話題。

SQL注入攻擊

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

什么是SQL注入攻擊？

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

用戶登錄，輸入用戶名 lianggzone，密碼 ‘ or ‘1’=’1 ，如果此時(shí)使用參數(shù)構(gòu)造的方式，就會(huì)出現(xiàn)select * from user where name = 'lianggzone' and password = '' or '1'='1'，不管用戶名和密碼是什么內(nèi)容，使查詢出來(lái)的用戶列表不為空。

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

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

如何防范SQL注入攻擊？

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

1. 不用拼接SQL字符串。

2. 使用預(yù)編譯的PrepareStatement。

3. 有效性檢驗(yàn)。(為什么服務(wù)端還要做有效性檢驗(yàn)?第一準(zhǔn)則，外部都是不可信的，防止攻擊者繞過(guò)Web端請(qǐng)求)

4. 過(guò)濾SQL需要的參數(shù)中的特殊字符。比如單引號(hào)、雙引號(hào)。

XSS攻擊

什么是XSS攻擊

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

假設(shè)頁(yè)面上有一個(gè)表單如果，用戶輸入的不是一個(gè)正常的字符串，而是"/>，此時(shí)，頁(yè)面變成下面的內(nèi)容，在輸入框input的后面帶上了一段腳本代碼。

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

XSS攻擊有多可怕

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

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

如何防范XSS攻擊

1. 前端，服務(wù)端，同時(shí)需要字符串輸入的長(zhǎng)度限制。

2. 前端，服務(wù)端，同時(shí)需要對(duì)HTML轉(zhuǎn)義處理。將其中的”<”,”>”等特殊字符進(jìn)行轉(zhuǎn)義編碼。

CSRF攻擊

什么是CSRF攻擊

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

如何防范CSRF攻擊

1. 安全框架，例如Spring Security。

2. token機(jī)制。在HTTP請(qǐng)求中進(jìn)行token驗(yàn)證，如果請(qǐng)求中沒(méi)有token或者token內(nèi)容不正確，則認(rèn)為CSRF攻擊而拒絕該請(qǐng)求。

3. 驗(yàn)證碼。通常情況下，驗(yàn)證碼能夠很好的遏制CSRF攻擊，但是很多情況下，出于用戶體驗(yàn)考慮，驗(yàn)證碼只能作為一種輔助手段，而不是最主要的解決方案。

4. referer識(shí)別。在HTTP Header中有一個(gè)字段Referer，它記錄了HTTP請(qǐng)求的來(lái)源地址。如果Referer是其他網(wǎng)站，就有可能是CSRF攻擊，則拒絕該請(qǐng)求。但是，服務(wù)器并非都能取到Referer。很多用戶出于隱私保護(hù)的考慮，限制了Referer的發(fā)送。在某些情況下，瀏覽器也不會(huì)發(fā)送Referer，例如HTTPS跳轉(zhuǎn)到HTTP。

文件上傳漏洞

什么是文件上傳漏洞

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

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

如何防范文件上傳漏洞

1. 文件上傳的目錄設(shè)置為不可執(zhí)行。

2. 判斷文件類型。在判斷文件類型的時(shí)候，可以結(jié)合使用MIME Type，后綴檢查等方式。因?yàn)閷?duì)于上傳文件，不能簡(jiǎn)單地通過(guò)后綴名稱來(lái)判斷文件的類型，因?yàn)楣粽呖梢詫⒖蓤?zhí)行文件的后綴名稱改為圖片或其他后綴類型，誘導(dǎo)用戶執(zhí)行。

3. 對(duì)上傳的文件類型進(jìn)行白名單校驗(yàn)，只允許上傳可靠類型。

4. 上傳的文件需要進(jìn)行重新命名，使攻擊者無(wú)法猜想上傳文件的訪問(wèn)路徑，將極大地增加攻擊成本，同時(shí)向shell.php.rar.ara這種文件，因?yàn)橹孛鵁o(wú)法成功實(shí)施攻擊。

5. 限制上傳文件的大小。

6. 單獨(dú)設(shè)置文件服務(wù)器的域名。

訪問(wèn)控制

一般來(lái)說(shuō)，“基于URL的訪問(wèn)控制”是最常見(jiàn)的。

垂直權(quán)限管理

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

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

水平權(quán)限管理

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

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

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