原理
攻擊者構造的惡意資料存儲在資料庫後,惡意資料被讀取并進入到SQL查詢語句所導緻的注入
防禦者可能在使用者輸入惡意資料時對其中的特殊字元進行了轉義處理,但在惡意資料插入到資料庫時被處理的資料又被還原并存儲在資料庫中
當Web程式調用存儲在資料庫中的惡意資料并執行SQL查詢時,就發生了SQL二次注入
二次注入,可以概括為以下兩步:
第一步:插入惡意資料
進行資料庫插入資料時,對其中的特殊字元進行了轉義處理,在寫入資料庫的時候又保留了原來的資料。
第二步:引用惡意資料
開發者預設存入資料庫的資料都是安全的,在進行查詢時,直接從資料庫中取出惡意資料,沒有進行進一步的檢驗的處理。

作者:Ackerzy
連結:https://www.jianshu.com/p/3fe7904683ac
來源:簡書
案例(sqli-lab-less-24)
- 最初的使用者名密碼:admin/admin
SQL注入--二次注入原理案例(sqli-lab-less-24) -
界面是這樣的,可以新增賬號
嘗試用admin’#進行注入,失敗。
而源代碼中也确實進行了轉義處理,是以此處使用admin’#肯定失敗
SQL注入--二次注入原理案例(sqli-lab-less-24) -
新增賬號登入後,發現頁面跳轉到了修改密碼的功能頁面
并且修改密碼界面沒有驗證原來的密碼
猜測Sql語句可能是:
可以考慮二次注入Update users set password=’xxx’ where username=’ xxx ’
SQL注入--二次注入原理案例(sqli-lab-less-24) -
注冊一個名為admin’#的賬号,注冊成功後的資料庫内容
傳入的username、password、re_password仍均被mysql_escape_string進行了轉義處理,但是在資料庫中還是插入了admin’#
這是因為當資料寫入到資料庫的時候反斜杠會被移除,是以寫入到資料庫的内容就是原始資料,并不會在前面多了反斜杠。SQL注入--二次注入原理案例(sqli-lab-less-24) - 登入成功
SQL注入--二次注入原理案例(sqli-lab-less-24) - 修改密碼為111,提示成功
SQL注入--二次注入原理案例(sqli-lab-less-24) - 使用admin/111,成功登入 此時檢視資料庫,admin’#密碼依舊是123456,而admin密碼已經被修改為111
SQL注入--二次注入原理案例(sqli-lab-less-24) SQL注入--二次注入原理案例(sqli-lab-less-24)