1.1.sql 注入攻擊原理
SQL 注入漏洞可以說是在企業運營中會遇到的最具破壞性的漏洞之一,它也是目前被利用得最多的漏洞。要學會如何防禦 SQL 注入,首先我們要學習它的原理。
針對 SQL 注入的攻擊行為可描述為通過在用戶可控參數中注入 SQL 語法,破壞原有 SQL 結構,達到編寫程序時意料之外結果的攻擊行為。其成因可以歸結為以下兩個原因疊加造成的:
程序編寫者在處理應用程式和資料庫交互時,使用字符串拼接的方式構造 sql 語句。未對用戶可控參數進行足夠的過濾便將參數內容拼接進入到 SQL 語句中。注入攻擊的本質,是把用戶輸入的數據當做代碼執行。這裡有兩個關鍵條件:用戶能夠控制輸入。原本程序要執行的代碼,拼接了用戶輸入的數據。
1.2.Sql 審計方法
手動找的話,可以直接找到 sqlmapper.xml 文件或者直接搜索 select、update、delete、insert 「String sql=」等關鍵詞,定位 SQL xml 配置文件。
如果 sql 語句中有出現 $ 進行參數拼接,則存在 SQL 注入風險。
當找到某個變量關鍵詞有 SQL 注入風險時,可以再根據調用鏈找到該存在注入風險的業務邏輯代碼,查看參數來源是否安全、是否有配置 SQL 危險參數過濾的過濾器,最終確認是否存在 SQL 注入。以下給出可能造成 sql 注入攻擊的關鍵字,審計時可根據實際情況進項查找
常見 SQL 語句關鍵詞
【一一幫助安全學習,所有資源一一】①網絡安全學習路線②20 份滲透測試電子書③安全攻防 357 頁筆記④50 份安全攻防面試指南⑤安全紅隊滲透工具包⑥網絡安全必備書籍⑦100 個漏洞實戰案例⑧安全大廠內部教程
1.3Sql 注入漏洞危害
1 、 攻擊者可以做到
- 業務運營的所有數據被攻擊
- 對當前資料庫用戶擁有的所有表數據進行增、刪、改、查等操作
- 若當前資料庫用戶擁有 file_priv 權限,攻擊者可通過植入木馬的方式進一步控制 DB 所在伺服器
- 若當前資料庫用戶為高權限用戶,攻擊者甚至可以直接執行伺服器命令從而通過該漏洞直接威脅整個內網系統
2、可能對業務造成的影響
① 用戶信息被篡改
② 攻擊者偷取代碼和用戶數據惡意獲取
線上代碼被非法篡改,並造成為惡意攻擊者輸送流量或其他利益的影響
1.4Sql 注入漏洞代碼示例
Java 代碼動態構建 SQL
Statement stmt = null;
ResultSet rs = null;
try{
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String sqlString = "SELECT * FROM t_item WHERE owner='" + userName + "' AND itemName='" + request.getParameter("itemName") + "'";
stmt = connection.createStatement();
rs = stmt.executeQuery(sqlString);
// ... result set handling
}
catch (SQLException se){
// ... logging and error handling
}
複製代碼
這裡將查詢字符串常量與用戶輸入進行拼接來動態構建 SQL 查詢命令。僅當 itemName 不包含單引號時,這條查詢語句的行為才會是正確的。如果一個攻擊者以用戶名 wiley 發起一個請求,並使用以下條目名稱參數進行查詢:
name' OR 'a' = 'a
複製代碼
那麼這個查詢將變成:
SELECT * FROM t_item WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a';
複製代碼
此處,額外的 OR 'a'='a'條件導致整個 WHERE 子句的值總為真。那麼,這個查詢便等價於如下非常簡單的查詢:
SELECT * FROM t_item
複製代碼
這個簡化的查詢使得攻擊者能夠繞過原有的條件限制:這個查詢會返回 items 表中所有儲存的條目,而不管它們的所有者是誰,而原本應該只返回屬於當前已認證用戶的條目。
在存儲過程中動態構建 SQL
Java 代碼:
CallableStatement = null
ResultSet results = null;
try
{
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
cs = connection.prepareCall("{call sp_queryItem(?,?)}");
cs.setString(1, userName);
cs.setString(2, itemName);
results = cs.executeQuery();
// ... result set handling
}
catch (SQLException se)
{
// ... logging and error handling
}
SQL Server存儲過程:
CREATE PROCEDURE sp_queryItem
@userName varchar(50),
@itemName varchar(50)
AS
BEGIN
DECLARE @sql nvarchar(500);
SET @sql = 'SELECT * FROM t_item
WHERE owner = ''' + @userName + '''
AND itemName = ''' + @itemName + '''';
EXEC(@sql);
END
GO
複製代碼
在存儲過程中,通過拼接參數值來構建查詢字符串,和在應用程式代碼中拼接參數一樣,同樣是有 SQL 注入風險的。
Hibernate 動態構建 SQL/HQL
原生 SQL 查詢:
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
Query sqlQuery = session.createSQLQuery("select * from t_item where owner = '" + userName + "' and itemName = '" + itemName + "'");
List<Item> rs = (List<Item>) sqlQuery.list();
複製代碼
HQL 查詢:
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
Query hqlQuery = session.createQuery("from Item as item where item.owner = '" + userName + "' and item.itemName = '" + itemName + "'");
List<Item> hrs = (List<Item>) hqlQuery.list();
複製代碼
即使是使用 Hibernate,如果在動態構建 SQL/HQL 查詢時包含了不可信輸入,同樣也會面臨 SQL/HQL 注入的問題。
HQL 代碼中,session.createQuery 使用 HQL 語句將查詢到的數據存到到 list 集合中,需要時在拿出來使用。而參數中 itemName 是通過 request.getParameter 直接獲取。攻擊者若在此處寫入惡意語句,程序將惡意語句查詢出來的數據存放在 list 集合中,再通過某處調用成功將數據顯示在前台。
Mybatis 注入分析
Mybatis 框架下易產生 SQL 注入漏洞的情況主要分為以下三種:
1)模糊查詢 like
例如對人員姓名檢索進行模糊查詢,如果考慮安全編碼規範問題,其對應的 SQL 語句如下:
Select * from user where name like '%#{name}%'
複製代碼
但由於這樣寫程序會報錯,研發人員將 SQL 查詢語句修改如下:
Select * from user where name like '%${name}%'
複製代碼
在這種情況下我們發現程序不再報錯,但是此時產生了 SQL 語句拼接問題,如果 java 代碼層面沒有對用戶輸入的內容做處理勢必會產生 SQL 注入漏洞。
2)in 之後的參數
例如對人員姓名進行同條件多值檢索的時候,如當用戶輸入 001,002,003...時,如果考慮安全編碼規範問題,其對應的 SQL 語句如下:
Select * from name where id in (#{id})
複製代碼
但由於這樣寫程序會報錯,研發人員將 SQL 查詢語句修改如下:
Select * from name where id in (${id})
複製代碼
修改 SQL 語句之後,程序停止報錯,但是卻引入了 SQL 語句拼接的問題,如果沒有對用戶輸入的內容做過濾,勢必會產生 SQL 注入漏洞。
3)order by 之後(重點和區分點)
當根據姓名、id 序號等信息用戶進行排序的時候,如果考慮安全編碼規範問題,其對應的 SQL 語句如下:
Select * from user where name = 'qihoo' order by #{id} desc
複製代碼
但由於發布時間 id 不是用戶輸入的參數,無法使用預編譯。研發人員將 SQL 查詢語句修改如下:
Select * from user where name = 'qihoo' order by ${id} desc
複製代碼
修改之後,程序未通過預編譯,但是產生了 SQL 語句拼接問題,極有可能引發 SQL 注入漏洞。
1.5.實戰案例-OFCMS SQL 注入漏洞分析
本文中使用 ofcms 進行 SQL 注入漏洞講解,此 CMS 算是對新手學習代碼審計比較友好的 CMS。
上述為安裝成功頁面,如何安裝 CMS 本章不在贅述。
後台頁面:http://localhost:8080/ofcms-admin/admin/index.html
漏洞點:
ofcms-admin/src/main/java/com/ofsoft/cms/admin/controller/system/SystemGeneratrController.java
create方法
|
/**
* 創建表
*/
public void create() {
try {
String sql = getPara("sql");
Db.update(sql);
rendSuccessJson();
} catch (Exception e) {
e.printStackTrace();
rendFailedJson(ErrorCode.get("9999"), e.getMessage());
}
}
複製代碼
上述代碼中使用 getpara 獲取 sql 的參數值,並 update,跟進一下 getpara 和 update 方法。
跳轉至 jfinal-3.2.jar/com/jfinal/core/controller.class
public String getPara(String name) {
return this.request.getParameter(name);
}
複製代碼
上述代碼無特殊用意,就是獲取參數值,繼續跟進 Db.update 方法。
跳轉至 jfinal-3.2.jar/com/jfinal/plugin/activerecord/Db.class
public static int update(String sql) {
return MAIN.update(sql);
}
複製代碼
發現調用 MAIN.update , 繼續跟進。
跳轉至 jfinal-3.2.jar/com/jfinal/plugin/activerecord/DbPro.class
public int update(String sql) {
return this.update(sql, DbKit.NULL_PARA_ARRAY);
}
複製代碼
繼續跟進到最後,發現華點。
public int update(String sql, Object... paras) {
Connection conn = null;
int var4;
try {
conn = this.config.getConnection();//連接
var4 = this.update(this.config, conn, sql, paras);//調用update更新
} catch (Exception var8) {
throw new ActiveRecordException(var8);
} finally {
this.config.close(conn);
}
return var4;
}
複製代碼
重點:Object...
Object 是所有類的基類,而 Object... 是不確定方法參數情況下的一種多態表現形式(可以傳遞多個參數)。
再繼續跟進 update ,同文件代碼
int update(Config config, Connection conn, String sql, Object... paras) throws SQLException {
PreparedStatement pst = conn.prepareStatement(sql);
config.dialect.fillStatement(pst, paras);
int result = pst.executeUpdate();
DbKit.close(pst);
return result;
}
複製代碼
上述代碼執行 SQL 語句,並返回結果。
至此,整個功能流程結束,在我們跟進的過程中,代碼中無任何過濾語句,獲取參數值,調用 update 方法更新,更新成功後返回結果。
漏洞驗證
漏洞點打上斷點,網頁中輸入 poc 進行驗證
update of_cms_topic set topic_url=updatexml(1,concat(0x7e,(user())),0) where topic_id = 1
複製代碼
根據如上截圖可看出我們傳入的 SQL 語句是被完整的接收,並未做任何過濾直接帶入資料庫執行,所以此處直接寫入漏洞代碼爆出當前資料庫帳戶為 root。
上述為 sqlmap 工具跑出來的注入點。
1.6漏洞修複方法
添加全局過濾器,過濾特殊字符
SQLFilter.java 中:
PreparedStatement 參數化
如果使用參數化查詢,則在 SQL 語句中使用占位符表示需在運行時確定的參數值。參數化查詢使得 SQL 查詢的語義邏輯被預先定義,而實際的查詢參數值則等到程序運行時再確定。參數化查詢使得資料庫能夠區分 SQL 語句中語義邏輯和數據參數,以確保用戶輸入無法改變預期的 SQL 查詢語義邏輯。
在 Java 中,可以使用 java.sql.PreparedStatement 來對資料庫發起參數化查詢。在這個正確示例中,如果一個攻擊者將 itemName 輸入為 name' OR 'a' = 'a,這個參數化查詢將免受攻擊,而是會查找一個 itemName 匹配 name' OR 'a' = 'a 這個字符串的條目。
PreparedStatement stmt = null
ResultSet rs = null
try
{
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
// ...Ensure that the length of userName and itemName is legitimate
// ...
String sqlString = "SELECT * FROM t_item WHERE owner=? AND itemName=?";
stmt = connection.prepareStatement(sqlString);
stmt.setString(1, userName);
stmt.setString(2, itemName);
rs = stmt.executeQuery();
// ... result set handling
}
catch (SQLException se)
{
// ... logging and error handling
}
複製代碼
存儲過程參數化
這個存儲過程使用參數化查詢,而未包含不安全的動態 SQL 構建。資料庫編譯此存儲過程時,會生成一個 SELECT 查詢的執行計劃,只允許原始的 SQL 語義被執行。任何參數值,即使是被注入的 SQL 語句也不會被執行,因為它們不是執行計劃的一部分。
CallableStatement = null
ResultSet results = null;
try
{
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
// ... Ensure that the length of userName and itemName is legitimate
// ...
cs = connection.prepareCall("{call sp_queryItem(?,?)}");
cs.setString(1, userName);
cs.setString(2, itemName);
results = cs.executeQuery();
// ... result set handling
}
catch (SQLException se)
{
// ... logging and error handling
}
複製代碼
Hibernate 參數化查詢
Hibernate 支持 SQL/HQL 參數化查詢。為了防止 SQL 注入以及改善性能,以上這些示例使用了參數化綁定 的方式來設置查詢參數。
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
Query hqlQuery = session.createQuery("from Item as item where item.owner = ? and item.itemName = ?");
hqlQuery.setString(1, userName);
hqlQuery.setString(2, itemName);
List<Item> rs = (List<Item>) hqlQuery.list();
複製代碼
HQL 基於名稱的參數化查詢
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
Query hqlQuery = session.createQuery("from Item as item where item.owner = :owner and item.itemName = :itemName");
hqlQuery.setString("owner", userName);
hqlQuery.setString("itemName", itemName);
List<Item> rs = (List<Item>) hqlQuery.list();
複製代碼
原生參數化查詢
String userName = ctx.getAuthenticatedUserName(); //this is a constant
String itemName = request.getParameter("itemName");
Query sqlQuery = session.createSQLQuery("select * from t_item where owner = ? and itemName = ?");
sqlQuery.setString(0, owner);
sqlQuery.setString(1, itemName);
List<Item> rs = (List<Item>) sqlQuery.list();
複製代碼
MyBatis 框架的修複方案
儘量使用 #描述參數,如果一定要使用 $,則需要自己過濾用戶輸入
模糊查詢 like SQL 注入修復建議
按照新聞標題對新聞進行模糊查詢,可將 SQL 查詢語句設計如下:
select * from news where name like concat(『%』,#{name }, 『%』)
複製代碼
採用預編譯機制,避免了 SQL 語句拼接的問題,從根源上防止了 SQL 注入漏洞的產生。
in 之後的參數 SQL 注入修復建議
在對新聞進行同條件多值查詢的時候,可使用 Mybatis 自帶循環指令解決 SQL 語句動態拼接的問題:
select * from news where id in<foreach collection="ids" item="item" open="("separator="," close=")">#{item} </foreach>
複製代碼
order by SQL 注入修復建議
在 Java 層面做映射預編譯機制只能處理查詢參數,其他地方還需要研發人員根據具體情況來解決。如前面提到的排序情景:
Select * from news where title =『淘寶』 order by #{time} asc,
複製代碼
這裡 time 不是查詢參數,無法使用預編譯機制,只能這樣拼接:
Select * from news where title =『淘寶』 order by ${time} asc
複製代碼
針對這種情況研發人員可以在 java 層面做映射來進行解決。如當存在發布時間 time 和點擊量 click 兩種排序選擇時,我們可以限制用戶只能輸入 1 和 2。
當用戶輸入 1 時,我們在代碼層面將其映射為 time,當用戶輸入 2 時,將其映射為 click。而當用戶輸入 1 和 2 之外的其他內容時,我們可以將其轉換為默認排序選擇 time(或者 click)。