常見web安全漏洞修復方案(全面)

第一章 SQL注入漏洞

第一節 漏洞介紹

概述:SQL注入攻擊包括通過輸入數據從客戶端插入或“注入”SQL查詢到應用程序。一個成功的SQL注入攻擊可以從 數據庫中獲取敏感數據、修改數據庫數據(插入/更新/刪除)、執行數據庫管理操作 (如關閉數據庫管理系統)、恢 復存在於數據庫文件系統中的指定文件內容,在某些情況下能對操作系統發佈命令。SQL注入攻擊是一種注入攻擊。 它將SQL命令注入到數據層輸入,從而影響執行預定義的SQL命令。由於用戶的輸入,也是SQL語句的一部分,所以 攻擊者可以利用這部分可以控制的內容,注入自己定義的語句,改變SQL語句執行邏輯,讓數據庫執行任意自己需要 的指令。通過控制部分SQL語句,攻擊者可以查詢數據庫中任何自己需要的數據,利用數據庫的一些特性,可以直接 獲取數據庫服務器的系統權限。

潛在風險:高

第二節 JAVA漏洞代碼示例

//拼接SQL語句,直接插入數據庫查詢

第三節 修復建議

使用參數化查詢接口或在代碼級對帶入SQL語句中的外部參數進行轉義或過濾:

1. 對於整數,判斷變量是否符合[0-9]的值;其他限定值,也可以進行合法性校驗;

2. 對於字符串,對SQL語句特殊字符進行轉義(單引號轉成兩個單引號,雙引號轉成兩個雙引號)。

第四節 JAVA修復建議

1. 參數化查詢(最佳修復方法)

2. 過濾特殊字符,過濾的訪問爲所有用戶輸入的數據

GET、POST的參數

表單的參數

http頭的參數

UA、X-FORWARD-FOR、Content-type等可以修改的字段

JSON類型的參數

在web.xml 配置攔截器

過濾器SqlFilter.java

 

 3. 若使用框架,對應的框架可能存在相應的防注入方法

第二章 XSS漏洞

第一節 漏洞介紹

描述:當應用程序發送給瀏覽器的頁面中包含用戶提供的數據,而這些數據沒有經過適當的驗證或轉義 (escape),就會導致跨站腳本漏洞。攻擊者通常會利用XSS漏洞來安裝鍵盤記錄器、竊取受害者的cookie、竊取剪 貼板內容、改變網頁內容(例如,下載鏈接)等。有三種已知的跨站漏洞類型:1)存儲式;2)反射式;3)基於 DOM的XSS。

(一) 反射型跨站腳本:攻擊者會通過社會工程學手段,發送一個URL連接給用戶打開,在用戶打開頁面的同時,瀏覽 器會執行頁面中嵌入的惡意腳本;

(二) 存儲型跨站腳本:攻擊者利用web應用程序提供的輸入或修改數據功能,將數據存儲到服務器或用戶cookie中, 當其他用戶瀏覽展示該數據的頁面時,瀏覽器會執行頁面中嵌入的惡意腳本。所有瀏覽者都會受到攻擊;

(三) DOM跨站攻擊:由於html頁面中,定義了一段JS,根據用戶的輸入,顯示一段html代碼,攻擊者可以在輸入 時,插入一段惡意腳本,最終展示時,會執行惡意腳本;

(四)DOM跨站和以上兩個跨站攻擊的差別是,DOM跨站是純頁面腳本的輸出,只有規範使用JAVASCRIPT,纔可以防 御。

惡意攻擊者可以利用跨站腳本攻擊做到: 

(一) 盜取用戶cookie,僞造用戶身份登錄;

(二) 控制用戶瀏覽器;

(三) 結合瀏覽器及其插件漏洞,下載病毒木馬到瀏覽者的計算機上執行;

(四) 衍生URL跳轉漏洞; // TODO Auto-generated method stub config = fConfig; } } //Hibernate String queryStr = "from user where username=:username "+"password=:password"; List result = session.createQuery(queryStr).setString("username",username).setString("password", password).list(); //Mybatis 參數拼接使用#{},而不是使用${} SELECT id,title,author,content FROM blog WHERE id=#{id}

(五) 讓官方網站出現釣魚頁面;

(六) 蠕蟲攻擊。

第二節 JAVA漏洞代碼示例

變量name被直接輸出到了頁面中,沒有做任何安全過濾,一旦讓用戶可以輸入數據,都可能導致用戶瀏覽器把“用戶 可控數據”當成JS/VBS腳本執行,或頁面元素被“用戶可控數據”插入的頁面HTML代碼控制,從而造成攻擊。

第三節 修復建議

1. 對參數做html轉義過濾(要過濾的字符包括:單引號、雙引號、大於號、小於號,&符號),防止腳本執行。 在變量輸出時進行HTML ENCODE 處理。

2. JAVA應用可以使用org.apache.commons.lang3.StringEscapeUtils.escapeHtml4對用戶參數進行編碼

3. 啓用COOKIE的httponly屬性。 

第四節 JAVA修復示例

1. 輸出轉義(最佳修復方法)

2. 輸入過濾,可以參考SQL注入利用過濾器的方式,但該方法不推薦。

3. 富文本框的XSS修復方法,利用Jsoup的包,對文本輸入的標籤做限制 

第三章 CSRF漏洞

第一節 漏洞介紹

描述:用戶以當前身份瀏覽到flash或者惡意網站時,JS/flash可以迫使用戶瀏覽器向任意CGI發起請求,此請求包含 用戶身份標識,CGI如無限制則會以用戶身份進行操作。如:以用戶身份發起的轉賬請求等。CSRF攻擊可以從站外和 站內發起。從站內發起CSRF攻擊,需要利用網站本身的業務,比如“自定義頭像”功能,惡意用戶指定自己的頭像URL 是一個修改用戶信息的鏈接,當其他已登錄用戶瀏覽惡意用戶頭像時,會自動向這個鏈接發送修改信息請求。從站外 發送請求,則需要惡意用戶在自己的服務器上,放一個自動提交修改個人信息的htm頁面,並把頁面地址發給受害者 用戶,受害者用戶打開時,會發起一個請求。如果惡意用戶能夠知道網站管理後臺某項功能的URL,就可以直接攻擊 管理員,強迫管理員執行惡意用戶定義的操作。

潛在危險:中

第二節 JAVA漏洞代碼示例

代碼中接收用戶提交的參數“passwordOld、passwordNew”,之後修改了該用戶的密碼,一旦接收到一個用戶發來 的請求,就執行此操作。

提交表單代碼:

當用戶點提交時,就會觸發修改操作。

第三節 修復建議

第一種修復方法:(推薦) 添加隨機TOKEN,實現方式如下:

1. 在用戶登陸時,設置一個CSRF的隨機TOKEN,同時種植在用戶的cookie (session)中,當用戶瀏覽器關閉、或 用戶再次登錄、或退出時,清除token;

2. 在表單中,生成一個隱藏域,它的值就是COOKIE (session)中隨機TOKEN;

3. 表單被提交後,就可以在接收用戶請求的web應用中,判斷表單中的TOKEN值是否和用戶COOKIE (session)中 的TOKEN值一致,如果不一致或沒有這個值,就判斷爲CSRF攻擊,同時記錄攻擊日誌。由於攻擊者無法預測每 一個用戶登錄時生成的那個隨機TOKEN值,所以無法僞造這個參數。 

第二種修復方法:

驗證referer,判斷referer是否從表單頁面跳轉過來。

第四節 JAVA修復示例

1.配置過濾,驗證referer

2.配置過濾器,驗證TOKEN

 

第四章 文件上傳漏洞

第一節 漏洞介紹

 描述:Web應用程序在處理用戶上傳的文件時,沒有判斷文件的擴展名是否在允許的範圍內,就把文件保存在服務器 上,導致惡意用戶可以上傳任意文件,甚至上傳腳本木馬到web服務器上,直接控制web服務器。

第二節 JAVA漏洞代碼示例

第三節 修復建議

處理用戶上傳文件,要做以下檢查:

1. 檢查上傳文件擴展名白名單,不屬於白名單內,不允許上傳;

2. 上傳文件的目錄必須是http請求無法直接訪問到的。如果需要訪問的,必須上傳到其他(和web服務器不同 的)域名下,並設置該目錄爲不解析php、jsp等腳本語言的目錄;

3. 上傳文件要保存的文件名和目錄名由系統根據時間隨機生成,不允許用戶自定義;

4. 圖片上傳,要通過處理(縮略圖、水印等),或通過圖片讀取函數判斷無異常後才能保存到服務器;

5. 上傳文件需要做日誌記錄 

第四節 JAVA修復示例

第五章 文件下載漏洞

第一節 漏洞介紹

描述:處理用戶請求下載文件時,允許用戶提交任意文件路徑,並把服務器上對應的文件直接發送給用戶,這將造成 任意文件下載威脅。如果讓用戶提交文件目錄地址,就把目錄下的文件列表發給用戶,會造成目錄遍歷安全威脅。 惡意用戶會變換目錄或文件地址,下載服務器上的敏感文件、數據庫鏈接配置文件、網站源代碼等。

潛在危險:高

第二節 JAVA漏洞代碼示例

第三節 修復建議

 對文件操作功能,做到以下幾點:

1. 要下載的文件地址保存至數據庫中;

2. 文件路徑保存至數據庫,讓用戶提交文件對應ID下載文件;

3. 下載文件之前做權限判斷;

4. 文件放在web無法直接訪問的目錄下;

5. 記錄文件下載日誌;

6. 不允許提供目錄遍歷服務。

第四節 JAVA修復示例

 或者

第六章 命令執行漏洞

第一節 漏洞介紹

描述:web應用代碼中,允許接收用戶輸入一段代碼,之後在web應用服務器上執行這段代碼,並返回給用戶。 由於用戶可以自定義輸入一段代碼,在服務器上執行,所以惡意用戶可以寫一個遠程控制木馬,直接獲取服務器控制 權限,所有服務器上的資源都會被惡意用戶獲取和修改,甚至可以直接控制數據庫。

潛在危險:高 

第二節 JAVA漏洞代碼示例

第三節 修復建議

所有需要執行的系統命令,必須是預先定義好的,不允許接收用戶傳來的參數,加入到系統命令中去。

第四節 JAVA修復示例

第七章 URL跳轉漏洞

第一節 漏洞介紹

 描述:某些頁面由於功能需要需要進行頁面跳轉,如果沒有對跳轉的目的頁面做檢查,惡意攻擊者可以發送給用戶一 個僞裝的鏈接,安全意識較低的用戶很可能會以爲該鏈接展現的內容是公司站點的,從而信任此站點。但是用戶打開 後,跳轉至釣魚網站頁面,將會導致用戶被釣魚攻擊,賬號被盜,或賬號相關財產被盜。

潛在危險:中

第二節 JAVA漏洞代碼示例

第三節 修復建議

爲了保證用戶所點擊的URL,是從web應用程序中生成的URL,所以要做TOKEN驗證: 1. 當用戶訪問需要生成跳轉URL的頁面時,首先生成隨機token,並放入cookie; 2. 在顯示連接的頁面上生成URL,在URL參數中加入token; 3. 應用程序在跳轉前,判斷token是否和cookie中的token一致,如果不一致,就判定爲URL跳轉攻擊,並記錄日 志(日誌內容見“Error Handing and Logging”章節); 4. 如果在javascript中做頁面跳轉,需要判斷域名白名單後,才能跳轉; 5. 如果應用只有跳轉到公司網站的需求,可以設置白名單,判斷目的地址是否在白名單列表中,如果不在列表 中,就判定爲URL跳轉攻擊,並記錄日誌,不允許配置集團以外網站到白名單列表中。

第四節 JAVA修復示例

第八章 水平權限攻擊

第一節 漏洞介紹

描述:Web應用程序接收到用戶請求,對用戶數據進行CRUD(增加、讀取、更新和刪除)操作時,沒有判斷數據的所 屬人,或數據所屬人userid直接從用戶提交的request參數(用戶可控數據)中獲取,導致惡意攻擊者可以通過變換 數據ID或所屬人userid,從而越權獲取或修改其他人數據。

潛在危險:高 

第二節 JAVA漏洞代碼示例

第三節 修復建議

(一)檢查提交CRUD請求的操作者(通過session信息得到)與目標對象的權限所有者(查數據庫)是否一致,如 果不一致則阻斷。從session中獲取當前登錄用戶的userid,並且需要在執行的SQL語句中,加入當前用戶userid作 爲條件語句。

(二)將數據ID改成一個具有一定長度的隨機字符串。

第四節 Java修復示例

 第九章 垂直權限攻擊

第一節 漏洞介紹

描述:垂直權限攻擊即低權限用戶越權利用更高權限用戶的功能實現權限提升攻擊,是由於web應用程序沒有做權限 控制,或僅僅在菜單上做了權限控制,導致的惡意用戶只要猜測其他管理頁面的URL,就可以訪問或控制其他角色擁 有的數據或頁面,達到權限提升目的。這個威脅可能導致普通用戶變成管理員權限。

潛在危險:高

第二節 JAVA漏洞代碼

一個僅僅做了菜單控制的代碼:

第三節 修復建議

1. 在打開管理頁面URL或者請求接口時,首先判斷當前用戶是否擁有該頁面的權限,如果沒有權限,就判定爲攻 擊拒絕訪問; 2. 使用ESAPI框架進行安全開發

第十章 服務器應用錯誤頁面信息泄露

第一節 漏洞介紹

描述:服務器應用錯誤頁面信息泄露是指服務器應用默認配置了錯誤頁面,默認的錯誤頁面泄露了服務器應用的版本 信息,有時候應用程序的報錯,也會直接調用默認的錯誤頁面,導致程序的錯誤信息也會泄露出來。

潛在危險:低 

第二節 默認錯誤配置頁面

tomcat的錯誤頁面: 500頁面

404頁面

第三節 修復建議

Tomcat的修復方法 :

1.新建一個error.html ,保存在webapps/ROOT/下 

2.修改tomcat配置下$CATALINA_HOME/conf/web.xml文件

nginx的配置方法

1. 參考tomcat的修復中的第一步,新建一個報錯的error.html

2. 修改nginx.conf文件或者網站的配置文件,在server節點配置一下內容,把常見的錯誤碼,全部指定到404頁 面。root節點是404.html頁面絕對路徑地址 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章