目錄
- SQL注入
- 一些尋找SQL漏洞的方法
- 防御SQL注入
- SQL注入相關的優秀博客
- XML注入
- 什么是XML注入
- 預防XML注入
- JSON注入
- 什么是JSON注入
- JSON注入的防御
- CRLF注入
- CRLF介紹
- CRLF漏洞檢測
- CRLF漏洞預防
SQL注入
所謂SQL注入，是將惡意SQL命令通過某種方式提交到服務器后臺，并欺騙服務器執行這些惡意的SQL命令的一種攻擊方式， —— [ 百度百科 ]
造成SQL注入漏洞原因有兩個：一個是沒有對輸入的資料進行過濾(過濾輸入)，還有一個是沒有對發送到資料庫的資料進行轉義(轉義輸出)，
一些尋找SQL漏洞的方法
http://host/test.php?id=100 and 1=1 //回傳成功
http://host/test.php?id=100 and 1=2 //回傳失敗
http://host/test.php?name=rainman ‘ and ‘1’=‘1 //回傳成功
http://host/test.php?name=rainman ‘ and ‘1’=‘2 //回傳失敗
http://host/test.php?name=rainman ‘ and ‘1’=‘2 )) //使用括號進行陳述句閉合
//在具有模糊搜索的地方
1)先搜索(')，如果出錯，說明90%存在這個漏洞，
2)然后搜索(%)，如果正常回傳，說明95%有洞了，
3)然后再搜索一個關鍵字，比如(2006)吧，正常回傳所有2006相關的資訊，
4)再搜索(2006%'and 1=1 and '%'=')和(2006%'and 1=2 and '%'=')，
//看看能否繞過驗證
(1) 用戶名輸入： ‘or 1=1 or’ 密碼：任意
(2) Admin’ -- (或’or 1=1 or’ --)(admin or 1=1 --) (MSSQL)(直接輸入用戶名，不進行密碼驗證)
(3) 用戶名輸入：admin 密碼輸入：’ or ‘1’=‘1 也可以
(4) 用戶名輸入：admin' or 'a'='a 密碼輸入：任意
(5) 用戶名輸入：’ or 1=1 --
(6) 用戶名輸入：admin’ or 1=1 -- 密碼輸入：任意
(7) 用戶名輸入：1'or'1'='1'or'1'='1 密碼輸入：任意
//不同的SQL服務器連結字串的語法不同，比如MS SQL Server使用符號+來連結字串，而Oracle使用符號||來連結
http://host/test.jsp?ProdName=Book’ //回傳錯誤
http://host/test.jsp?ProdName=B’+’ook //回傳正常
http://host/test.jsp?ProdName=B’||’ook //回傳正常說明有SQL注入
如果應用程式已經過濾了’和+等特殊字符，我們仍然可以在輸入時過把字符轉換成URL編碼(即字符ASCII碼的16進制)來繞過檢查，
防御SQL注入
- 對輸入進行過濾；
- 使用預編譯的SQL陳述句，比如Java中的PreparedStatement；
- 使用存盤程序（不是所有場景都使用，這個方法不是很推薦）；
- MyBatis的SQL注入防護—模糊查詢
-- MySQL
select * from table where name like concat('%',#{name},'%')
-- Oracle
select * from table where name like '%' || #{name} || '%'
-- SQL Server
select * from table where name like '%'+#{name}+'%'
-- DB2
select * from table where name like concat('%',#{name},'%')
SQL注入相關的優秀博客
- https://blog.csdn.net/wutianxu123/article/details/82718718
- https://blog.csdn.net/wutianxu123/article/details/82719212
XML注入
什么是XML注入
XML的設計宗旨是傳輸資料，而非顯示資料，XML注入是一種古老的技術，通過利用閉合標簽改寫XML檔案實作的，
下面舉個最簡單的例子
<?xml version="1.0" encoding="utf-8"?>
<USER>
<user Account="admin">用戶輸入</user>
<user Account="root">root</user>
</USER>
若攻擊者剛好能掌控用戶輸入欄位，輸入 admin
<?xml version="1.0" encoding="utf-8" ?>
<USER>
<user Account="admin">admin</user>
<user Account="hacker">hacker</user>
<user Account="root">root</user>
</USER>
這樣我們可以通過XML注入添加一個管理員賬戶，
預防XML注入
- 對有改變XML結構的特殊輸入進行過濾或者編碼；
- 對["&","<",">","'".'"',"/"]這些特殊字符過濾，
JSON注入
什么是JSON注入
我們知道JSON是根據引號（"）、冒號(??、逗號（,）和花括號（{}）區分各字符的意義的，如果有惡意用戶向JSON中注入惡意字符，那么JSON將決議失敗，例如，輸入的PassWord值為：admin"888
那么組裝成的JSON資料位如下：
"PassWord":" admin"888"
在PassWord中的引號將會破壞整個JSON的結構，導致JSON決議失敗，JSON注入沒有其他幾種注入的危害性大，但依然不可小視，筆者一直認為沒有低危的漏洞，只是還沒碰到可利用的場景，攻擊者可能通過這類低危漏洞輔助其他攻擊，這時低危漏洞將不再低危，
JSON注入的防御
如何防御JSON注射呢？方法依然很簡單，只需要對其關鍵字符進行轉義即可，如：將"admin"888"轉換為"admin"888"，這樣JSON的值就可以決議了，如果字串中出現""，同樣需要將其轉義"\"，
CRLF注入
我們知道：一個HTTP請求報文由四個部分組成：請求行、請求頭部、空行、請求資料，請求報文格式就如下圖所示：
參考博客
我們可以發現請求行和請求頭的尾部都有CRLF標志，請求頭和請求體之間也是通過CRLF標志分割的，CRLF注入漏洞就是利用Http的這種報文結構，向請求行或請求頭的欄位注入惡意的CRLF，就能注入一些首部欄位或報文主體（請求回應資料），并在回應中輸出，所以CRLF又稱為HTTP回應拆分漏洞（HTTP Response Splitting），
CRLF介紹
CRLF指的是回車符(CR，ASCII 13，\r，%0d) 和換行符(LF，ASCII 10，\n，%0a)，CRLF的概念最早源自打字機，表明行的結束，計算機出現后沿用了這個概念，
回車符（\r)的作用是將游標移到行首，換行符（\n）的作用是將游標垂直移到下行，鍵盤上的回車鍵(Enter)就可以執行該操作，但是不同的作業系統，行的結束符是不一樣的，Windows系統使用CRLF表示行的結束，Linux/Unix系統使用LF表示行的結束，MacOS系統早期使用CR表示，但是現在好像也用LF表示行的結束，所以同一檔案在不同作業系統中打開，內容格式可能會出現差異，這是行結束符不一致導致的，
在HTTP規范中，行使用CRLF來結束，首部與主體由兩個CRLF分隔，瀏覽器根據這兩個CRLF來獲取HTTP內容并顯示，
CRLF漏洞檢測
CRLF注入漏洞的本質和XSS有點相似，攻擊者將惡意資料發送給易受攻擊的Web應用程式，Web應用程式將惡意資料輸出在HTTP回應頭中（XSS一般輸出在主體中），所以CRLF注入漏洞的檢測也和XSS漏洞的檢測差不多，通過修改HTTP引數或URL，注入惡意的CRLF，查看構造的惡意資料是否在回應頭中輸出，
總結下：
如果你找到了一個你傳給Web程式的引數最后會在回應的Http頭部回顯，那么這個地方可能就是一個存在CRLF注入漏洞的地方，
CRLF漏洞預防
- 過濾引數中的\r\n之類的行結束符；
- 輸入引數盡量不要在相應頭部回顯，如果非要回顯的話一定要對該欄位的輸入值進行嚴格的過濾，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/59940.html
標籤：其他