<meta name="keywords" content="HTML,ASP,PHP,SQL">

<meta http-equiv="charset" content="iso-8859-1">
<meta http-equiv="expires" content="31 Dec 2008">

.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)。