Web安全之SQL Inject

SQL Inject(SQL注入)概述

     在owasp發佈的top10排行榜裏，注入漏洞一直是危害排名第一的漏洞，其中注入漏洞裏面首當其衝的就是數據庫注入漏洞。

數據庫注入漏洞,主要是開發人員在構建代碼時, 沒有對輸入邊界進行安全考慮,致使攻擊者能夠經過合法的輸入點提交一些精心構造的語句,從而欺騙後臺數據庫對其進行執行,致使數據庫信息泄漏的一-種漏洞。
一個嚴重的SQL注入漏洞，可能會直接致使一家公司破產！
SQL注入漏洞主要造成的緣由是在數據交互中，前端的數據傳入到後臺處理時，沒有作嚴格的判斷，致使其傳入的「數據」拼接到SQL語句中後，被看成SQL語句的一部分執行。 從而致使數據庫受損（被脫褲、被刪除、甚至整個服務器權限淪陷）。

SQL inject漏洞攻擊流程

第一步：注入點探測

自動方式：經過web漏洞掃描工具，自動進行注入點發現

手動方式：手工構造sql inject測試語句進行注入點發現

第二步：信息獲取

經過注入點取指望獲得的數據

1. 環境信息：  　　數據庫類型，數據庫版本、操做系統版本、用戶信息等
2. 數據庫信息：　  數據庫名稱、數據庫表、表字段，字段內容（加密內容破解）

第三步：獲取權限

獲取操做系統權限：經過數據庫執行shell，上傳木馬

SQL inject漏洞-常見注入點類型

• 數字型     user_id=$id
• 字符型     user_id='$id'
• 搜索型     text LIKE '%{$_GET[''search]}%'

數字型注入（post）演示

打開pikachu的SQL-inject中的數字型注入 ，頁面中的查詢，在查詢相應的用戶以後會返回用戶名和用戶郵箱

 

 

點擊查詢以後能夠發現是以post方式提交的，並無在url中進行傳參，接着咱們打開burp找到剛提交的post請求發送到Repeater

 

 而後把id修改成咱們所猜測的數據庫邏輯構造出的payload  id=3 or 1=1 ，點擊GO，而後直接查看Render頁面上面返回的結果

能夠看到頁面把數據庫內全部的用戶數據都給顯示出來了，意味着id查詢處是存在數字型SQL注入漏洞

 

 經過查看後端代碼，能夠發現漏洞造成的緣由，後端從前端獲取到id賦值給$id以後沒有作任何處理就直接拼接到SQL裏，這樣就致使了$id能夠被直接控制，而且能夠經過拼接構造合法的SQL語句形成信息的泄漏。

 

字符型注入（get）演示

 

打開pikachu上SQL-inject的字符型注入，輸入用戶名，頁面會返回相應的用戶id和用戶郵箱

 

 隨意輸入一段字符，頁面會返回用戶不存在，並且參數是在url裏面提交的，是一個get請求

 

 

 

 而後咱們根據頁面的反饋來猜測後臺的執行語句來構造合法的payload，咱們輸入的一段字符，後臺的執行語句應該是一段數據庫字符查詢語句

 咱們能夠先用一個單引號閉合掉前面的單引號，而後用#符號註釋掉後面的單引號，中間是一個恆成立的條件，這樣咱們的payload就是 lucy' or 1=1# 將這段payload輸入點擊提交

 

 接着來看後端代碼，與數字型大同小異，惟一區別在於$name的單引號處理

 

搜索型注入演示

搜索型就是用的數據庫中的搜索語句來進行的查找，它會搜索全部包含你所輸入部分的結果

 

 咱們能夠根據數據庫的搜索語句 select * from member where username like '%l%'; 來構造合法的閉合 l%' or 1=1# 

接着咱們用這個payload來測試SQL注入漏洞，將payload提交後能夠看到頁面顯示出了全部的用戶信息

 

 

接着查看後臺代碼，和以前兩種類型同樣，都是沒作任何處理就直接拼接到了SQL中，惟一的區別是變量拼接時用了單引號百分號處理

 

XX型注入演示

 打開xx型注入，先輸入一個單引號提交，頁面報錯

 

查看源碼，發現XX型在參數拼接使用了一個()，咱們能夠根據這一點來構造合法的閉合

 

 咱們根據猜測構造payload xxx') or 1=1# ，將payload輸入提交，能夠看到用戶信息都被遍歷出來了