激情久久久_欧美视频区_成人av免费_不卡视频一二三区_欧美精品在欧美一区二区少妇_欧美一区二区三区的

服務器之家:專注于服務器技術及軟件下載分享
分類導航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|數據庫技術|

服務器之家 - 數據庫 - 數據庫技術 - 詳細聊聊關于sql注入的一些零散知識點

詳細聊聊關于sql注入的一些零散知識點

2021-12-15 16:38劃水的小白白 數據庫技術

SQL注入攻擊是通過將惡意的SQL查詢或添加語句插入到應用的輸入參數中,再在后臺SQL服務器上解析執行進行的攻擊,它目前是黑客對數據庫進行攻擊的最常用的手段之一,這篇文章主要給大家介紹了關于sql注入的一些零散知識點,需要的

零、本文涉及知識點

sqlmap寫一句馬的具體過程

堆疊注入

union injection(聯合注入)

常見的注入繞過姿勢

sql注入預編譯與常見繞過姿勢

一、sqlmap寫一句馬的過程(-- os-shell)

1.1 簡述過程

先寫一個文件上傳的文件,名字為“ tmpujhum.php ”。

然后通過這個文件上傳的木馬,將shell(tmpbcluy.php)上傳,

執行命令的木馬名字為“ tmpbcluy.php ”

具體過程可以參考: https://xz.aliyun.com/t/7942

1.2 一個小問題

都可以直接通過命令寫文件了,為什么還要先寫一個上傳文件的木馬,在通過這個木馬上傳一句馬?

*答:**

sqlmap官方這么寫得代碼,所在按照這個流程,開玩笑~~

主要原因是大多數waf的對命令直接寫文件的監控比上傳木馬的監控嚴格。

即通過這種“多此一舉”的思路,可以提高上傳成功一句馬的概率

二、堆疊注入:

2.1 什么是堆疊注入

在SQL中,分號(;)是用來表示一條sql語句的結束。

試想一下我們在 ; 結束一個sql語句后繼續構造下一條語句,會不會一起執行?

因此這個想法也就造就了堆疊注入。

2.2 如何判斷存在堆疊注入?

~“ id=1 ”正常

~試試“ id=1a ”,假設報錯,說明數據沒有被強轉

~在試試“ id=1; ”假設沒有報錯,說明“;”沒有被代入查詢,而是當做了sql語句的結束符

~此時,此位置大概率存在堆疊注入

2.3 局限性

  堆疊注入的局限性在于并不是每一個環境下都可以執行, 

  可能受到API或者數據庫引擎不支持的限制, 

  當然了權限不足也可以解釋為什么攻擊者無法修改數據或者調用一些程序。

三、union injection(聯合注入)

3.1 原理

絕大多數的sql注入都是利用的此姿勢,

詳細不在贅述,可以直接參考之前的文章。

3.2 與堆疊注入的區別

區別就在于union 或者union all執行的語句類型是有限的,僅僅可以用來執行查詢語句,

而堆疊注入可以執行的是任意的語句。

**例如以下這個例子,即堆疊可以執行成功,聯合注入不能成功**

用戶輸入:1; DELETE FROM products服務器端生成的sql語句為:

  Select * from products where productid=1;DELETE FROM products

當執行查詢后,第一條顯示查詢信息,第二條則將整個表進行刪除。

四、常見的sql注入繞過姿勢

4.1 Waf特性:

 絕大多數的waf都是通過正則匹配過濾/攔截請求

 一般一個waf會同時上線N個規則,這些規則同時生效的情況下,僅僅饒過一個依舊會被攔截

4.2 繞waf的核心思路:

 繞過waf正則匹配規則的同時,注入的sql語句可以被正常解析執行。

4.3 常見的思路

數據上:

  大小寫           、、很老的waf可以繞過

  加解密、編碼解碼

  等價函數         union select == union all select

  特殊符號

  反序列化

  注釋符混用       、、mysql特性:   

                   database/**/() == database()  

                   內聯注釋,如/*一個sql版本號sql執行內容*/,具體不在展開      

方式:

 更改提交方式      、、部分waf默認僅僅檢測get(但是假設后端不接收post也沒什么卵用);

 變異

其他:

  FUZZ        

    、、模糊測試,使用腳本/工具生成大量payload,直接爆破waf,看看哪些語句可以過waf  

  數據庫特性

    、、mysql特性:

      union%23a%0Aselect 1,2,3#

    == union#a(換號)select 1,2,3#  

    == union select 1,2,3#

        、、mysql特性:

       /*!select * from users*/ 會正常執行

  垃圾數據溢出

  HTTP參數污染   

      、、多個參數的情況下,一般默認取最后一個  

                、、?id=1/**&id=-1%20union%20select%201,2,3%23*/  

                   即“ 1/**-1 union select 1,2,3#*/ ”

                在mysql之中“ /** 內容不會執行  */ ”所以WAF認為是安全的,

    但是因為Apache的特性,

                      其最終接收的參數為:“ -1 union select 1,2,3#*/ ”

  靜態資源        

      、、即本來為php?id=1   改為  php/a.txt(b.js等)?id=1  

       結果不受影響,但是可以過一些老waf

用注釋配合參數污染繞waf的成功率是比較高的     

使用sqlmap注意,

~UA自帶的要改一下,參數就可以改,可以改為百度等搜索引擎的UA

~可以設置繞waf腳本來提高成功率,而且腳本寫也挺簡單

~自己測試的時候,可以用參數將sqlmap的流量代理到burp,然后對比自己正常瀏覽器的流量,看看區別

~必要的時刻,連接代理池直接暴力配合開干

五、Sql注入預編譯與常見繞過姿勢

5.1 概述

預編譯一般在Java的框架中使用,在提高sql語句效率的同時也可以攔截掉很多注入的情況,

但是仍可以被繞過的,

5.2 具體方式

5.2.1 ASC/DESC

應用場景:

當應用顯示多條數據時,通常可以選擇正向排序或者逆向排序,此時就會用到 ASC/DESC

ASC/DESC 是SQL語句中影響語義的關鍵字,是不能用單引號引起來的

假設ASC/DESC是接收的前端傳入,即存在被注入的風險。

詳細聊聊關于sql注入的一些零散知識點

如何處理:

比較安全的方式是使用白名單,排序方式也只有兩種,可使用簡單的條件判斷語句

?
1
2
3
4
5
6
<?php
 if($_POST['order'] === 'DESC'){
        $order = 'DESC';
    }else{
        $order = 'ASC'
    }

5.2.2 表名/字段名

應用場景:

表名與列名是不能被預編譯的,這是由于在預編譯生成語法樹的過程中,

預處理器在檢查解析后的語法樹時,會確定數據表和數據列是否存在,

此兩者必須為具體值,不能被占位符 ? 所替代

假設表名/字段名是接收的前端傳參,即存在被注入的風險

如何處理:

參考下邊order by的情況

5.2.3 order by

order by 用來指定某個字段作為排序依據,前面也解釋了字段名不能使用預編譯

假設order by后邊的字段是接收的前端傳參,即存在被注入的風險

具體的一些繞過方法可以搜索“ case when ”

如何處理:

為了避免直接拼接SQL語句,可以將列名定義為常量,

再通過白名單的方式進行拼接,能夠有效防止SQL注入

當然,這里也可以單獨對傳入的語句配合正則匹配過濾,但是效果不如這種方式簡潔有效。

前端表單:

?
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>

白名單函數:

?
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小結:

假設ASC/DESC是接收的前端傳入,即存在被注入的風險。

假設表名/字段名是接收的前端傳參,即存在被注入的風險

假設order by后邊的字段是接收的前端傳參,即存在被注入的風險

總結

到此這篇關于sql注入的一些零散知識點的文章就介紹到這了,更多相關sql注入零散知識點內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家!

原文鏈接:https://blog.csdn.net/weixin_43970718/article/details/120556294

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板: 久久精品视频2 | 国产精品一二区 | 在线播放免费播放av片 | 欧美国产综合视频 | 在线无码 | 五月天堂婷婷 | av免费在线观看国产 | 逼片| 成人情欲视频在线看免费 | 九九热在线免费观看视频 | 欧美一级黄色录像片 | 国产人成免费爽爽爽视频 | 精品一区二区三区免费毛片 | 电影av在线 | 久色伊人 | 夏目友人帐第七季第一集 | 久久久久久久亚洲视频 | 国产中文99视频在线观看 | 欧美一级黄视频 | 免费观看又色又爽又黄的崩锅 | 欧美乱淫| 国产精品自拍啪啪 | 国产一区二区三区高清 | 成人毛片网 | 国产毛片网 | 性大片1000免费看 | 黄色免费不卡视频 | 成人爱情偷拍视频在线观看 | 海外中文字幕在线观看 | 免费在线一区二区 | 免费观看一级黄色片 | 一区二区三区无码高清视频 | 国内精品国产三级国产a久久 | 中文字幕伦乱 | 亚洲精品 在线播放 | 欧美日韩在线播放 | 久久精品视频在线免费观看 | 欧美黄色一区 | 成人一级视频 | 亚洲99 | 色播视频在线播放 |