一、介紹

#（井號）：MyBatis使用#{}作為參數(shù)占位符時，會創(chuàng)建預處理語句（Prepared Statement），并將參數(shù)值作為預處理語句的參數(shù)綁定到SQL語句中。

使用#可以防止SQL注入攻擊，因為MyBatis會自動對參數(shù)值進行轉(zhuǎn)義處理。

#{}內(nèi)部可以是參數(shù)的名稱或者參數(shù)的索引位置（例如#{param1}或者#{1}）。

SELECT * FROM users WHERE username = #{username}

$（美元符號）：MyBatis使用${}作為參數(shù)占位符時，不會創(chuàng)建預處理語句。而是直接將參數(shù)值拼接到SQL語句中。

使用$不會對參數(shù)值進行轉(zhuǎn)義，因此容易受到SQL注入攻擊，除非參數(shù)值是可信的或者已經(jīng)進行了適當?shù)奶幚怼?/p>

${}內(nèi)部通常是參數(shù)的名稱。

SELECT * FROM ${tableName} WHERE id = #{id}

$和#的主要區(qū)別：

a、安全性：#提供預處理語句的參數(shù)綁定，更安全，可以有效防止SQL注入；$直接將參數(shù)值拼接到SQL語句中，存在SQL注入的風險。

b、性能：#通常性能更好，因為預處理語句可以重復使用，而$每次都會生成新的SQL語句。

c、使用場景：#適用于大多數(shù)情況，特別是當參數(shù)是用戶輸入時；$適用于需要動態(tài)指定表名或列名的情況，因為這些部分不能作為預處理語句的參數(shù)。

因此，除非有特殊需求，通常推薦使用#來提高SQL語句的安全性和性能。

二、sql注入風險實例

1、存在 SQL 注入風險的情況（使用 $）：

// Mapper 接口
public interface UserMapper {
    User selectUserByUsername(String username);
}
// XML 映射文件（存在注入風險）
<select id="selectUserByUsername" resultType="User">
    SELECT * FROM users WHERE username = '${username}'
</select>

攻擊示例：當輸入的 username 為 ' OR '1'='1 時，最終生成的 SQL 語句如下：

SELECT * FROM users WHERE username = '' OR '1'='1'

這個 SQL 語句會讓所有用戶記錄都被返回。

2、安全處理方式（使用#）

// Mapper 接口
public interface UserMapper {
    User selectUserByUsername(String username);
}
// XML 映射文件（安全）
<select id="selectUserByUsername" resultType="User">
    SELECT * FROM users WHERE username = #{username}
</select>

3、預編譯過程

編譯后的 SQL：SELECT * FROM users WHERE username = ?
實際執(zhí)行時：如果輸入的 username 是 ' OR '1'='1，JDBC 會對其進行轉(zhuǎn)義，轉(zhuǎn)義后的值為 \' OR \'1\'=\'1。
最終效果：查詢會去匹配一個名為 ' OR '1'='1 的用戶，顯然這樣的用戶是不存在的，注入攻擊也就失敗了。

到此這篇關于mybaits中$與#的區(qū)別解析的文章就介紹到這了,更多相關mybaits $與#區(qū)別內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論