當(dāng)前位置：首頁 > 编程资源 > 综合教程 >内容正文

综合教程

常见21种漏洞编码安全规范及解决方案

發(fā)布時(shí)間：2023/12/3 综合教程 35 生活家

生活随笔收集整理的這篇文章主要介紹了常见21种漏洞编码安全规范及解决方案小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.

常見21種漏洞編碼安全規(guī)范

1.sql注入
- 1.1風(fēng)險(xiǎn)描述
- 1.2漏洞示例
- 1.3解決方案
2.跨站腳本攻擊(XSS)
- 2.1風(fēng)險(xiǎn)描述
- 2.2漏洞示例
- 2.3解決方案
3.任意文件下載
- 3.1風(fēng)險(xiǎn)描述
- 3.2漏洞示例
- 3.3解決方案
4.任意文件上傳
- 4.1風(fēng)險(xiǎn)描述
- 4.2解決方案
5.越權(quán)操作
- 5.1風(fēng)險(xiǎn)描述
- 5.2漏洞示例
- 5.3解決方案
6.URL跳轉(zhuǎn)
- 6.1風(fēng)險(xiǎn)描述
- 6.2漏洞示例
- 6.3解決方案
7.跨站請(qǐng)求偽造(CSRF)
- 7.1風(fēng)險(xiǎn)描述
- 7.2漏洞示例
- 7.3解決方案
8. 不充分帳戶封鎖
- 8.1風(fēng)險(xiǎn)描述
- 8.2解決方案
9. 密碼安全
- 9.1風(fēng)險(xiǎn)描述
- 9.2漏洞示例
- 9.3解決方案
10.敏感數(shù)據(jù)未加密
- 10.1風(fēng)險(xiǎn)描述
- 10.2漏洞示例
- 10.3解決方案
11. 啟用了不安全的HTTP方法
- 11.1風(fēng)險(xiǎn)描述
- 11.2解決方案
12. 缺少"Content-Security-Policy"頭
- 12.1風(fēng)險(xiǎn)描述
- 12.2解決方案
13. 缺少 X-XSS-Protection 頭
- 13.1漏洞描述
- 13.2解決方案
14. 缺少 X-Content-Type-Options 頭
- 14.1風(fēng)險(xiǎn)描述
- 14.2解決方案
15. 自動(dòng)填寫未對(duì)密碼字段禁用的 HTML 屬性
- 15.1漏洞描述
- 15.2解決方案
16.敏感信息泄露及錯(cuò)誤處理
- 16.1風(fēng)險(xiǎn)描述
- 16.2解決方案
17. 發(fā)現(xiàn)數(shù)據(jù)庫錯(cuò)誤模式
- 17.1風(fēng)險(xiǎn)描述
- 17.2漏洞示例
- 17.3解決方案
18.Cookie安全
- 18.1風(fēng)險(xiǎn)描述
- 18.2解決方法
19. 會(huì)話超時(shí)設(shè)置
- 19.1漏洞描述
- 19.2漏洞示例
- 19.3解決方案
20.日志處理
- 20.1風(fēng)險(xiǎn)描述
- 20.2漏洞示例
- 20.2解決方案
21 HTTP響應(yīng)頭X-Frame-Options
- 21.1風(fēng)險(xiǎn)描述
- 21.2解決方案

1.sql注入

1.1風(fēng)險(xiǎn)描述

SQL注入主要發(fā)生在應(yīng)用程序數(shù)據(jù)庫層面上。程序員在設(shè)計(jì)程序的時(shí)候，沒有對(duì)用戶的輸入進(jìn)行校驗(yàn)，含有特殊字符語句會(huì)被數(shù)據(jù)庫誤認(rèn)為是正常的SQL指令而運(yùn)行，從而使數(shù)據(jù)庫受到攻擊，可能導(dǎo)致數(shù)據(jù)被竊取、更改、刪除，以及進(jìn)一步導(dǎo)致網(wǎng)站被嵌入惡意代碼等危害。

1.2漏洞示例

1.3解決方案

1、檢查變量數(shù)據(jù)類型和格式

如果你的SQL語句是類似where id={$id}這種形式，數(shù)據(jù)庫里所有的id都是數(shù)字，那么就應(yīng)該在SQL被執(zhí)行前，檢查確保變量id是int類型；如果是接受郵箱，那就應(yīng)該檢查并嚴(yán)格確保變量一定是郵箱的格式，其他的類型比如日期、時(shí)間等也是一個(gè)道理?？偨Y(jié)起來：只要是有固定格式的變量，在SQL語句執(zhí)行前，應(yīng)該嚴(yán)格按照固定格式去檢查，確保變量是我們預(yù)想的格式，這樣很大程度上可以避免SQL注入攻擊。

比如，我們前面接受username參數(shù)例子中，我們的產(chǎn)品設(shè)計(jì)應(yīng)該是在用戶注冊(cè)的一開始，就有一個(gè)用戶名的規(guī)則，比如5-20個(gè)字符，只能由大小寫字母、數(shù)字以及一些安全的符號(hào)組成，不包含特殊字符。此時(shí)我們應(yīng)該有一個(gè)check_username的函數(shù)來進(jìn)行統(tǒng)一的檢查。不過，仍然有很多例外情況并不能應(yīng)用到這一準(zhǔn)則，比如文章發(fā)布系統(tǒng)，評(píng)論系統(tǒng)等必須要允許用戶提交任意字符串的場景，這就需要采用過濾等其他方案了。

2、添加全局過濾器，過濾特殊字符。

Web.xml

Web.xml
<filter ><filter-name>SQLFilter</filter-name>< filter -class>*.SQLFilte</ filter -class >
</filter >  
<filter-mapping><filter-name> SQLFilter </filter-name><url-pattern> /*</url-pattern>   攔截所有請(qǐng)求
</filter-mapping>
在SQLFilter.java類中：
paramValue= paramValue.replaceAll(“>”, “”)
paramValue= paramValue.replaceAll(“%”,“”)

3、綁定變量，使用預(yù)編譯語句

MySQL的mysql驅(qū)動(dòng)提供了預(yù)編譯語句的支持，不同的程序語言，都分別有使用預(yù)編譯語句的方法。

實(shí)際上，綁定變量使用預(yù)編譯語句是預(yù)防SQL注入的最佳方式，使用預(yù)編譯的SQL語句語義不會(huì)發(fā)生改變，在SQL語句中，變量用問號(hào)?表示，黑客即使本事再大，也無法改變SQL語句的結(jié)構(gòu)。

2.跨站腳本攻擊(XSS)

2.1風(fēng)險(xiǎn)描述

跨站攻擊是因?yàn)榫W(wǎng)站程序?qū)τ脩糨斎脒^濾不足，將用戶輸入的惡意腳本代碼正常執(zhí)行或者提交。攻擊者可利用XSS漏洞獲取用戶cookie值、傳播蠕蟲、篡改頁面或進(jìn)行釣魚等攻擊。

跨站腳本攻擊（XSS），是最普遍的Web應(yīng)用安全漏洞。這類漏洞能夠使得攻擊者嵌入惡意腳本代碼到正常用戶會(huì)訪問到的頁面中，當(dāng)正常用戶訪問該頁面時(shí)，則可導(dǎo)致嵌入的惡意腳本代碼的執(zhí)行，從而達(dá)到惡意攻擊用戶的目的。

攻擊者可以使用戶在瀏覽器中執(zhí)行其預(yù)定義的惡意腳本，其導(dǎo)致的危害可想而知，如劫持用戶會(huì)話，插入惡意內(nèi)容、重定向用戶、使用惡意軟件劫持用戶瀏覽器、繁殖XSS蠕蟲，甚至破壞網(wǎng)站、修改路由器配置信息等。

XSS攻擊又分：反射型攻擊跟持久型攻擊。

第一種XSS攻擊是反射型攻擊，可能通過圖片或者flash的動(dòng)圖之類的誘導(dǎo)你點(diǎn)擊一個(gè)URL鏈接。在這個(gè)URL鏈接里就嵌入他自己的惡意腳本，你點(diǎn)擊URL鏈接之后，URL指向的是黑客自己的服務(wù)器上的一段惡意腳本，然后惡意腳本被返回到你的瀏覽器里就會(huì)運(yùn)行，就可以控制你的瀏覽器里的行為了，比如說腳本可以自動(dòng)讓你關(guān)注某個(gè)用戶ID，然后控制你自動(dòng)發(fā)布一個(gè)帶有病毒的微博等。

另外一種XSS攻擊叫持久型攻擊，舉個(gè)例子，比如某個(gè)論壇、或者社交網(wǎng)站之類的系統(tǒng)，你可以發(fā)布一些帖子，或者是評(píng)論，此時(shí)黑客就可以在里面寫一段惡意腳本，然后把惡意腳本混雜在評(píng)論內(nèi)容里提交到你的網(wǎng)站的數(shù)據(jù)庫里去。后面比如其他用戶在社交網(wǎng)站里瀏覽到了你的這個(gè)評(píng)論，評(píng)論內(nèi)容會(huì)被返回到瀏覽器里去，此時(shí)評(píng)論內(nèi)容是包含惡意js腳本的，馬上惡意腳本運(yùn)行。達(dá)到攻擊的目的。

2.2漏洞示例

點(diǎn)擊搜索訪問接口：
http://…/searchword?word=…
此處參數(shù)在前端為EL表達(dá)式獲取，并且為添加任何過濾，最后直接顯示在頁面。當(dāng)輸入框輸入的參數(shù)為：時(shí)，就會(huì)直接被瀏覽器當(dāng)作腳本執(zhí)行并彈框：

還有一種是將參數(shù)進(jìn)行傳遞并最終存儲(chǔ)到數(shù)據(jù)庫當(dāng)中，因?yàn)閰?shù)在傳遞過程中未經(jīng)過任何有效過濾(或者存在過濾不全，會(huì)被繞過)，作為可信資源存入到數(shù)據(jù)庫中并最終被執(zhí)行。

2.3解決方案

消毒機(jī)制，對(duì)用戶輸入的內(nèi)容進(jìn)行轉(zhuǎn)義，比如說把>轉(zhuǎn)義為&gt之類的，這樣就可以把惡意腳本里的html標(biāo)簽、js代碼之類的東西，都給轉(zhuǎn)義掉，讓這些惡意腳本失效。
HttpOnly方式，如果你在瀏覽器里存放cookie的時(shí)候，可以設(shè)置一個(gè)HttpOnly屬性，比如說存放用戶加密認(rèn)證信息的cookie，這樣的話，在瀏覽器里運(yùn)行的js腳本是被禁止訪問這些HttpOnly cookie的，他就無法竊取你在瀏覽器里存儲(chǔ)的cookie了。

response.setHeader
("Set-Cookie","cookiename=httponlyTest;Path=/;Domain=domainvalue;HTTPOnly");

3.任意文件下載

3.1風(fēng)險(xiǎn)描述

網(wǎng)站在處理用戶下載文件的請(qǐng)求時(shí)，允許用戶提交任意文件路徑，并把服務(wù)器上對(duì)應(yīng)的文件直接發(fā)送給用戶，這將造成任意文件下載威脅。如果服務(wù)器根據(jù)用戶提交的目錄地址，就把目錄下的文件列表發(fā)給用戶，會(huì)造成目錄遍歷安全威脅。惡意用戶會(huì)變換目錄或文件地址，下載服務(wù)器上的敏感文件、數(shù)據(jù)庫鏈接配置文件、網(wǎng)站源代碼等。

3.2漏洞示例

下載功能url：
http://…/downloadFile.action?jpgPath=/download/&jpgName=test.jpg
后端代碼文件路徑和文件名都是從前端獲取，然后執(zhí)行下載操作。

3.3解決方案

1、文件下載時(shí)進(jìn)行過濾，過濾掉 “./”、“…/”、“%”等，代碼如下：

2、對(duì)下載的文件路徑進(jìn)行嚴(yán)格控制，只允許下載某部分目錄下的文件：

3、對(duì)下載文件后綴名做嚴(yán)格控制：

4、下載文件之前做權(quán)限判斷，判斷用戶是否有下載該文件的權(quán)限?？山⑽募酌麊?#xff0c;不屬于白名單內(nèi)，不允許下載。
5、使用ID替換文件夾和文件名，使得整個(gè)輸入由路徑名變?yōu)橐粋€(gè)表示ID的字符串，這種方法很容易驗(yàn)證它的有效性。

4.任意文件上傳

4.1風(fēng)險(xiǎn)描述

應(yīng)用程序在處理用戶上傳的文件時(shí)，沒有判斷文件是否在允許的范圍內(nèi)，就把文件保存在服務(wù)器上，導(dǎo)致惡意用戶可以上傳任意文件，甚至上傳腳本木馬到服務(wù)器上，直接控制服務(wù)器。文件上傳漏洞的利用是有限制條件的，首先要能夠成功上傳木馬文件，其次上傳的木馬文件能夠被執(zhí)行，最后就是上傳文件的路徑必須可知。

4.2解決方案

對(duì)上傳文件的類型進(jìn)行檢測，設(shè)置白名單進(jìn)行過濾。（建議禁止上傳jsp、jspx、php、asp、aspx等格式的文件）。
對(duì)上傳文件的內(nèi)容及大小進(jìn)行檢測。

5.越權(quán)操作

5.1風(fēng)險(xiǎn)描述

越權(quán)漏洞是比較常見的漏洞類型，越權(quán)漏洞可以理解為，一個(gè)正常的用戶A通常只能夠?qū)ψ约旱囊恍┬畔⑦M(jìn)行增刪改查，但是由于程序員的一時(shí)疏忽未對(duì)信息進(jìn)行增刪改查的時(shí)候沒有進(jìn)行一個(gè)判斷，判斷所需要操作的信息是否屬于對(duì)應(yīng)的用戶，可以導(dǎo)致用戶A可以操作其他人的信息。?

權(quán)限攻擊可以分為水平權(quán)限攻擊和垂直權(quán)限攻擊。

水平權(quán)限攻擊，也叫作訪問控制攻擊。Web應(yīng)用程序接收到用戶請(qǐng)求，修改某條數(shù)據(jù)時(shí)，沒有判斷數(shù)據(jù)的所屬人，或者在判斷數(shù)據(jù)所屬人時(shí)從用戶提交的表單參數(shù)中獲取了userid。導(dǎo)致攻擊者可以自行修改userid修改不屬于自己的數(shù)據(jù)。

垂直權(quán)限攻擊又叫做權(quán)限提升攻擊。其原理是由于Web應(yīng)用沒有做權(quán)限控制，或僅僅在菜單上做了權(quán)限控制，導(dǎo)致惡意用戶只要猜測其他管理頁面的URL，就可以訪問或控制其他角色擁有的數(shù)據(jù)或頁面，達(dá)到權(quán)限提升的目的。

5.2漏洞示例

1.水平權(quán)限攻擊

Web應(yīng)用在修改用戶個(gè)人信息時(shí)，從用戶提交的表單中獲取userid，執(zhí)行修改操作：

后端直接從表單參數(shù)列表中獲取userid，修改userid對(duì)應(yīng)的用戶數(shù)據(jù)。

這時(shí)攻擊者可以隨意修改表單的userid：

修改userid后，提交表單，就可能修改了其他用戶的數(shù)據(jù)。

5.3解決方案

1.在進(jìn)行增、刪、改、查等操作時(shí)，需將sessionID和認(rèn)證的token綁定，存放在服務(wù)器的會(huì)話里，不要相信任何客戶端發(fā)來的認(rèn)證和授權(quán)信息，包括消息頭、Cookie、隱藏的表單或者URL參數(shù)。

例如：從用戶的加密認(rèn)證cookie中獲取當(dāng)前用戶id，并且在執(zhí)行的sql語句中加入當(dāng)前用戶id作為條件語句。由于cookie是加密的，所以攻擊者無法修改加密信息。

代碼中通過GetUseridFromCookie方法，從加密的cookie中獲取當(dāng)前用戶的id，并加入判斷。

對(duì)于垂直權(quán)限攻擊，只需要在每個(gè)頁面的加載之前進(jìn)行權(quán)限驗(yàn)證即可。

6.URL跳轉(zhuǎn)

6.1風(fēng)險(xiǎn)描述

應(yīng)用程序接收到用戶提交的URL參數(shù)后，沒有對(duì)參數(shù)做"可信任URL"的驗(yàn)證，就向用戶瀏覽器返回跳轉(zhuǎn)到該URL的指令。惡意攻擊者可以發(fā)送給用戶一個(gè)鏈接，但是用戶打開后，卻來到釣魚網(wǎng)站頁面，將會(huì)導(dǎo)致用戶被釣魚攻擊，賬號(hào)被盜，或賬號(hào)相關(guān)財(cái)產(chǎn)被盜。

6.2漏洞示例

跳轉(zhuǎn)代碼：response.sendRedirect(request.getParameter(“url”));

某應(yīng)用程序有一個(gè)名為"redirect.jsp"的頁面，該頁面的參數(shù)為"url"，攻擊者精心構(gòu)造一個(gè)鏈接將用戶重定向到一個(gè)惡意網(wǎng)站，執(zhí)行釣魚攻擊并安裝惡意程序。

6.3解決方案

1、輸入驗(yàn)證，對(duì)跳轉(zhuǎn)的URL進(jìn)行驗(yàn)證，對(duì)于不合法的跳轉(zhuǎn)URL拒絕跳轉(zhuǎn)訪問。可通過白名單進(jìn)行驗(yàn)證。

2、如果在本網(wǎng)站內(nèi)跳轉(zhuǎn)，則使用相對(duì)路徑，而不要使用絕對(duì)路徑，如在URL的參數(shù)中使用了絕對(duì)路徑，建議在代碼里剝離URL中域名部分，然后再和網(wǎng)站的域名重新結(jié)合成絕對(duì)路徑，再跳轉(zhuǎn)。

3、如果請(qǐng)求允許跳轉(zhuǎn)的對(duì)象只是限制在有限的范圍內(nèi)，可創(chuàng)建一個(gè)匹配的規(guī)則，通過數(shù)字類型的ID來代替跳轉(zhuǎn)到具體的頁面。

7.跨站請(qǐng)求偽造(CSRF)

7.1風(fēng)險(xiǎn)描述

CSRF 是一種攻擊者迫使被攻擊者網(wǎng)頁瀏覽器發(fā)送HTTP 請(qǐng)求到攻擊者所選擇的網(wǎng)站的漏洞。CSRF依靠用戶標(biāo)識(shí)，并利用網(wǎng)站對(duì)用戶標(biāo)識(shí)的信任欺騙用戶瀏覽器發(fā)送HTTP請(qǐng)求給目標(biāo)站點(diǎn)。通過跨站請(qǐng)求偽造漏洞，攻擊者能讓受害用戶修改可以修改的任何數(shù)據(jù)，或者是執(zhí)行允許使用的任何功能。

你這可以這么理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求。CSRF能夠做的事情包括：以你名義發(fā)送郵件，發(fā)消息，盜取你的賬號(hào)，甚至于購買商品，虛擬貨幣轉(zhuǎn)賬…造成的問題包括：個(gè)人隱私泄露以及財(cái)產(chǎn)安全。

下圖簡單闡述了CSRF攻擊的思想：

從上圖可以看出，要完成一次CSRF攻擊，受害者必須依次完成兩個(gè)步驟：

1.登錄受信任網(wǎng)站A，并在本地生成Cookie。
2.在不登出A的情況下，訪問危險(xiǎn)網(wǎng)站B。

7.2漏洞示例

bob在銀行有一筆存款，可以通過請(qǐng)求

http://bank.example/withdraw?account=bob&amount=1000000&for=bob2

把錢轉(zhuǎn)到bob2下。通常情況下，該請(qǐng)求到達(dá)網(wǎng)站后，服務(wù)器會(huì)驗(yàn)證請(qǐng)求是否來自一個(gè)合法的session，并且該session的用戶Bob已登錄。Tom在該銀行也有賬戶，于是他偽造了一個(gè)地址

http://bank.example/withdraw?account=bob&amount=1000000&for=tom ，但是如果直接訪問，服務(wù)器肯定會(huì)識(shí)別出當(dāng)前登錄用戶是mal而不是Bob，不能接受請(qǐng)求。于是通過CSRF攻擊方式，將此鏈接偽造在廣告下，誘使Bob自己點(diǎn)這個(gè)鏈接，那么請(qǐng)求就會(huì)攜帶Bob瀏覽起的cookie一起發(fā)送到銀行，而Bob同時(shí)又登錄了銀行或者剛剛登錄不久session還沒有過期，那服務(wù)器發(fā)現(xiàn)cookie中有Bob的登錄信息，就接收了響應(yīng)，攻擊就成功了。

7.3解決方案

驗(yàn)證Referer：

referer攜帶請(qǐng)求來源，從示例可以看出，受害者發(fā)送非法請(qǐng)求肯定不是在銀行的界面，所以在服務(wù)器通過驗(yàn)證Referer是不是bank.example開始就可以了，這個(gè)方法簡單粗暴。

String referer=request.getHeader("Referer");  if((referer!=null) &&(referer.trim().startsWith("bank.example"))){  chain.doFilter(request, response);  }else{  request.getRequestDispatcher("error.jsp").forward(request,response);  }

在請(qǐng)求參數(shù)中添加token驗(yàn)證：

要抵御跨站點(diǎn)請(qǐng)求偽造就要設(shè)置一個(gè)黑客偽造不了的東西。我們可以在請(qǐng)求參數(shù)中加一個(gè)隨機(jī)token，在服務(wù)器驗(yàn)證這個(gè)token，通過即銷毀重設(shè)。

在HTTP頭中自定義屬性并驗(yàn)證：

這個(gè)方法和上面那個(gè)類似，也是設(shè)置token，只是把token設(shè)置為HTTP頭中的自定義屬性。

8. 不充分帳戶封鎖

8.1風(fēng)險(xiǎn)描述

當(dāng)攻擊者試圖利用不正確的憑證來登錄時(shí)，當(dāng)用戶輸入無效的用戶名和無效的密碼時(shí)，應(yīng)用程序會(huì)分別生成不同的錯(cuò)誤消息。通過利用該行為攻擊者可以通過反復(fù)試驗(yàn)，加暴力破解來發(fā)現(xiàn)應(yīng)用程序的有效用戶名、再繼續(xù)嘗試發(fā)現(xiàn)相關(guān)聯(lián)的密碼。

8.2解決方案

1、登錄的時(shí)候密碼輸入次數(shù)過多時(shí)鎖住用戶一段時(shí)間不能登錄，增加鎖的功能。

2、加入圖形驗(yàn)證碼解決暴力攻擊。

9. 密碼安全

9.1風(fēng)險(xiǎn)描述

密碼安全問題主要存在明文密碼、弱密碼、密碼硬編碼等問題。此類問題均容易導(dǎo)致密碼的泄露。惡意攻擊者可直接讀取獲得明文賬號(hào)密碼，導(dǎo)致其他相關(guān)聯(lián)系統(tǒng)應(yīng)用口令泄漏，擴(kuò)大入侵范圍。

9.2漏洞示例

9.3解決方案

1、配置文件中涉及到需要用戶驗(yàn)證的密碼字段采用加密后保存，禁止明文或使用弱加密算法對(duì)密碼進(jìn)行加密。

2、涉及密碼的配置，需要把密碼設(shè)置具備一定的強(qiáng)度，比如大小寫數(shù)字特殊字等最少3類型8位以上，并且不能包含與用戶名一樣的字符串。

3、程序代碼中涉及到使用密碼的地方，密碼引用不得直接寫入到程序中，需把密碼寫入相應(yīng)的配置文件中。

4、對(duì)硬編碼密碼進(jìn)行模糊化處理，將密碼獲取途徑分散到其他系統(tǒng)或文件各處，增加直接獲取密碼難度。

10.敏感數(shù)據(jù)未加密

10.1風(fēng)險(xiǎn)描述

數(shù)據(jù)加密主要應(yīng)用于數(shù)據(jù)存儲(chǔ)及數(shù)據(jù)傳輸過程中，敏感數(shù)據(jù)未加密進(jìn)行存儲(chǔ)或傳輸，容易導(dǎo)致數(shù)據(jù)泄露，惡意攻擊者可嗅探到明文傳輸?shù)拿舾袛?shù)據(jù)，從而竊取相關(guān)信息。

10.2漏洞示例

1.密碼明文傳輸

2.配置文件密碼明文存儲(chǔ)

10.3解決方案

登陸密碼建議采用不可逆的加密方式對(duì)密碼進(jìn)行加密如MD5。
禁止明文或使用弱加密算法對(duì)密碼進(jìn)行加密，密碼設(shè)置應(yīng)具備一定的強(qiáng)度，大小寫數(shù)字特殊字等最少3類型8位以上，并且不能包含與用戶名一樣的字符串。

11. 啟用了不安全的HTTP方法

11.1風(fēng)險(xiǎn)描述

除標(biāo)準(zhǔn)的GET與POST方法外，HTTP請(qǐng)求還使用其他各種方法。許多這類方法主要用于完成不常見與特殊的任務(wù)。如果低權(quán)限用戶可以訪問這些方法，他們就能夠以此向應(yīng)用程序?qū)嵤┯行Ч簟Ｒ韵率且恍┲档米⒁獾姆椒?#xff1a;

PUT，向指定的目錄上傳附加文件；

DELETE，刪除指定的資源；

COPY，將指定的資源復(fù)制到Destination消息頭指定的位置；

MOVE，將指定的資源移動(dòng)到Destination消息頭指定的位置；

SEARCH，在一個(gè)目錄路徑中搜索資源。

PROPFIND，獲取與指定資源有關(guān)的信息，如作者、大小與內(nèi)容類型。

TRACE，在響應(yīng)中返回服務(wù)器收到的原始請(qǐng)求?？梢允褂眠@種方法避開阻止跨站點(diǎn)腳本的防御

11.2解決方案

在 xxxapplication.java 文件里加入

@BeanPublic ConfigurableServletWebServerFactory configurableServletWebServerFactory() {TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();factory.addContextCustomizers(context -> {SecurityConstraint securityConstraint = new SecurityConstraint();securityConstraint.setUserConstraint("CONFIDENTIAL");SecurityCollection collection = new SecurityCollection();collection.addPattern("/*");collection.addMethod("HEAD");collection.addMethod("PUT");collection.addMethod("DELETE");collection.addMethod("OPTIONS");collection.addMethod("TRACE");collection.addMethod("COPY");collection.addMethod("SEARCH");collection.addMethod("PROPFIND");securityConstraint.addCollection(collection);context.addConstraint(securityConstraint);});return factory;}

添加一個(gè)SecurityConstraint 往這個(gè)SecurityConstraint 里面加method，加進(jìn)去的method就是要被禁止的。

在應(yīng)用程序的web.xml中添加如下的代碼

<security-constraint><web-resource-collection><web-resource-name>fortune</web-resource-name><url-pattern>/*</url-pattern><http-method>PUT</http-method><http-method>DELETE</http-method><http-method>HEAD</http-method><http-method>OPTIONS</http-method><http-method>TRACE</http-method></web-resource-collection><auth-constraint></auth-constraint></security-constraint>

用于限制對(duì)資源的訪問；
用于限制那些角色可以訪問資源，這里設(shè)置為空就是禁止所有角色用戶訪問；
指定需要驗(yàn)證的資源
指定那些方法需要驗(yàn)證

12. 缺少"Content-Security-Policy"頭

12.1風(fēng)險(xiǎn)描述

Content Security Policy，縮寫 CSP，CSP 的實(shí)質(zhì)就是白名單制度，開發(fā)者明確告訴客戶端，哪些外部資源可以加載和執(zhí)行，等同于提供白名單。它的實(shí)現(xiàn)和執(zhí)行全部由瀏覽器完成，開發(fā)者只需提供配置。CSP 大大增強(qiáng)了網(wǎng)頁的安全性。攻擊者即使發(fā)現(xiàn)了漏洞，也沒法注入腳本。

12.2解決方案

1.通過 HTTP 頭信息的Content-Security-Policy的字段。

2.通過網(wǎng)頁的標(biāo)簽。

default-src 限制全局,默認(rèn)所有都會(huì)使用這種規(guī)則
script-src：外部腳本
style-src：樣式表
img-src：圖像
media-src：媒體文件（音頻和視頻）
font-src：字體文件
object-src：插件（比如 Flash）
child-src：框架
frame-ancestors：嵌入的外部資源（比如、、和）connect-src：HTTP 連接（通過 XHR、WebSockets、EventSource等）
worker-src：worker腳本
manifest-src：manifest 文件
例如：
default-src ‘self’; 只允許同源下的資源
script-src ‘self’; 只允許同源下的js
script-src ‘self’ www.google-analytics.com ajax.googleapis.com;
允許同源以及兩個(gè)地址下的js加載
default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’;
多個(gè)資源時(shí),后面的會(huì)覆蓋前面的

13. 缺少 X-XSS-Protection 頭

13.1漏洞描述

跨站XSS防護(hù)，X-XSS-Protection

HTTP X-XSS-Protection 響應(yīng)頭是 Internet Explorer，Chrome 和 Safari 的一個(gè)特性，當(dāng)檢測到跨站腳本攻擊 (XSS (en-US))時(shí)，瀏覽器將停止加載頁面。

13.2解決方案

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

X-XSS-Protection: 1; report=<reporting-uri>

禁止XSS過濾。

啟用XSS過濾（通常瀏覽器是默認(rèn)的）。如果檢測到跨站腳本攻擊，瀏覽器將清除頁面（刪除不安全的部分）。

1;mode=block

啟用XSS過濾。如果檢測到攻擊，瀏覽器將不會(huì)清除頁面，而是阻止頁面加載。

1; report=<reporting-URI> (Chromium only)

啟用XSS過濾。如果檢測到跨站腳本攻擊，瀏覽器將清除頁面并使用CSP report-uri (en-US)指令的功能發(fā)送違規(guī)報(bào)告。

14. 缺少 X-Content-Type-Options 頭

14.1風(fēng)險(xiǎn)描述

響應(yīng)內(nèi)容探測，X-Content-Type-Options

X-Content-Type-Options HTTP 消息頭相當(dāng)于一個(gè)提示標(biāo)志，被服務(wù)器用來提示客戶端一定要遵循在 Content-Type 首部中對(duì) MIME 類型的設(shè)定，而不能對(duì)其進(jìn)行修改。這就禁用了客戶端的 MIME 類型嗅探行為，換句話說，也就是意味著網(wǎng)站管理員確定自己的設(shè)置沒有問題。

有些服務(wù)器響應(yīng)內(nèi)容未設(shè)置content-type，瀏覽器會(huì)自動(dòng)檢測內(nèi)容type（MIME自識(shí)別：通過查看資源的字節(jié)來猜測正確的 MIME 類型），會(huì)出現(xiàn)編碼相關(guān)的安全問題（IE和chrome會(huì)忽略content-typ自行推測網(wǎng)頁格式、編碼等）

14.2解決方案

服務(wù)器配置響應(yīng)頭：X-Content-Type-Options: nosniff

15. 自動(dòng)填寫未對(duì)密碼字段禁用的 HTML 屬性

15.1漏洞描述

密碼字段沒有強(qiáng)制禁用自動(dòng)填寫功能。

15.2解決方案

input中添加屬性：autocomplete=off

16.敏感信息泄露及錯(cuò)誤處理

16.1風(fēng)險(xiǎn)描述

應(yīng)用系統(tǒng)常常產(chǎn)生錯(cuò)誤信息并顯示給使用者，導(dǎo)致信息泄露問題，很多時(shí)候，這些錯(cuò)誤信息是非常有用的攻擊信息，因?yàn)樗鼈儽┞读藨?yīng)用系統(tǒng)實(shí)施細(xì)則或有用的開發(fā)信息，對(duì)攻擊系統(tǒng)有很大幫助。

16.2解決方案

1、應(yīng)根據(jù)業(yè)務(wù)特點(diǎn)定義出系統(tǒng)存儲(chǔ)的敏感信息。

2、敏感信息在存儲(chǔ)、傳輸、顯示時(shí)應(yīng)進(jìn)行安全處理，可采用的處理方式為加密或脫敏。

3、敏感信息不應(yīng)使用GET方式提交到服務(wù)器。

4、用戶密碼為最高級(jí)別的敏感信息，在存儲(chǔ)、傳輸、顯示時(shí)都必須加密。

5、需要選擇可靠的加密算法，優(yōu)先選擇不對(duì)稱加密算法，不得使用BASE64等編碼方式進(jìn)行"加密"。

6、對(duì)于一些系統(tǒng)默認(rèn)報(bào)錯(cuò)頁面應(yīng)重新進(jìn)行設(shè)計(jì)自定義報(bào)錯(cuò)頁面，以免暴露系統(tǒng)敏感信息。

17. 發(fā)現(xiàn)數(shù)據(jù)庫錯(cuò)誤模式

17.1風(fēng)險(xiǎn)描述

主要是一些數(shù)據(jù)連接錯(cuò)誤信息，通過提交特殊構(gòu)造的字符，程序會(huì)暴露一些數(shù)據(jù)庫信息，也容易引起SQL注入攻擊。

17.2漏洞示例

17.3解決方案

1.加強(qiáng)輸入數(shù)據(jù)的有效性驗(yàn)證，

2.軌范代碼錯(cuò)誤捕獲及日志打印。

18.Cookie安全

18.1風(fēng)險(xiǎn)描述

Cookie作為用戶身份的替代，其安全性有時(shí)決定了整個(gè)系統(tǒng)的安全性，Cookie的安全性問題主要如下所述：

（1） Cookie欺騙

Cookie記錄了用戶的帳戶ID、密碼之類的信息，通常使用MD5方法加密后在網(wǎng)上傳遞。雖然經(jīng)過了加密處理，但是截獲Cookie的人不需要知道這些字符串的含義，只要把別人的Cookie向服務(wù)器提交，并且能夠通過驗(yàn)證，就可以冒充受害人的身份登陸網(wǎng)站，這種行為叫做Cookie欺騙。非法用戶通過Cookie欺騙獲得相應(yīng)的加密密鑰，從而訪問合法用戶的所有個(gè)性化信息，包括用戶的E-mail甚至帳戶信息，對(duì)個(gè)人信息造成嚴(yán)重危害。

（2）Cookie截獲

Cookie以純文本的形式在瀏覽器和服務(wù)器之間傳送，很容易被他人非法截獲和利用。任何可以截獲Web通信的人都可以讀取Cookie。Cookie被非法用戶截獲后，然后在其有效期內(nèi)重放，則此非法用戶將享有合法用戶的權(quán)益。例如，對(duì)于在線閱讀，非法用戶可以不支付費(fèi)用即可享受在線閱讀電子雜志。

18.2解決方法

1、設(shè)置認(rèn)證COOKIE時(shí)，增加Cookie httponly這個(gè)屬性。如果在Cookie中設(shè)置了"HttpOnly"屬性，那么通過程序(JS腳本、Applet等)將無法讀取到Cookie信息。

2、增加Secure這個(gè)屬性。當(dāng)該屬性設(shè)置為true時(shí)，表示創(chuàng)建的 Cookie 會(huì)被以安全的形式向服務(wù)器傳輸，也就是只能在 HTTPS 連接中被瀏覽器傳遞到服務(wù)器端進(jìn)行會(huì)話驗(yàn)證，如果是 HTTP 連接則不會(huì)傳遞該cookie信息，所以不會(huì)被竊取到Cookie 的具體內(nèi)容。就是只允許在加密的情況下將cookie加在數(shù)據(jù)包請(qǐng)求頭部，防止cookie被帶出來。secure屬性是防止信息在傳遞的過程中被監(jiān)聽捕獲后信息泄漏，HttpOnly屬性的目的是防止程序獲取cookie后進(jìn)行攻擊。

19. 會(huì)話超時(shí)設(shè)置

19.1漏洞描述

瀏覽器和服務(wù)器之間創(chuàng)建了一個(gè)Session，若沒有做會(huì)話超時(shí)設(shè)置，當(dāng)客戶端長時(shí)間（休眠時(shí)間）沒有與服務(wù)器交互的情況下，服務(wù)器也沒有將此Session銷毀，若攻擊者獲取此會(huì)話，就能一直利用該會(huì)話，進(jìn)行與服務(wù)器的交互。

19.2漏洞示例

下面一段存在漏洞的代碼中，沒有對(duì)session做一個(gè)失效的處理。

修復(fù)后的代碼如下所示，用戶在登錄的時(shí)候，首先會(huì)讓之前的session失效，然后又獲取新的seesion。

19.3解決方案

設(shè)置空閑會(huì)話強(qiáng)制超時(shí)時(shí)間，時(shí)間不能設(shè)置過長，建議設(shè)置為5分鐘。

設(shè)置Session超時(shí)時(shí)間方式：

方式一：

在web.xml中設(shè)置session-config如下：

即客戶端連續(xù)兩次與服務(wù)器交互間隔時(shí)間最長為2分鐘，2分鐘后session.getAttribute()獲取的值為空

方式二：

在Servlet中設(shè)置

HttpSession session = request.getSession();

session.setMaxInactiveInterval(60);//單位為秒

20.日志處理

20.1風(fēng)險(xiǎn)描述

日志處理是由于在全局過濾的時(shí)候沒有考慮日志文件內(nèi)容，當(dāng)一些敏感內(nèi)容通過日志文件保存下來的時(shí)候，或者說木馬病毒代碼通過日志記錄下來時(shí)，可以通過日志文件查看或執(zhí)行。導(dǎo)致敏感信息泄露，甚至被上傳webshell，導(dǎo)致攻擊者可以隨時(shí)進(jìn)入后臺(tái)，對(duì)文件進(jìn)行操作。

20.2漏洞示例

1.日志文件中打印用戶的用戶名和密碼。

2.日志中輸出數(shù)據(jù)庫信息。

3.保存惡意腳本。

20.2解決方案

對(duì)日志文件中的敏感內(nèi)容進(jìn)行轉(zhuǎn)義，凡是從日志文件中輸出的內(nèi)容都要進(jìn)行驗(yàn)證。而且對(duì)于一些敏感信息，如電話號(hào)碼，密碼，ip地址等內(nèi)容都要進(jìn)行加密保存。

21 HTTP響應(yīng)頭X-Frame-Options

21.1風(fēng)險(xiǎn)描述

X-Frame-Options HTTP響應(yīng)頭是用來確認(rèn)是否瀏覽器可以在frame或iframe標(biāo)簽中渲染一個(gè)頁面，網(wǎng)站可以使用此功能，來確保自己網(wǎng)站的內(nèi)容沒有被嵌到別人的網(wǎng)站中去，也從而避免了點(diǎn)擊劫持 (clickjacking) 的攻擊。

攻擊者可以使用一個(gè)透明的、不可見的iframe，覆蓋在目標(biāo)網(wǎng)頁上，然后誘使用戶在該網(wǎng)頁上進(jìn)行操作，此時(shí)用戶將在不知情的情況下點(diǎn)擊透明的iframe頁面。通過調(diào)整iframe頁面的位置，可以誘使用戶恰好點(diǎn)擊iframe頁面的一些功能性按鈕上，導(dǎo)致被劫持。

21.2解決方案

X-Frame-Options可配置的三個(gè)參數(shù):
1、DENY
表示該頁面不允許在frame中展示，即便是在相同域名的頁面中嵌套也不允許。
2、SAMEORIGIN
表示該頁面可以在相同域名頁面的frame中展示。
3、ALLOW-FROM uri
表示該頁面可以在指定來源的frame中展示。
一般我們使用SAMEORIGIN

配置方式：
在服務(wù)端設(shè)置的方式如下：
Java代碼:
添加攔截器設(shè)置：
response.addHeader(“x-frame-options”,“SAMEORIGIN”);
Nginx配置:
nginx.conf添加配置：
add_header X-Frame-Options SAMEORIGIN

總結(jié)

以上是生活随笔為你收集整理的常见21种漏洞编码安全规范及解决方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。

上一篇： Building Fire Statio
下一篇： 201912-3 化学方程式