徹底幹掉噁心的 SQL 注入漏洞, 一網打盡!

2021-02-19 芋道源碼
0x01簡介

文章主要內容包括:

0x02 JDBC介紹

JDBC:

是Java訪問資料庫的API,不依賴於特定資料庫(database-independent)

更多請參考http://www.oracle.com/technetwork/java/javase/jdbc/index.html

說明

直接使用JDBC的場景,如果代碼中存在分解SQL語句,那麼很有可能會產生注入,如

// concat sql
String sql = "SELECT * FROM users WHERE name ='"+ name + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

安全的寫法是使用參數化查詢(參數化查詢),即SQL語句中使用參數綁定(?佔位符)和PreparedStatement,如

// use ? to bind variables
String sql = "SELECT * FROM users WHERE name= ? ";
PreparedStatement ps = connection.prepareStatement(sql);
// 參數 index 從 1 開始
ps.setString(1, name);

還有一些情況,例如按名稱,列名稱排序,不能使用參數綁定,此時需要手工過濾,如通常按按順序排序,其名稱是有限的,因此可以使用白名單的方式來限制參數值

這裡需要注意的是,使用了PreparedStatement 並不意味著不會產生注入,如果在使用PreparedStatement之前,存在拆分sql語句,那麼仍然會導致注入,如

// 拼接 sql
String sql = "SELECT * FROM users WHERE name ='"+ name + "'";
PreparedStatement ps = connection.prepareStatement(sql);

看到這裡,大家肯定會好奇PreparedStatement是如何防止SQL注入的,來了解一下

正常情況下,用戶的輸入是作為參數值的,而在SQL注入中,用戶的輸入是作為SQL指令的一部分,會被資料庫進行編譯/解釋執行。當使用了PreparedStatement,帶佔位符(?)的sql語句只會被編譯一次,之後執行只是將佔位符替換為用戶輸入,並不會再次編譯/解釋,因此從根本上防止了SQL注入問題。

更詳細和準確的回答,請參考:

PreparedStatement如何避免或阻止SQL注入?如何使用Java PreparedStatement和CallableStatement修復SQL注入0x03 Mybatis介紹分為JDBC(原始SQL)和Hibernate(ORM)

更多請參考http://www.mybatis.org/

說明

在MyBatis中,使用XML文件或注釋來進行配置和映射,將接口和Java POJO(普通的舊Java對象)映射到資料庫記錄

XML例子

映射器界面

@Mapper
public interface UserMapper {
    User getById(int id);
}

XML配置文件

<select id="getById" resultType="org.example.User">
 SELECT * FROM user WHERE id = #{id}
</select>

注釋示例

@Mapper
public interface UserMapper {
    @Select("SELECT * FROM user WHERE id= #{id}")
    User getById(@Param("id") int id);
}

可以看到,使用者需要自己編寫SQL語句,因此當使用不當時,會導致注入問題

與使用JDBC不同的是,MyBatis使用#{}和${}來進行參數值替換

使用#{}語法時,MyBatis會自動生成PreparedStatement,使用參數綁定(?)的方式來設置值,上述兩個示例等價的JDBC查詢代碼如下:

String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement ps = connection.prepareStatement(sql);
ps.setInt(1, id);

因此#{}可以有效防止SQL注入,詳細可參考http://www.mybatis.org/mybatis-3/sqlmap-xml.html 字符串替換部分

而使用${}語法時,MyBatis會直接注入原始字符串,即相當於分段字符串,因此會導致SQL注入,如

<select id="getByName" resultType="org.example.User">
 SELECT * FROM user WHERE name = '${name}' limit 1
</select>

名稱估計' or '1'='1,實際執行的語句為

SELECT * FROM user WHERE name = '' or '1'='1' limit 1

因此建議儘量使用#{},但有些時候,如按語句排序,使用#{}會導致錯誤,如

ORDER BY #{sortBy}

sortBy參數估計name,替換後會成為

ORDER BY "name"

即以字符串「 name」來排序,而不是按名稱排序,詳細可參考https://stackoverflow.com/a/32996866/6467552。

這種情況就需要使用 ${}

ORDER BY ${sortBy}

使用了${}後,使用者需要自行過濾輸入,方法有:

代碼層使用白名單的方式,限制sortBy允許的值,如只能為name,email變量,異常情況則設置為替換值name

在XML配置文件中,使用if標籤來進行判斷

Mapper接口方法

List<User> getUserListSortBy(@Param("sortBy") String sortBy);

xml配置文件

<select id="getUserListSortBy" resultType="org.example.User">
  SELECT * FROM user
  <if test="sortBy == 'name' or sortBy == 'email'">
 order by ${sortBy}
  </if>
</select>

因為Mybatis不支持else,需要替換值的情況,可以使用 choose (when, otherwise)

<select id="getUserListSortBy" resultType="org.example.User">
  SELECT * FROM user
  <choose>
    <when test="sortBy == 'name' or sortBy == 'email'">
      order by ${sortBy}
    </when>
    <otherwise>
      order by name
    </otherwise>
 </choose>
</select>

更多場景

除了order by之外,還有一些可能會使用到${}情況,可以使用其他方法避免,如

像語句

如需要使用通配符(通配符%和_),可以

使用bind標籤來構造新參數,然後再使用#{}

Mapper接口方法

List<User> getUserListLike(@Param("name") String name);

xml配置文件

<select id="getUserListLike" resultType="org.example.User">
    <bind name="pattern" value="'%' + name + '%'" />
    SELECT * FROM user
    WHERE name LIKE #{pattern}
</select>

<bind>語句內部的值為OGNL表達式,具體可參考http://www.mybatis.org/mybatis-3/dynamic-sql.html bind部分

使用SQL concat()函數

<select id="getUserListLikeConcat" resultType="org.example.User">
 SELECT * FROM user WHERE name LIKE concat ('%', #{name}, '%')
</select>

除了注入問題之外,這裡還需要對用戶的輸入進行過濾,永久有通配符,否則在表中數據量中斷的時候,假設用戶輸入為%%,會進行全表模糊查詢,嚴重情況下可導致DOS ,參考http://www.tothenew.com/blog/sql-wildcards-is-your-application-safe/

IN條件

使用<foreach>和#{}

Mapper接口方法

List<User> getUserListIn(@Param("nameList") List<String> nameList);

xml配置文件

<select id="selectUserIn" resultType="com.example.User">
  SELECT * FROM user WHERE name in
  <foreach item="name" collection="nameList"
           open="(" separator="," close=")">
        #{name}
  </foreach>
</select>

具體可參考http://www.mybatis.org/mybatis-3/dynamic-sql.html foreach部分

極限語句

直接使用#{}即可

Mapper接口方法

List<User> getUserListLimit(@Param("offset") int offset, @Param("limit") int limit);

xml配置文件

<select id="getUserListLimit" resultType="org.example.User">
 SELECT * FROM user limit #{offset}, #{limit}
</select>

0x04 JPA和休眠介紹

JPA:

ORM(對象關係映射)持久層API,需要有具體的實現

更多請參考https://en.wikipedia.org/wiki/Java_Persistence_API

休眠:

更多請參考http://hibernate.org/

說明

這裡有一種錯誤的認識,使用了ORM框架,就不會有SQL注入。而實際上,在Hibernate中,支持HQL(Hibernate查詢語言)和native sql查詢,前者存在HQL注入,封裝和之前JDBC存在相同的注入問題,來具體看一下

高品質

HQL查詢例子

Query<User> query = session.createQuery("from User where name = '" + name + "'", User.class);
User user = query.getSingleResult();

這裡的User為類名,和原生SQL類似,拼接會導致注入

正確的用法:

Query<User> query = session.createQuery("from User where name = ?", User.class);
query.setParameter(0, name);

Query<User> query = session.createQuery("from User where name = :name", User.class);
query.setParameter("name", name);

Query<User> query = session.createQuery("from User where name in (:nameList)", User.class);
query.setParameterList("nameList", Arrays.asList("lisi", "zhaowu"));

User user = new User();
user.setName("zhaowu");
Query<User> query = session.createQuery("from User where name = :name", User.class);
// User 類需要有 getName() 方法
query.setProperties(user);

本機SQL

存在SQL注入

String sql = "select * from user where name = '" + name + "'";
// deprecated
// Query query = session.createSQLQuery(sql);
Query query = session.createNativeQuery(sql);

使用參數綁定來設置參數值

String sql = "select * from user where name = :name";
// deprecated
// Query query = session.createSQLQuery(sql);
Query query = session.createNativeQuery(sql);
query.setParameter("name", name);

JPA

JPA中使用JPQL(Java持久性查詢語言),同時也支持本地sql,因此和Hibernate存在類似的問題,這裡就不再細說,注意到的可以參考[如何使用Java Persistence API修復SQL注入( JPA)

相關焦點

  • SQL注入攻擊詳解
    注入可以藉助資料庫的存儲過程進行提權等操作4、判斷Sql注入點4.1 判斷是否存在sql注入漏洞通常情況下,可能存在 Sql 注入漏洞的 Url 是類似這種形式 :http://xxx.xxx.xxx/abcd.php?id=XX對 Sql 注入的判斷,主要有兩個方面:判斷該帶參數的 Url 是否存在 Sql 注入?
  • Myql SLEEP函數和SQL注入
    sqlmap是使用Python編寫的一款資料庫sql注入掃描工具,目前支持常見的mysql、oracel、postgresql、sql server,access,db2,sqlite等數據的安全漏洞(sql注入)。
  • Java web安全黑客攻防之sql注入
    1.什麼是sql注入sql注入通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙伺服器執行惡意的SQL命令通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串,最終達到欺騙伺服器執行惡意的SQL
  • SQL注入、XSS以及CSRF分別是什麼?
    什麼是SQL注入、XSS和CSRF?本篇文章就來帶大家了解一下SQL注入、XSS和CSRF,有一定的參考價值,有需要的朋友可以參考一下,希望對你有所幫助。SQL注入SQL注入是屬於注入式攻擊,這種攻擊是因為在項目中沒有將代碼與數據(比如用戶敏感數據)隔離,在讀取數據的時候,錯誤的將數據作為代碼的一部分執行而導致的。典型的例子就是當對SQL語句進行字符串拼接的時候,直接使用未轉義的用戶輸入內容作為變量。
  • 淺談開啟magic_quote_gpc後的sql注入攻擊與防範
    通過啟用php.ini配置文件中的相關選項,就可以將大部分想利用SQL注入漏洞的駭客拒絕於門外  通過啟用php.ini配置文件中的相關選項,就可以將大部分想利用SQL注入漏洞的駭客拒絕於門外。';這時候通過url地址欄輸入的單引號(')將被加上反斜線,該sql語句將失效。
  • 常見web漏洞(Sql注入、XSS、CSRF)原理以及攻防總結
    作者:quanweibai     文章來源:GitHubSql注入所謂SQL注入式攻擊,就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串
  • SQL 注入攻防入門詳解
    這幾天把sql注入的相關知識整理了下,希望大家多多提意見。(對於sql注入的攻防,我只用過簡單拼接字符串的注入及參數化查詢,可以說沒什麼好經驗,為避免後知後覺的犯下大錯,專門查看大量前輩們的心得,這方面的資料頗多,將其精簡出自己覺得重要的,就成了該文)下面的程序方案是採用 ASP.NET + MSSQL,其他技術在設置上會有少許不同。
  • 【雲演情報】Discuz_7.2_faq.php_sql注入;全球IPv4地址正式耗盡;FB與Twitter再現漏洞.
    Discuz_7.2在faq.php存在sql注入漏洞,攻擊者可以利用此漏洞執行任意的sql命令,可以造成資料庫信息洩露,嚴重者可導致伺服器被控制。JTBCv3.0.1.6版本manage.php頁面存在代碼執行漏洞getshellJTBC網站內容管理系統是一套可對現有模塊進行擴充與克隆的網站系統核心,採用UTF-8編碼,採取 語言/代碼/程序 兩兩分離的技術模式。  JTBC應用3.0.1.6版本在console/file/manage.php文件中存在任意代碼執行漏洞。
  • 什麼是SQL 注入?
    SQL注入是一種非常常見的資料庫攻擊手段,SQL注入漏洞也是網絡世界中最普遍的漏洞之一。大家也許都聽過某某學長通過攻擊學校資料庫修改自己成績的事情,這些學長們一般用的就是SQL注入方法。SQL注入其實就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。簡單來說,就是數據「越俎代庖」做了代碼才能幹的事情。
  • php mysql SQL注入語句構造
    ,本文主要是借對Okphp BBS v1.3一些文件得簡單分析,來談談php+mysql注射語句構造方式,希望本文對你有點幫助。   聲明:文章所有提到的「漏洞」,都沒有經過測試,可能根本不存在,其實有沒有漏洞並不重要,重要的是分析思路和語句構造。   二.
  • SQL注入的幾種類型和原理
    布爾盲注原理布爾盲住指得是代碼存在SQL注入漏洞,但是頁面既不會回顯數據,也不會回顯錯誤信息,只返回 」Right「 和 」Wrong」。通過構造語句,來判斷資料庫信息的正確性,通過頁面返回的 」真「 和 」假「 來識別判斷是否正確。
  • 特殊場景的sql注入思路
    上一篇介紹了sql注入的基礎知識以及手動注入方法,但是在實際的環境中往往不會像靶場中那樣簡單。今天我就來為大家介紹一種特殊場景的sql注入思路。用戶名與密碼分開驗證的情況第一個場景我們以We Chall平臺的Training: MySQL II 一題為例。
  • 何謂SQL 注入,這個漫畫告訴你
    轉自:https://jizhi.im/blog/post/sql_injection_intro先來看一副很有意思的漫畫:今天我們來聊一聊SQL注入相關的內容。何謂SQL注入?SQL注入是一種非常常見的資料庫攻擊手段,SQL注入漏洞也是網絡世界中最普遍的漏洞之一。大家也許都聽過某某學長通過攻擊學校資料庫修改自己成績的事情,這些學長們一般用的就是SQL注入方法。SQL注入其實就是惡意用戶通過在表單中填寫包含SQL關鍵字的數據來使資料庫執行非常規代碼的過程。
  • 滲透測試公司實戰注入攻擊拿下客戶網站
    近來,利用sql注入、xss和文件上傳漏洞,成功getshell的一個客戶網站(必須要拿到客戶授權滲透測試許可證明才可以,不得違法入侵),這裡簡單記錄一下整個過程,與大家分享。收集信息,查找漏洞。然後,尋找漏洞,個人一般都是從尋找帶有XSS漏洞的sql注入開始,打開網站,burp打開,進入XSS漏洞平臺,打開尋找漏洞的途徑。
  • SQL注入常規Fuzz全記錄
    前言本篇文章是在做ctf bugku的一道sql 盲注的題(題目地址:注入題目)中運用了fuzz的思路,完整記錄整個fuzz的過程
  • 最詳細的SQL注入相關的命令整理
    /display.asp,行173、在檢測索尼中國的網站漏洞時,分明已經確定了漏洞存在卻無法在這三種漏洞中找到對應的類型。/display.asp,行177、 列出當前所有的資料庫名稱:select * from master.dbo.sysdatabases 列出所有列的記錄select name from master.dbo.sysdatabases 僅列出name列的記錄8、 不需xp_cmdshell支持在有注入漏洞的SQL伺服器上運行CMD命令:create
  • SQL 注入常規 Fuzz 全記錄
    (給數據分析與開發加星標,提升數據技能)來自:FreeBuf.COM,作者:Conanwww.freebuf.com/articles/web/190019.html前言本文是在做ctf bugku的一道sql
  • 最新DEDECMS 存 SQL 注入 0day 漏洞 - OSCHINA - 中文開源技術...
    4月29日消息:國內安全研究團隊「知道創宇」稱截獲到最新DEDECMS SQL注入0day,DEDECMS官網目前提供下載的最新版
  • web安全之SQL注入(16)——delete和like注入
    delete from users where id=14 一般情況是網站後臺的sql語句,當我們測試刪除功能是否存在注入時,一定你要是用and測試,不要使用or測試。當使用or進行測試,跟一個布爾假值,這時如果前面的條件為真,你使用or跟一個假值,只會刪除一條數據,這裡問題不大,繼續測試
  • 雲安全日報201201:紅帽身份驗證訪問控制系統發現SQL注入漏洞,需要...
    12月1日,RedHat發布了安全更新,修復了Red Hat Single Sign-On中發現的SQL注入漏洞。以下是漏洞詳情:漏洞詳情來源:https://access.redhat.com/errata/RHSA-2020:5254CVE-2020-25638 CVSS評分:7.4 嚴重程度:高SQL注入即是指web應用程式對用戶輸入數據的合法性沒有判斷