零、本文涉及知識點
sqlmap寫一句馬的具體過程
堆疊注入
union injection（聯(lián)合注入）
常見的注入繞過姿勢
sql注入預(yù)編譯與常見繞過姿勢
一、sqlmap寫一句馬的過程（-- os-shell）
1.1 簡述過程
先寫一個文件上傳的文件，名字為“ tmpujhum.php ”。
然后通過這個文件上傳的木馬，將shell（tmpbcluy.php）上傳，
執(zhí)行命令的木馬名字為“ tmpbcluy.php ”
具體過程可以參考： https://xz.aliyun.com/t/7942
1.2 一個小問題
都可以直接通過命令寫文件了，為什么還要先寫一個上傳文件的木馬，在通過這個木馬上傳一句馬？
*答：**
sqlmap官方這么寫得代碼，所在按照這個流程，開玩笑~~
主要原因是大多數(shù)waf的對命令直接寫文件的監(jiān)控比上傳木馬的監(jiān)控嚴(yán)格。
即通過這種“多此一舉”的思路，可以提高上傳成功一句馬的概率
二、堆疊注入：
2.1 什么是堆疊注入
在SQL中，分號（;）是用來表示一條sql語句的結(jié)束。
試想一下我們在 ; 結(jié)束一個sql語句后繼續(xù)構(gòu)造下一條語句，會不會一起執(zhí)行？
因此這個想法也就造就了堆疊注入。
2.2 如何判斷存在堆疊注入？
~“ id=1 ”正常
~試試“ id=1a ”，假設(shè)報錯，說明數(shù)據(jù)沒有被強轉(zhuǎn)
~在試試“ id=1; ”假設(shè)沒有報錯，說明“;”沒有被代入查詢，而是當(dāng)做了sql語句的結(jié)束符
~此時，此位置大概率存在堆疊注入
2.3 局限性
堆疊注入的局限性在于并不是每一個環(huán)境下都可以執(zhí)行，
可能受到API或者數(shù)據(jù)庫引擎不支持的限制，
當(dāng)然了權(quán)限不足也可以解釋為什么攻擊者無法修改數(shù)據(jù)或者調(diào)用一些程序。
三、union injection（聯(lián)合注入）
3.1 原理
絕大多數(shù)的sql注入都是利用的此姿勢，
詳細(xì)不在贅述，可以直接參考之前的文章。
3.2 與堆疊注入的區(qū)別
區(qū)別就在于union 或者union all執(zhí)行的語句類型是有限的，僅僅可以用來執(zhí)行查詢語句，
而堆疊注入可以執(zhí)行的是任意的語句。
**例如以下這個例子，即堆疊可以執(zhí)行成功，聯(lián)合注入不能成功**
用戶輸入：1; DELETE FROM products服務(wù)器端生成的sql語句為：
Select * from products where productid=1;DELETE FROM products
當(dāng)執(zhí)行查詢后，第一條顯示查詢信息，第二條則將整個表進行刪除。
四、常見的sql注入繞過姿勢
4.1 Waf特性：
絕大多數(shù)的waf都是通過正則匹配過濾/攔截請求
一般一個waf會同時上線N個規(guī)則，這些規(guī)則同時生效的情況下，僅僅饒過一個依舊會被攔截
4.2 繞waf的核心思路：
繞過waf正則匹配規(guī)則的同時，注入的sql語句可以被正常解析執(zhí)行。
4.3 常見的思路
數(shù)據(jù)上：
大小寫 、、很老的waf可以繞過
加解密、編碼解碼
等價函數(shù) union select == union all select
特殊符號
反序列化
注釋符混用 、、mysql特性：
database/**/() == database()
內(nèi)聯(lián)注釋，如/*一個sql版本號sql執(zhí)行內(nèi)容*/，具體不在展開
方式：
更改提交方式 、、部分waf默認(rèn)僅僅檢測get（但是假設(shè)后端不接收post也沒什么卵用）；
變異
其他：
FUZZ
、、模糊測試，使用腳本/工具生成大量payload，直接爆破waf，看看哪些語句可以過waf
數(shù)據(jù)庫特性
、、mysql特性：
union%23a%0Aselect 1,2,3#
== union#a（換號）select 1,2,3#
== union select 1,2,3#
、、mysql特性：
/*!select * from users*/ 會正常執(zhí)行
垃圾數(shù)據(jù)溢出
HTTP參數(shù)污染
、、多個參數(shù)的情況下，一般默認(rèn)取最后一個
、、?id=1/**&id=-1%20union%20select%201,2,3%23*/
即“ 1/**-1 union select 1,2,3#*/ ”
在mysql之中“ /** 內(nèi)容不會執(zhí)行 */ ”所以WAF認(rèn)為是安全的，
但是因為Apache的特性，
其最終接收的參數(shù)為：“ -1 union select 1,2,3#*/ ”
靜態(tài)資源
、、即本來為php?id=1 改為 php/a.txt（b.js等）?id=1
結(jié)果不受影響，但是可以過一些老waf
用注釋配合參數(shù)污染繞waf的成功率是比較高的
使用sqlmap注意，
~UA自帶的要改一下，參數(shù)就可以改，可以改為百度等搜索引擎的UA
~可以設(shè)置繞waf腳本來提高成功率，而且腳本寫也挺簡單
~自己測試的時候，可以用參數(shù)將sqlmap的流量代理到burp，然后對比自己正常瀏覽器的流量，看看區(qū)別
~必要的時刻，連接代理池直接暴力配合開干
五、Sql注入預(yù)編譯與常見繞過姿勢
5.1 概述
預(yù)編譯一般在Java的框架中使用，在提高sql語句效率的同時也可以攔截掉很多注入的情況，
但是仍可以被繞過的，
5.2 具體方式
5.2.1 ASC/DESC
應(yīng)用場景：
當(dāng)應(yīng)用顯示多條數(shù)據(jù)時，通常可以選擇正向排序或者逆向排序，此時就會用到 ASC/DESC
ASC/DESC 是SQL語句中影響語義的關(guān)鍵字，是不能用單引號引起來的
假設(shè)ASC/DESC是接收的前端傳入，即存在被注入的風(fēng)險。
如何處理：
比較安全的方式是使用白名單，排序方式也只有兩種，可使用簡單的條件判斷語句
|
1
2
3
4
5
6
|
<?php if($_POST['order'] === 'DESC'){ $order = 'DESC'; }else{ $order = 'ASC' } |
5.2.2 表名/字段名
應(yīng)用場景：
表名與列名是不能被預(yù)編譯的，這是由于在預(yù)編譯生成語法樹的過程中，
預(yù)處理器在檢查解析后的語法樹時，會確定數(shù)據(jù)表和數(shù)據(jù)列是否存在，
此兩者必須為具體值，不能被占位符 ? 所替代
假設(shè)表名/字段名是接收的前端傳參，即存在被注入的風(fēng)險
如何處理：
參考下邊order by的情況
5.2.3 order by
order by 用來指定某個字段作為排序依據(jù)，前面也解釋了字段名不能使用預(yù)編譯
假設(shè)order by后邊的字段是接收的前端傳參，即存在被注入的風(fēng)險
具體的一些繞過方法可以搜索“ case when ”
如何處理：
為了避免直接拼接SQL語句，可以將列名定義為常量，
再通過白名單的方式進行拼接，能夠有效防止SQL注入
當(dāng)然，這里也可以單獨對傳入的語句配合正則匹配過濾，但是效果不如這種方式簡潔有效。
前端表單：
|
1
2
3
4
5
6
7
8
|
<form action="" method="post"> <select name="order"> <option value="0">id</option> <option value="1">name</option> <option value="2">age</option> </select> <input type="submit" name="submit"></form> |
白名單函數(shù)：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<?php $i = $_POST['order']; switch($i){ case 0: $order = "id"; break; case 1: $order = "name"; break; default: $order = "age"; break; } |
5.2.4小結(jié)：
假設(shè)ASC/DESC是接收的前端傳入，即存在被注入的風(fēng)險。
假設(shè)表名/字段名是接收的前端傳參，即存在被注入的風(fēng)險
假設(shè)order by后邊的字段是接收的前端傳參，即存在被注入的風(fēng)險
總結(jié)
到此這篇關(guān)于sql注入的一些零散知識點的文章就介紹到這了,更多相關(guān)sql注入零散知識點內(nèi)容請搜索服務(wù)器之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持服務(wù)器之家！
原文鏈接：https://blog.csdn.net/weixin_43970718/article/details/120556294
