sql注入報錯注入原理詳解

前言

我相信很多小夥伴在玩sql注入報錯注入時都會有一個疑問，為什麼這麼寫就會報錯？曾經我去查詢的時候，也沒有找到滿意的答案，時隔幾個月終於找到搞清楚原理，特此記錄，也希望後來的小夥伴能夠少走彎路

0x01

我們先來看一看現象，我這裡有一個users表，裡面有五條資料：

然後用我們的報錯語句查詢一下：

select count(*),(concat(floor(rand()*2),(select version())))x from users group by x

成功爆出了資料庫的版本號。
要理解這個錯誤產生的原因，我們首先要知道group by語句都做了什麼。我們用一個studetn表來看一下：

注：這裡有特別重要的一點，group by後面的欄位時虛擬表的主鍵，也就是說它是不能重複的，這是後面報錯成功的關鍵點，其實前面的報錯語句我們已經可以窺見點端倪了

0x02

正如我前面所說的，報錯的主要原因時虛擬表的主鍵重複了，那麼我們就來看一下它到底是在哪裡，什麼時候重複的。這裡rand()函式就登場了。
首先我們先來了解rand()函式的用法：
1.用來生成一個0~1的數
2.還可以給rand函式傳一個引數作為rand()的種子，然後rand函式會依據這個種子進行隨機生成。
那他們的區別是什麼呢？我們來看一下，這兩個語句的執行效果：

可以看到rand()生成的資料毫無規律，而rand(0)生成的資料則有規律可循，是：
0110 0110

注：如果你覺得資料不夠，證明不了rand()的隨機性，你可以自己多插入幾條資料再查詢試一下。

0x03

現在我們弄清楚了group by語句的工作流程，以及rand()與rand(0)的區別，那麼接下來就是重點了，mysql官方說，在執行group by語句的時候，group by語句後面的欄位會被運算兩次。
第一次：我們之前不是說了會把group by後面的欄位值拿到虛擬表中去對比嗎，在對比之前肯定要知道group by後面欄位的值，所以第一次的運算就發生在這裡。
第二次：現在假設我們下一次掃描的欄位的值沒有在虛擬表中出現，也就是group by後面的欄位的值在虛擬表中還不存在，那麼我們就需要把它插入到虛擬表中，這裡在插入時會進行第二次運算，由於rand函式存在一定的隨機性，所以第二次運算的結果可能與第一次運算的結果不一致，但是這個運算的結果可能在虛擬表中已經存在了，那麼這時的插入必然導致錯誤！
所以我們現在通過一個例子來驗證我們的理論，拿出我們最開始的例子：

select count(*),(concat(floor(rand(0)*2),'@',(select version())))x from users group by x

宣告：users表就是本文第一個表，表中有五條資料

注意我這裡用的是rand(0)，不是rand()，
rand(0)生成的有規律的序列：

我們跟著剛剛的思路走，最開始的虛擬表是空的，就像下面一樣：

當我掃描原始表的第一項時，第一次計算，floor(rand(0)*2)是0，然後和資料庫的版本號（假設就是5.7.19）拼接，到虛擬表裡去尋找x有沒有x的值是[email protected]的資料項，結果顯然是沒有，那麼接下來就將它插入到上表中，但是還記得嗎，在插入之前會進行第二次計算，這時x的值就變成了[email protected]，所以虛擬表變成了下面這樣：

現在掃描原始表的第二項，第一次計算x==’[email protected]‘，已經存在，不需要進行第二次計算，直接插入，得到下表：

掃描原始表的第三項，第一次計算x==’[email protected]’，虛擬表中找不到，那麼進行第二次計算，這時x==’[email protected]’，然後插入，但是插入的時候問題就發生了，虛擬表中已經存在以[email protected]為主鍵的資料項了，插入失敗，然後就報錯了！

上面是使用rand(0)的情況，rand(0)是比較穩定的，所以每次執行都可以報錯，但是如果使用rand()的話，因為它生成的序列是隨機的嘛，所以並不是每次執行都會報錯，下面是我的測試結果：

執行了五次，報錯兩次，所以是看運氣。

總結

總之，報錯注入，rand(0),floor(),group by缺一不可

預見未來的最好方式就是自己去創造一個

歡迎交流，我會第一時間回覆