---

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

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

---

1.sql注入

1.1風險描述

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

1.2漏洞示例

1.3解決方案

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

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

比如，我們前面接受username參數(shù)例子中，我們的產(chǎn)品設計應該是在用戶注冊的一開始，就有一個用戶名的規(guī)則，比如5-20個字符，只能由大小寫字母、數(shù)字以及一些安全的符號組成，不包含特殊字符。此時我們應該有一個check_username的函數(shù)來進行統(tǒng)一的檢查。不過，仍然有很多例外情況并不能應用到這一準則，比如文章發(fā)布系統(tǒ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>   攔截所有請求
</filter-mapping>
在SQLFilter.java類中：
paramValue= paramValue.replaceAll(“>”, “”)
paramValue= paramValue.replaceAll(“%”,“”)

3、綁定變量，使用預編譯語句

MySQL的mysql驅動提供了預編譯語句的支持，不同的程序語言，都分別有使用預編譯語句的方法。

實際上，綁定變量使用預編譯語句是預防SQL注入的最佳方式，使用預編譯的SQL語句語義不會發(fā)生改變，在SQL語句中，變量用問號?表示，黑客即使本事再大，也無法改變SQL語句的結構。

2.跨站腳本攻擊(XSS)

2.1風險描述

跨站攻擊是因為網(wǎng)站程序對用戶輸入過濾不足，將用戶輸入的惡意腳本代碼正常執(zhí)行或者提交。攻擊者可利用XSS漏洞獲取用戶cookie值、傳播蠕蟲、篡改頁面或進行釣魚等攻擊。

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

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

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

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

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

2.2漏洞示例

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

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

2.3解決方案

1. 消毒機制，對用戶輸入的內(nèi)容進行轉義，比如說把>轉義為&gt之類的，這樣就可以把惡意腳本里的html標簽、js代碼之類的東西，都給轉義掉，讓這些惡意腳本失效。

2. HttpOnly方式，如果你在瀏覽器里存放cookie的時候，可以設置一個HttpOnly屬性，比如說存放用戶加密認證信息的cookie，這樣的話，在瀏覽器里運行的js腳本是被禁止訪問這些HttpOnly cookie的，他就無法竊取你在瀏覽器里存儲的cookie了。

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

3.任意文件下載

3.1風險描述

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

3.2漏洞示例

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

3.3解決方案

1、文件下載時進行過濾，過濾掉 “./”、“…/”、“%”等，代碼如下：

2、對下載的文件路徑進行嚴格控制，只允許下載某部分目錄下的文件：

3、對下載文件后綴名做嚴格控制：

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

4.任意文件上傳

4.1風險描述

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

4.2解決方案

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

5.越權操作

5.1風險描述

越權漏洞是比較常見的漏洞類型，越權漏洞可以理解為，一個正常的用戶A通常只能夠對自己的一些信息進行增刪改查，但是由于程序員的一時疏忽未對信息進行增刪改查的時候沒有進行一個判斷，判斷所需要操作的信息是否屬于對應的用戶，可以導致用戶A可以操作其他人的信息。?

權限攻擊可以分為水平權限攻擊和垂直權限攻擊。

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

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

5.2漏洞示例

1.水平權限攻擊

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

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

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

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

5.3解決方案

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

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

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

2. 對于垂直權限攻擊，只需要在每個頁面的加載之前進行權限驗證即可。

6.URL跳轉

6.1風險描述

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

6.2漏洞示例

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

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

6.3解決方案

1、輸入驗證，對跳轉的URL進行驗證，對于不合法的跳轉URL拒絕跳轉訪問?？赏ㄟ^白名單進行驗證。

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

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

7.跨站請求偽造(CSRF)

7.1風險描述

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

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

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

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

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

7.2漏洞示例

bob在銀行有一筆存款，可以通過請求

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

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

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

7.3解決方案

1. 驗證Referer：

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

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);  }

2. 在請求參數(shù)中添加token驗證：

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

3. 在HTTP頭中自定義屬性并驗證：

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

8. 不充分帳戶封鎖

8.1風險描述

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

8.2解決方案

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

2、加入圖形驗證碼解決暴力攻擊。

9. 密碼安全

9.1風險描述

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

9.2漏洞示例

9.3解決方案

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

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

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

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

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

10.1風險描述

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

10.2漏洞示例

1.密碼明文傳輸

2.配置文件密碼明文存儲

10.3解決方案

1. 登陸密碼建議采用不可逆的加密方式對密碼進行加密如MD5。

2. 禁止明文或使用弱加密算法對密碼進行加密，密碼設置應具備一定的強度，大小寫數(shù)字特殊字等最少3類型8位以上，并且不能包含與用戶名一樣的字符串。

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

11.1風險描述

除標準的GET與POST方法外，HTTP請求還使用其他各種方法。許多這類方法主要用于完成不常見與特殊的任務。如果低權限用戶可以訪問這些方法，他們就能夠以此向應用程序實施有效攻擊。以下是一些值得注意的方法：

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

DELETE，刪除指定的資源；

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

MOVE，將指定的資源移動到Destination消息頭指定的位置；

SEARCH，在一個目錄路徑中搜索資源。

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

TRACE，在響應中返回服務器收到的原始請求?？梢允褂眠@種方法避開阻止跨站點腳本的防御

11.2解決方案

1. 在 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;}

添加一個SecurityConstraint 往這個SecurityConstraint 里面加method， 加進去的method就是要被禁止的。

2. 在應用程序的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>

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

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

12.1風險描述

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

12.2解決方案

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

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

default-src 限制全局,默認所有都會使用這種規(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;
允許同源以及兩個地址下的js加載
default-src ‘none’; script-src ‘self’; connect-src ‘self’; img-src ‘self’; style-src ‘self’;
多個資源時,后面的會覆蓋前面的

13. 缺少 X-XSS-Protection 頭

13.1漏洞描述

跨站XSS防護，X-XSS-Protection

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

13.2解決方案

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

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

0

禁止XSS過濾。

1

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

1;mode=block

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

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

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

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

14.1風險描述

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

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

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

14.2解決方案

服務器配置響應頭：X-Content-Type-Options: nosniff

15. 自動填寫未對密碼字段禁用的 HTML 屬性

15.1漏洞描述

密碼字段沒有強制禁用自動填寫功能。

15.2解決方案

input中添加屬性：autocomplete=off

16.敏感信息泄露及錯誤處理

16.1風險描述

應用系統(tǒng)常常產(chǎn)生錯誤信息并顯示給使用者，導致信息泄露問題，很多時候，這些錯誤信息是非常有用的攻擊信息，因為它們暴露了應用系統(tǒng)實施細則或有用的開發(fā)信息，對攻擊系統(tǒng)有很大幫助。

16.2解決方案

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

2、敏感信息在存儲、傳輸、顯示時應進行安全處理，可采用的處理方式為加密或脫敏。

3、敏感信息不應使用GET方式提交到服務器。

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

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

6、對于一些系統(tǒng)默認報錯頁面應重新進行設計自定義報錯頁面，以免暴露系統(tǒng)敏感信息。

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

17.1風險描述

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

17.2漏洞示例

17.3解決方案

1.加強輸入數(shù)據(jù)的有效性驗證，

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

18.Cookie安全

18.1風險描述

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

（1） Cookie欺騙

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

（2）Cookie截獲

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

18.2解決方法

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

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

19. 會話超時設置

19.1漏洞描述

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

19.2漏洞示例

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

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

19.3解決方案

設置空閑會話強制超時時間，時間不能設置過長，建議設置為5分鐘。

設置Session超時時間方式：

方式一：

在web.xml中設置session-config如下：

2

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

方式二：

在Servlet中設置

HttpSession session = request.getSession();

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

20.日志處理

20.1風險描述

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

20.2漏洞示例

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

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

3.保存惡意腳本。

20.2解決方案

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

21 HTTP響應頭X-Frame-Options

21.1風險描述

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

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

21.2解決方案

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

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

總結

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

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