① 常見的sql注入類型分為哪幾種
根據輸入的參數，可將SQL注入方式大致分為兩類：數字型注入、字元型注入。
數字型注入：當輸入的參數為整型時，如ID、年齡、頁碼等，如果存在注入漏洞，則可以認為是數字型注入。這種數字型注入最多出現在ASP、PHP等弱類型語言中，弱類型語言會自動推導變數類型。而對於Java、C#這類強類型語言，如果試圖把一個字元串轉換為int類型，則會拋出異常，無法繼續執行。所以，強類型的語言很少存在數字型注入漏洞。
字元型注入：當輸入參數為字元串時，稱為字元型。數字型與字元型注入最大的區別在於：數字型不需要單引號閉合，而字元串類型一般要使用單引號來閉合。
② java正則表達式怎麼防止代碼漏洞
javaWeb安全漏洞及處理方式
關注
轉載自：https://blog.csdn.net/lujiancs/article/details/78175007
1、SQL注入攻擊
SQL注入攻擊就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將(惡意)的SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入(惡意)SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設差舉計者意圖去執行SQL語句。
隨著B/S框架結構在系統開發中的廣泛應用，惡意攻擊者利用SQL命令在Web表單中輸入合法的字元或查詢字元串來欺騙伺服器執行SQL命令。當注入攻擊得逞後，Web程序將泄露大量用戶隱私數據和資料庫中數據結構。攻擊者能夠獲得系統較高的訪問許可權，進行破壞操作。
SQL注入可以分為平台層注入和代碼層注入。前者由不安全的資料庫配置或資料庫平台的漏洞所致;後者主要是由於程序員對輸入未進行細致地過濾，從而執行了非法的數據查詢。基於此，SQL注入的產生原因通常表現在以下幾方面:
1）不當的類型處理;
2）不安全的資料庫配置;
3）不合理的查詢集處理;
4）不當的錯誤處理;
5）轉義字元處理不合適;
6) 多個提交處理不當。
解決方法:
資料庫安全通信包括SQL注入攻擊的防範、安全設置、異常信息處理三個方面。
1.服務端Filter對訪問者輸入的字元進行過濾檢驗，但是攻擊者經常把危險字元潛藏在用戶輸入的有效字元中完 成過濾檢驗。
2.通過正則表達式對頁面的文本框輸入的數據進行限制可以減少過濾檢驗存在的漏洞。
3.使用prepareStatment預編譯sql語句
2、XSS跨站腳本攻擊
跨站腳本（Cross-site scripting，簡稱XSS），是一種迫使Web站點回顯可執行代碼的攻擊技術，而這些可執行代碼由攻擊者提供、最終為用戶瀏覽器載入。不同於大多數攻擊（一般只涉及攻擊者和受害者），XSS涉及到三方，即攻擊者、客戶端與網站。XSS的攻擊目標是為了盜取客戶端的cookie或者其他網站用於識別客戶端身份的敏感信息。獲取到合法用戶的信息後，攻擊者甚至可以假冒最終用戶與網站進行交互。
XSS 屬於被動式的攻擊。攻擊者先構造一個跨站頁面，利用SCRIPT、<IMG>、<IFRAME>等各種方式使得用戶瀏覽這個頁面時，觸發對被攻擊站點的HTTP 請求。此時，如果被攻擊者如果已經在被攻擊站點登錄，就會持有該站點cookie。這樣該站點會認為被攻擊者發起了一個HTTP請求。而實際上這個請求是在被攻擊者不知情情況下發起的，由此攻擊者在一定程度上達到了冒充被攻擊者的目的。精心的構造這個攻擊請求，可以達到冒充發文，奪取許可權等多個攻擊目的。在常見的攻擊實例中，這個請求是通過script 來發起的，因此被稱為Cross Site Script。
XSS漏洞成因是由於動態網頁的Web應用對用戶提交請求參數未做充分的檢查過濾，允許用戶在提交的數據中摻入HTML代碼（最主要的塌胡是「>」、「<」），然後未加編碼地輸出到第三方用戶的瀏覽器，這些攻擊者惡意提交代碼會被受害用戶的瀏覽器解釋執行。
分為三種類型：
1）反射型（數據流向：瀏覽器 ->後端 -> 瀏覽器）
反射型XSS腳本攻擊即如我們上面所提到的XSS跨站腳本攻擊方式，該類型只是簡單地將用戶輸入的數據直接或未經過完善的安全過濾就在瀏覽器中進行輸出，導致輸出的數據中存在可被瀏覽器執行的代碼數據。由於此種類型的跨站代碼存在於URL中，所以黑客通常需要通過誘騙或加密變形等方式，將存在惡意代碼的鏈接發給用戶，只有用戶點擊以後才能使得攻擊成功實施。
2）存儲型（數據流向是：瀏覽器 ->後端 -> 資料庫 -> 後端-> 瀏覽器）
存儲型XSS腳本攻擊是指Web應用程序會將用戶輸入的數據信息保存在服務端的資料庫或其他文件形式中，網頁進行數據查詢展示時，會從資料庫中獲取數據內容，並將數據內容在網頁中進行輸出展示，因此存儲型XSS具有較強的穩定性。
存儲型XSS腳本攻擊最為常見的場景就是在博客或新聞發布系統中，黑客將包含有惡意代碼的數據信息直虛衫碧接寫入文章或文章評論中，所有瀏覽文章或評論的用戶，都會在他們客戶端瀏覽器環境中執行插入的惡意代碼。
3）基於DOM（數據流向是：URL-->瀏覽器 ）
基於DOM的XSS跨站腳本攻擊是通過修改頁面DOM節點數據信息而形成的XSS跨站腳本攻擊。不同於反射型XSS和存儲型XSS，基於DOM的XSS跨站腳本攻擊往往需要針對具體的javascript DOM代碼進行分析，並根據實際情況進行XSS跨站腳本攻擊的利用。
解決方法：
1).輸入過濾。對用戶的所有輸入數據進行檢測，比如過濾其中的「<」、「>」、「/」等可能導致腳本注入的特殊字元，或者過濾「script」、「javascript」等腳本關鍵字，或者對輸入數據的長度進行限制等等。同時，我們也要考慮用戶可能繞開ASCII碼，使用十六進制編碼來輸入腳本。因此，對用戶輸入的十六進制編碼，我們也要進行相應的過濾。只要能夠嚴格檢測每一處交互點，保證對所有用戶可能的輸入都進行檢測和XSS過濾，就能夠有效地阻止XSS攻擊。
2).輸出編碼。通過前面對XSS攻擊的分析，我們可以看到，之所以會產生XSS攻擊，就是因為Web應用程序將用戶的輸入直接嵌入到某個頁面當中，作為該頁面的HTML代碼的一部分。因此，當Web應用程序將用戶的輸入數據輸出到目標頁面中時，只要用HtmlEncoder等工具先對這些數據進行編碼，然後再輸出到目標頁面中。這樣，如果用戶輸入一些HTML的腳本，也會被當成普通的文字，而不會成為目標頁面HTML代碼的一部分得到執行.
3、CSRF跨站請求偽造漏洞防護
CSRF是CrossSite Request Forgery的縮寫，乍一看和XSS差不多的樣子，但是其原理正好相反，XSS是利用合法用戶獲取其信息，而CSRF是偽造成合法用戶發起請求。
字面理解意思就是在別的站點偽造了一個請求。專業術語來說就是在受害者訪問一個網站時，其 Cookie 還沒有過期的情況下，攻擊者偽造一個鏈接地址發送受害者並欺騙讓其點擊，從而形成 CSRF 攻擊。
根據HTTP協議，在HTTP頭中有一個欄位叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。
解決方案：
配置FILTER攔截用戶所有請求(POST/GET)，對用戶請求Referer頭URL進行合法性校驗。
4、URL鏈接注入漏洞防護
鏈接注入是修改站點內容的行為，其方式為將外部站點的 URL 嵌入其中，或將有易受攻擊的站點中的腳本 的 URL 嵌入其中。將URL 嵌入易受攻擊的站點中，攻擊者便能夠以它為平台來啟動對其他站點的攻擊，以及攻擊這個易受攻擊的站點本身。
解決方案：
1，二次驗證，進行重要敏感操作時，要求用戶進行二次驗證。
2，驗證碼，進行重要敏感操作時，加入驗證碼。
3，驗證 HTTP 的 Referer 欄位。
4，請求地址中添加 Token 並驗證。
5，HTTP 頭中自定義屬性並驗證。
5、會話COOKIE中缺少HttpOnly防護
會話cookie中缺少HttpOnly屬性會導致攻擊者可以通過程序(JS腳本、Applet等)獲取到用戶的cookie信息，造成用戶cookie信息泄露，增加攻擊者的跨站腳本攻擊威脅。
HttpOnly是微軟對cookie做的擴展，該值指定cookie是否可通過客戶端腳本訪問。Microsoft Internet Explorer 版本 6 Service Pack 1 和更高版本支持cookie屬性HttpOnly。
如果在Cookie中沒有設置HttpOnly屬性為true，可能導致Cookie被竊取。竊取的Cookie可以包含標識站點用戶的敏感信息。
如果在Cookie中設置HttpOnly屬性為true，兼容瀏覽器接收到HttpOnly cookie，那麼客戶端通過程序(JS腳本、Applet等)將無法讀取到Cookie信息，這將有助於緩解跨站點腳本威脅。
解決方案：
配置filter攔截器，將伺服器端返回請求，向所有會話cookie中添加「HttpOnly」屬性。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.setHeader("SET-COOKIE","JSESSIONID=" + sessionid + "; HttpOnly");
6、點擊劫持漏洞(Clickjacking)防護
點擊劫持是一種視覺上的欺騙手段，攻擊者使用一個透明的、不可見的iframe，覆蓋在一個網頁上，然後誘使用戶在該網頁上進行操作，此時用戶在不知情的情況下點擊了透明的iframe頁面。通過調整iframe頁面的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上。
解決方案：
配置FILTER攔截器，在伺服器端返回請求中，使用一個HTTP頭「X-Frame-Options」值為SAMEORIGIN-同源策略 ，則frame頁面的地址只能為同源域名下面的頁面，防止點擊劫持漏洞發生。
示例代碼：
HttpServletResponseresponse=(HttpServletResponse)paramServletResponse;
response.addHeader("x-frame-options","SAMEORIGIN");
7、HTTP host 頭攻擊漏洞
使用HTTP代理工具，可以篡改HTTP報文頭部中HOST欄位時，該值可被注入惡意代碼。因為需要控制客戶端的輸入，故該漏洞較難利用。
解決方案：
配置FILTER攔截器，對請求輸入HOST頭信息進行信息安全性校驗，防止HOST頭信息被惡意篡改利用。
示例代碼：
HttpServletRequest request =(HttpServletRequest)servletRequest;
//主機ip和埠 或 域名和埠
String myhosts = request.getHeader("host");
if(!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts, "xx.xx.xxx.xxx:xxxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx:xxxx")StringUtils.equals(myhosts,"xx.xx.xxx.xxx")
!StringUtils.equals(myhosts,"xx.xx.xxx.xxx") !StringUtils.equals(myhosts,"xx.xx.xxx.xxx" ){
logger.error("======訪問host非法，已攔截======");
response.sendRedirect(request.getContextPath() + "/login.jsp");
return;
}
8、越權訪問漏洞防護
越權訪問（Broken Access Control，簡稱BAC）是Web應用程序中一種常見的漏洞，分為垂直越權訪問和水平越權訪問。垂直越權是指不同用戶級別之間的越權，如普通用戶執行管理員用戶的許可權。水平越權是指相同級別用戶之間的越權操作。
Web應用程序如果存在越權訪問漏洞，可能導致以下危害：
1）導致任意用戶敏感信息泄露；
2）導致任意用戶信息被惡意修改或刪除。
解決方案：
配置FILTER攔截器，對請求所有URL進行攔截，對於需要進行授權的URL進行許可權校驗，防止用戶越權訪問系統資源。
9.弱口令漏洞
解決方案：最好使用至少6位的數字、字母及特殊字元組合作為密碼。資料庫不要存儲明文密碼，應存儲MD5加密後的密文，由於目前普通的MD5加密已經可以被破解，最好可以多重MD5加密，或者多種加密方式疊加組合。
10．JSP頁面拋出的異常可能暴露程序信息。
有經驗的入侵者，可以從JSP程序的異常中獲取很多信息，比如程序的部分架構、程序的物理路徑、SQL注入爆出來的信息等。
解決方案：自定義一個Exception，將異常信息包裝起來不要拋到頁面上。
11.本地緩存漏洞
合法用戶「注銷」後，在未關閉瀏覽器的情況下，點擊瀏覽器「後退」按鈕，可從本地頁面緩存中讀取數據，繞過了服務端filter過濾。
解決方案：配置filter對存放敏感信息的頁面限制頁面緩存。如：
httpResponse.setHeader("Cache-Control","no-cache");
httpResponse.setHeader("Cache-Control","no-store");
httpResponse.setDateHeader("Expires",0);
httpResponse.setHeader("Pragma","no-cache");
12.文件上傳漏洞。
前台僅使用JS對文件後綴做了過濾，這只能針對普通的用戶，而惡意攻擊者完全可以修改表單去掉JS校驗。
13.Java WEB容器默認配置漏洞。
如TOMCAT後台管理漏洞，默認用戶名及密碼登錄後可直接上傳war文件獲取webshell。
解決方案：最好刪除，如需要使用它來管理維護，可更改其默認路徑，口令及密碼。
③ SQL注入步驟和常用函數以及中文處理方法
第一節 SQL注入的一般步驟 首先 判斷環境 尋找注入點 判斷資料庫類型 這在入門篇已經講過了 其次 根據注入參數類型 在腦海中重構SQL語句的原貌 按參數類型主要分為下面三種 (A)ID= 這類注入的參數是數字型 SQL語句原貌大致如下 Select * from 表名 where 欄位= 注入的參數為ID= And [查詢條件] 即是生成語句 Select * from 表名 where 欄位= And [查詢條件](B) Class=連續劇 這類注入的參數是字元型 SQL語句原貌大致概如下 Select * from 表名 where 欄位= 連續劇 注入的參數為Class=連續劇 and [查詢條件] and = 即是生成語句 Select * from 表名 where 欄位= 連續劇 and [查詢條件] and = (C) 搜索時沒過濾參數的 如keyword=關鍵字 SQL語句原貌大致如下 Select * from 表名 where 欄位like %關鍵字% 注入的參數為keyword= and [查詢條件] and % = 即是生成語句 Select * from 表名 where欄位like % and [查詢條件] and % = % 接著 將查詢條件替換成SQL語句 猜解表名 例如 ID= And (Select Count(*) from Admin)>= 如果頁面就與ID= 的相同 說明附加條件成立 即表Admin存在 反之 即不存在（請牢記這種方法） 如此循環 直至猜到表名為止 表名猜出來後 將Count(*)替換成Count(欄位名) 用同樣的原理猜解欄位名 有人會說 這里有一些偶然的成分 如果表名起得很復雜沒規律的 那根本就沒得玩下去了 說得很對 這世界根本就不存在 %成功的黑客技術 蒼蠅不叮無縫的蛋 無論多技術多高深的黑客 都是因為別人的程序寫得不嚴密或使用者保密意識不夠 才有得下手 有點跑題了 話說回來 對於SQLServer的庫 還是有辦法讓程序告訴我們表名及欄位名的 我們在高級篇中會做介紹 最後 在表名和列名猜解成功後 再使用SQL語句 得出欄位的值 下面介紹一種最常用的方法－Ascii逐字解碼法 雖然這種方法速度很慢 但肯定是可行的方法 我們舉個例子 已知表Admin中存在username欄位 首先 我們取第一條記錄 測試長度 ?id= and (select top len(username) from Admin)> 先說明原理 如果top 的username長度大於 則條件成立 接著就是> > > 這樣測試下去 一直到條件不成立為止 比如> 成立 > 不成立 就是len(username)= 當然沒人會笨得從 一個個測試 怎麼樣才比較快就看各自發揮了 在得到username的長度後 用mid(username N )截取第N位字元 再asc(mid(username N ))得到ASCII碼 比如 id= and (select top asc(mid(username )) from Admin)> 同樣也是用逐步縮小范圍的方法得到第 位字元的ASCII碼 注意的是英文和數字的ASCII碼在 之間 可以用折半法加速猜解 如果寫成程序測試 效率會有極大的提高 第二節 SQL注入常用函數 有SQL語言基礎的人 在SQL注入的時候成功率比不熟悉的人高很多 我們有必要提高一下自己的SQL水平 特別是一些常用的函數及命令 Access asc(字元)SQLServer unicode(字元)作用 返回某字元的ASCII碼Access chr(數字)SQLServer nchar(數字)作用 與asc相反 根據ASCII碼返回字元Access mid(字元串 N L)SQLServer substring(字元串 N L)作用 返回字元串從N個字元起長度為L的子字元串 即N到N+L之間的字元串Access abc(數字)SQLServer abc (數字)作用 返回數字的絕對值（在猜解漢字的時候會用到）Access A beeen B And CSQLServer A beeen B And C作用 判斷A是否界於B與C之間 第三節 中文處理方法 在注入中碰到中文字元是常有的事 有些人一碰到中文字元就想打退堂鼓了 其實只要對中文的編碼有所了解 中文恐懼症 很快可以克服 先說一點常識 Access中 中文的ASCII碼可能會出現負數 取出該負數後用abs()取絕對值 漢字字元不變 SQLServer中 中文的ASCII為正數 但由於是UNICODE的雙位編碼 不能用函數ascii()取得ASCII碼 必須用函數unicode ()返回unicode值 再用nchar函數取得對應的中文字元 了解了上面的兩點後 是不是覺得中文猜解其實也跟英文差不多呢？除了使用的函數要注意 猜解范圍大一點外 方法是沒什麼兩樣的 lishixin/Article/program/SQLServer/201311/22039
④ 什麼是SQL注入，如何防止SQL注入
所謂SQL注入，就是通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。具體來說，它是利用現有應用程序，將（惡意）的SQL命令注入到後台資料庫引擎執行的能力，它可以通過在Web表單中輸入（惡意）SQL語句得到一個存在安全漏洞的網站上的資料庫，而不是按照設計者意圖去執行SQL語句。比如先前的很多影視網站泄露VIP會員密碼大多就是通過WEB表單遞交查詢字元暴出的，這類表單特別容易受到SQL注入式攻擊．
防護
歸納一下，主要有以下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和
雙"-"進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員許可權的資料庫連接，為每個應用使用單獨的許可權有限的資料庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出盡可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般採取輔助軟體或網站平台來檢測，軟體一般採用sql注入檢測工具jsky，網站平台就有億思網站安全平台檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS可以有效的防禦SQL注入，XSS攻擊等。
⑤ sql注入發生在計算機網路的哪一層
應用層，每一層，這都有一定道理。
但其實SQL注入岩跡發生在伺服器的業務邏輯粗宴並層，和計算機網路就沒祥簡有關系啊，你還需要學習一個。
你JS防，網路層防什麼用沒有，你只能在業務邏輯層防。
⑥ 什麼是sql注入
SQL是操作資料庫數據的結構化查詢語言，網頁的應用數據和後台資料庫中的數據進行交互時會採用SQL。而SQL注入是將Web頁面的原URL、表單域或數據包輸入的參數，修改拼接成SQL語句，傳遞給Web伺服器，進而傳給資料庫伺服器以執行資料庫命令。如Web應用程序的開發人員對用戶所輸入的數據或cookie等內容不進行過濾或驗證(即存在注入點)就直接傳輸給資料庫，就可能導致拼接的SQL被執行，獲取對資料庫的信息以及提權，發生SQL注入攻擊。
⑦ 什麼是SQL注入
SQL注入：利用現有應用程序，將(惡意)的SQL命令注入到後台資料庫引擎執行的能力，這是SQL注入的標准釋義。
隨著B/S模式被廣泛的應用，用這種模式編寫應用程序的程序員也越來越多，但由於開發人員的水平和經驗參差不齊，相當一部分的開發人員在編寫代碼的時候，沒有對用戶的輸入數據或者是頁面中所攜帶的信息（如Cookie）進行必要的合法性判斷，導致了攻擊者可以提交一段資料庫查詢代碼，根據程序返回的結果，獲得一些他想得到的數據。
SQL注入利用的是正常的HTTP服務埠，表面上看來和正常的web訪問沒有區別，隱蔽性極強，不易被發現。
SQL注入攻擊過程分為五個步驟：
第一步：判斷Web環境是否可以SQL注入。如果URL僅是對網頁的訪問，不存在SQL注入問題，如：http://www.../162414739931.shtml就是普通的網頁訪問。只有對資料庫進行動態查詢的業務才可能存在SQL注入，如：http://www...../webhp?id＝39，其中?id＝39表示資料庫查詢變數，這種語句會在資料庫中執行，因此可能會給資料庫帶來威脅。
第二步：尋找SQL注入點。完成上一步的片斷後，就要尋找可利用的注入漏洞，通過輸入一些特殊語句，可以根據瀏覽器返回信息，判斷資料庫類型，從而構建資料庫查詢語句找到注入點。
第三步：猜解用戶名和密碼。資料庫中存放的表名、欄位名都是有規律可言的。通過構建特殊資料庫語句在資料庫中依次查找表名、欄位名、用戶名和密碼的長度，以及內容。這個猜測過程可以通過網上大量注入工具快速實現，並藉助破解網站輕易破譯用戶密碼。
第四步：尋找WEB管理後台入口。通常WEB後台管理的界面不面向普通用戶
開放，要尋找到後台的登陸路徑，可以利用掃描工具快速搜索到可能的登陸地址，依次進行嘗試，就可以試出管理台的入口地址。
第五步：入侵和破壞。成功登陸後台管理後，接下來就可以任意進行破壞行為，如篡改網頁、上傳木馬、修改、泄漏用戶信息等，並進一步入侵資料庫伺服器。
SQL注入攻擊的特點:
變種極多，有經驗的攻擊者會手動調整攻擊參數，致使攻擊數據的變種是不可枚舉的，這導致傳統的特徵匹配檢測方法僅能識別相當少的攻擊，難以防範。
攻擊過程簡單，目前互聯網上流行眾多的SQL注入攻擊工具，攻擊者藉助這些工具可很快對目標WEB系統實施攻擊和破壞。
危害大，由於WEB編程語言自身的缺陷以及具有安全編程能力的開發人員少之又少，大多數WEB業務系統均具有被SQL注入攻擊的可能。而攻擊者一旦攻擊成功，可以對控制整個WEB業務系統，對數據做任意的修改，破壞力達到及至。
SQL注入的危害和現狀
SQL注入的主要危害包括：
未經授權狀況下操作資料庫中的數據
惡意篡改網頁內容
私自添加系統帳號或者是資料庫使用者帳號
網頁掛木馬
如何防止SQL參數：
1，檢查上傳的數據，並過濾
2. 禁止拼接SQL字元串
3.使用SQL參數化處理
4．載入防入侵等硬體設施
⑧ 部分sql注入總結
本人ctf選手一名，在最近做練習時遇到了一些sql注入的題目，但是sql注入一直是我的弱項之一，所以寫一篇總結記錄一下最近學到的一些sql注入漏洞的利用。
在可以聯合查詢的題目中，一般會將資料庫查詢的數據回顯到首頁面中，這是聯合注入的前提。
適用於有回顯同時資料庫軟體版本是5.0以上的MYSQL資料庫,因為MYSQL會有一個系統資料庫information_schema， information_schema 用於存儲資料庫元數據(關於數據的數據)，例如資料庫名、表名、列的數據類型、訪問許可權等
聯合注入的過程：
判斷注入點可以用and 1=1/and 1=2用於判斷注入點
當注入類型為數字型時返回頁面會不同,但都能正常執行。
sql注入通常為數字型注入和字元型注入：
1、數字型注入
數字型語句：
在這種情況下直接使用and 1=1/and 1=2是都可以正常執行的但是返回的界面是不一樣的
2、字元型注入
字元型語句：
字元型語句輸入我們的輸入會被一對單引號或這雙引號閉合起來。
所以如果我們同樣輸入and 1=1/and 1=2會發現回顯畫面是並無不同的。
在我們傳入and 1=1/and 1=2時語句變為
傳入的東西變成了字元串並不會被當做命令。
所以字元型的測試方法最簡單的就是加上單引號 ' ，出現報錯。
加上注釋符--後正常回顯界面。
這里還有的點就是sql語句的閉合也是有時候不同的，下面是一些常見的
這一步可以用到order by函數，order by 函數是對MySQL中查詢結果按照指定欄位名進行排序，除了指定字 段名還可以指定欄位的欄位進行排序，第一個查詢欄位為1，第二個為2，依次類推，所以可以利用order by就可以判斷列數。
以字元型注入為例：
在列數存在時會正常回顯
但是列數不存在時就會報錯
這步就說明了為什麼是聯合注入了，用到了UNION，UNION的作用是將兩個select查詢結果合並
但是程序在展示數據的時候通常只會取結果集的第一行數據，這就讓聯合注入有了利用的點。
當我們查詢的第一行是不存在的時候就會回顯第二行給我們。
講查詢的數據置為-1，那第一行的數據為空，第二行自然就變為了第一行
在這個基礎上進行注入
可以發現2，3都為可以利用的顯示點。
和前面一樣利用union select，加上group_concat()一次性顯示。
現在非常多的Web程序沒有正常的錯誤回顯，這樣就需要我們利用報錯注入的方式來進行SQL注入了
報錯注入的利用步驟和聯合注入一致，只是利用函數不同。
以updatexml為例。
UpdateXML(xml_target, xpath_expr, new_xml)
xml_target： 需要操作的xml片段
xpath_expr： 需要更新的xml路徑(Xpath格式)
new_xml： 更新後的內容
此函數用來更新選定XML片段的內容，將XML標記的給定片段的單個部分替換為 xml_target 新的XML片段 new_xml ，然後返回更改的XML。xml_target替換的部分 與xpath_expr 用戶提供的XPath表達式匹配。
這個函數當xpath路徑錯誤時就會報錯，而且會將路徑內容返回，這就能在報錯內容中看到我們想要的內容。
而且以~開頭的內容不是xml格式的語法，那就可以用concat函數拼接~使其報錯，當然只要是不符合格式的都可以使其報錯。
[極客大挑戰 2019]HardSQL
登錄界面嘗試注入，測試後發現是單引號字元型注入，且對union和空格進行了過濾，不能用到聯合注入，但是有錯誤信息回顯，說明可以使用報錯注入。
利用updatexml函數的報錯原理進行注入在路徑處利用concat函數拼接~和我們的注入語句
發現xpath錯誤並執行sql語句將錯誤返回。
在進行爆表這一步發現了等號也被過濾，但是可以用到like代替等號。
爆欄位
爆數據
這里就出現了問題flag是不完整的，因為updatexml能查詢字元串的最大長度為32，所以這里要用到left函數和right函數進行讀取
報錯注入有很多函數可以用不止updatexml一種，以下三種也是常用函數：
堆疊注入就是多條語句一同執行。
原理就是mysql_multi_query() 支持多條sql語句同時執行，用;分隔，成堆的執行sql語句。
比如
在許可權足夠的情況下甚至可以對資料庫進行增刪改查。但是堆疊注入的限制是很大的。但是與union聯合執行不同的是它可以同時執行無數條語句而且是任何sql語句。而union執行的語句是有限的。
[強網杯 2019]隨便注
判斷完注入類型後嘗試聯合注入，發現select被過濾，且正則不區分大小寫過濾。
那麼就用堆疊注入，使用show就可以不用select了。
接下去獲取表信息和欄位信息
那一串數字十分可疑大概率flag就在裡面，查看一下
這里的表名要加上反單引號，是資料庫的引用符。
發現flag，但是沒辦法直接讀取。再讀取words，發現裡面有個id欄位，猜測資料庫語句為
結合1'or 1=1#可以讀取全部數據可以利用改名的方法把修改1919810931114514為words，flag修改為id，就可以把flag讀取了。
最終payload：
盲注需要掌握的幾個函數
在網頁屏蔽了錯誤信息時就只能通過網頁返回True或者False判斷，本質上是一種暴力破解，這就是布爾盲注的利用點。
首先，判斷注入點和注入類型是一樣的。
但是盲注沒有判斷列數這一步和判斷顯示位這兩步，這是和可回顯注入的不同。
判斷完注入類型後就要判斷資料庫的長度，這里就用到了length函數。
以[WUSTCTF2020]顏值成績查詢為例
輸入參數後，發現url處有個get傳入的stunum
然後用到length函數測試是否有注入點。
發現頁面有明顯變化
將傳入變為
頁面回顯此學生不存在
那麼就可以得出資料庫名長度為3
測試發現過濾了空格
然後就是要查資料庫名了，這里有兩種方法
一、只用substr函數，直接對比
這種方法在寫腳本時可以用於直接遍歷。
二、加上ascii函數
這個payload在寫腳本時直接遍歷同樣可以，也可用於二分法查找，二分法速度更快。
接下來的步驟就和聯合注入一樣，只不過使用substr函數一個一個截取字元逐個判斷。但是這種盲注手工一個一個注十分麻煩所以要用到腳本。
直接遍歷腳本
二分法腳本
時間盲注用於代碼存在sql注入漏洞，然而頁面既不會回顯數據，也不會回顯錯誤信息
語句執行後也不提示真假，我們不能通過頁面的內容來判斷
所以有布爾盲注就必有時間盲注，但有時間盲注不一定有布爾盲注
時間盲注主要是利用sleep函數讓網頁的響應時間不同從而實現注入。
sql-lab-less8：
無論輸入什麼都只會回顯一個you are in...，這就是時間盲注的特點。
當正常輸入?id=1時時間為11毫秒
判斷為單引號字元型注入後，插入sleep語句
明顯發現響應時間為3053毫秒。
利用時間的不同就可以利用腳本跑出資料庫，後續步驟和布爾盲注一致。
爆庫
爆表
爆欄位
腳本
在進行SQL注入時,發現union,and,or被完全過濾掉了,就可以考慮使用異或注入
什麼是異或呢
異或是一種邏輯運算，運演算法則簡言之就是：兩個條件相同（同真或同假）即為假（0），兩個條件不同即為真（1），null與任何條件做異或運算都為null，如果從數學的角度理解就是，空集與任何集合的交集都為空
即 1^1=0,0^0=0,1^0=1
利用這個原理可以在union，and，or都被過濾的情況下實現注入
[極客大挑戰 2019]FinalSQL
給了五個選項但是都沒什麼用，在點擊後都會在url處出現?id。
而且union，and，or都被過濾
測試發現?id=1^1會報錯
但是?id=1^0會返回?id=1的頁面，這就是前面說的原理，當1^0時是等於1的所以返回?id=1的頁面。
根據原理寫出payload，進而寫出腳本。
爆庫
爆表
爆欄位
據此可以寫出基於異或的布爾盲注腳本
實驗推薦：課程:SQL注入初級(合天網安實驗室)