利用SQL注入漏洞登陸後臺

時間  2019-11-13
標籤 利用 sql 注入 漏洞 登陸 後臺 欄目 SQL 简体版
原文   原文鏈接

　　

所謂SQL注入，就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令，好比先前的不少影視網站泄露VIP會員密碼大多就是經過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊．php

sql注入html

何時最易受到sql注入攻擊

　 　當應用程序使用輸入內容來構造動態sql語句以訪問數據庫時，會發生sql注入攻擊。若是代碼使用存儲過程，而這些存儲過程做爲包含未篩選的用戶輸入的 字符串來傳遞，也會發生sql注入。sql注入可能致使攻擊者使用應用程序登錄在數據庫中執行命令。若是應用程序使用特權太高的賬戶鏈接到數據庫，這種問 題會變得很嚴重。在某些表單中，用戶輸入的內容直接用來構造動態sql命令，或者做爲存儲過程的輸入參數，這些表單特別容易受到sql注入的攻擊。而許多 網站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中自己的變量處理不當，使應用程序存在安全隱患。這樣，用戶就能夠提交一段數據庫查詢的代碼， 根據程序返回的結果，得到一些敏感的信息或者控制整個服務器，因而sql注入就發生了。mysql

如何防止SQL注入

　　概括一下，主要有如下幾點：程序員

　　1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和正則表達式

　　雙"-"進行轉換等。sql

　　2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。數據庫

　　3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。瀏覽器

　　4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。安全

　　5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝服務器

　　6.sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky,網站平臺就有億思網站安全平臺檢測工具。

　　例子1、SQL注入實例詳解(以上測試均假設服務器未開啓magic_quote_gpc)

　　1) 前期準備工做

　　先來演示經過SQL注入漏洞，登入後臺管理員界面

　　首先，建立一張試驗用的數據表：

　　CREATE TABLE `users` (

　　`id` int(11) NOT NULL AUTO_INCREMENT,

　　`username` varchar(64) NOT NULL,

　　`password` varchar(64) NOT NULL,

　　`email` varchar(64) NOT NULL,

　　PRIMARY KEY (`id`),

　　UNIQUE KEY `username` (`username`)

　　) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=latin1;

　　添加一條記錄用於測試：

　　INSERT INTO users (username,password,email)

　　VALUES('MarcoFly',md5('test'),'marcofly@test.com');

　　接下來，貼上登陸界面的源代碼：

<html>
<head>
<title>Sql注入演示</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
</head>

<body >
<form action="validate.php" method="post">
  <fieldset >
    <legend>Sql注入演示</legend>
    <table>
      <tr>
        <td>用戶名：</td>
        <td><input type="text" name="username"></td>
      </tr>
      <tr>
        <td>密&nbsp;&nbsp;碼：</td>
        <td><input type="text" name="password"></td>
      </tr>
      <tr>
        <td><input type="submit" value="提交"></td>
        <td><input type="reset" value="重置"></td>
      </tr>
    </table>
  </fieldset>
</form>
</body>
</html>

　　附上效果圖：

\

　　當用戶點擊提交按鈕的時候，將會把表單數據提交給validate.php頁面，validate.php頁面用來判斷用戶輸入的用戶名和密碼有沒有都符合要求(這一步相當重要，也每每是SQL漏洞所在)

　　代碼以下：

<html>
<head>
<title>登陸驗證</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
</head>

<body>
<?php

       $conn=@mysql_connect("localhost",'root','') or die("數據庫鏈接失敗！");;

       mysql_select_db("injection",$conn) or die("您要選擇的數據庫不存在");

       $name=$_POST['username'];

       $pwd=$_POST['password'];

       $sql="select * from users where username='$name' and password='$pwd'";

       $query=mysql_query($sql);

       $arr=mysql_fetch_array($query);

       if(is_array($arr)){

              header("Location:manager.php");

       }else{

              echo "您的用戶名或密碼輸入有誤，<a href=\"Login.php\">請從新登陸！</a>";

       }

?>
</body>
</html>

　　注意到了沒有，咱們直接將用戶提交過來的數據(用戶名和密碼)直接拿去執行，並無實現進行特殊字符過濾，待會大家將明白，這是致命的。

　　代碼分析：若是，用戶名和密碼都匹配成功的話，將跳轉到管理員操做界面(manager.php)，不成功，則給出友好提示信息。

　　登陸成功的界面：

\

　　登陸失敗的提示：

\

　　到這裏，前期工做已經作好了，接下來將展開咱們的重頭戲：SQL注入

　　2) 構造SQL語句

　　填好正確的用戶名(marcofly)和密碼(test)後，點擊提交，將會返回給咱們「歡迎管理員」的界面。

　　select * from users where username='marcofly' and password=md5('test')

　　很明顯，用戶名和密碼都和咱們以前給出的同樣，確定可以成功登錄。可是，若是咱們輸入一個錯誤的用戶名或密碼呢?很明顯，確定登入不了吧。恩，正常狀況下是如此，可是對於有SQL注入漏洞的網站來講，只要構造個特殊的「字符串」，照樣可以成功登陸。

　　好比：在用戶名輸入框中輸入:’ or 1=1#,密碼隨便輸入，這時候的合成後的SQL查詢語句爲：

　　select * from users where username='' or 1=1#' and password=md5('')

　　語義分析：「#」在mysql中是註釋符，這樣井號後面的內容將被mysql視爲註釋內容，這樣就不會去執行了，換句話說，如下的兩句sql語句等價：

　　select * from users where username='' or 1=1#' and password=md5('')

　　等價於

　　select * from users where username='' or 1=1

SQL注入採用的' OR 1=1 # 是什麼意思呢？

最後一個#號有什麼意義呢？
SELECT * FROM test WHERE name='' OR 1=1 #' AND age='20'
這後面寫的 #' 是什麼意思呢？ 求指教
# 能夠註釋掉後面的一行SQL代碼

至關於去掉了一個where條件

MySQL 註釋, 過濾掉後面的SQL語句，使其不起做用

由於1=1永遠是都是成立的，即where子句老是爲真，將該sql進一步簡化以後，等價於以下select語句：

select * from users 沒錯，該sql語句的做用是檢索users表中的全部字段

小技巧：一個經構造後的sql語句竟有如此可怕的破壞力，相信你看到這後，開始對sql注入有了一個理性的認識了吧~

有漏洞的腳本纔有機會給你攻擊，好比一個帶參數的刪除腳本a.asp?action=del&id=2你能夠改成a.asp?action=del&id=2 or 1這樣就有可能刪除所有數據------sql注入就是經過相似的手段來破壞數據

嘗試:在個人畢業設計首頁搜索中輸入【123' or 1=(select count(1) from tb_users)--】會查詢不出人和數據  而且不會報錯   經過這樣能夠判斷是否存在表tb_users

原文地址：http://www.cnblogs.com/rush/archive/2011/12/31/2309203.html

1.1.1 摘要

日前，國內最大的程序員社區CSDN網站的用戶數據庫被黑客公開發布，600萬用戶的登陸名及密碼被公開泄露，隨後又有多家網站的用戶密碼被流傳於網絡，連日來引起衆多網民對本身帳號、密碼等互聯網信息被盜取的廣泛擔心。

網絡安全成爲了如今互聯網的焦點，這也偏偏觸動了每一位用戶的神經，因爲設計的漏洞致使了不可收拾的惡果，驗證了一句話「出來混的，早晚是要還的」，因此我想經過專題博文介紹一些經常使用的攻擊技術和防範策略。

SQL Injection也許不少人都知道或者使用過，若是沒有了解或徹底沒有聽過也沒有關係，由於接下來咱們將介紹SQL Injection。

1.1.2 正文

SQL Injection：就是經過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。

具體來講，它是利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。

首先讓咱們瞭解何時可能發生SQL Injection。

假設咱們在瀏覽器中輸入URL www.sample.com，因爲它只是對頁面的簡單請求無需對數據庫動進行動態請求，因此它不存在SQL Injection，當咱們輸入www.sample.com?testid=23時，咱們在URL中傳遞變量testid，而且提供值爲23，因爲它是對數據庫進行動態查詢的請求（其中?testid＝23表示數據庫查詢變量），因此咱們能夠該URL中嵌入惡意SQL語句。

如今咱們知道SQL Injection適用場合，接下來咱們將經過具體的例子來講明SQL Injection的應用，這裏咱們以pubs數據庫做爲例子。

咱們經過Web頁面查詢job表中的招聘信息，job表的設計以下：

sqlinjection5

圖1 jobs表

接着讓咱們實現Web程序，它根據工做Id（job_id）來查詢相應的招聘信息，示意代碼以下：

/// <summary>
/// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["departmentID"]; if (!string.IsNullOrEmpty(queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } } }

如今咱們已經完成了Web程序，接下來讓咱們查詢相應招聘信息吧。

sqlinjection6

圖2 job表查詢結果

如圖所示，咱們要查詢數據庫中工做Id值爲1的工做信息，並且在頁面顯示了該工做的Id，Description，Min Lvl和Max Lvl等信息。

如今要求咱們實現根據工做Id查詢相應工做信息的功能，想必你們很快能夠給出解決方案，SQL示意代碼以下：

SELECT     job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1)

假設如今要求咱們獲取Department表中的全部數據，並且必須保留WHERE語句，那咱們只要確保WHERE恆真就OK了，SQL示意代碼以下：

SELECT     job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE (job_id = 1) OR 1 = 1

上面咱們使得WHERE恆真，因此該查詢中WHERE已經不起做用了，其查詢結果等同於如下SQL語句。

SELECT     job_id, job_desc, min_lvl, max_lvl FROM jobs

SQL查詢代碼實現以下：

string sql1 = string.Format( "SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='{0}'", jobId);

如今咱們要經過頁面請求的方式，讓數據庫執行咱們的SQL語句，咱們要在URL中嵌入惡意表達式1=1（或2=2等等），以下URL所示：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1

等效SQL語句以下：

SELECT     job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = '1' OR '1' = 1'

sqlinjection7

圖3 job表查詢結果

如今咱們把job表中的全部數據都查詢出來了，僅僅經過一個簡單的恆真表達式就能夠進行了一次簡單的攻擊。

雖然咱們把job表的數據都查詢出來了，但數據並無太大的價值，因爲咱們把該表臨時命名爲job表，因此接着咱們要找出該表真正表名。

首先咱們假設表名就是job，而後輸入如下URL：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or 1=(select count(*) from job)--

等效SQL語句以下：

SELECT       job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from job) --'

sqlinjection8

圖4 job表查詢結果

當咱們輸入了以上URL後，結果服務器返回咱們錯誤信息，這證實了咱們的假設是錯誤的，那咱們該感受到挫敗嗎？不，其實這裏返回了不少信息，首先它 證實了該表名不是job，並且它還告訴咱們後臺數據庫是SQL Server，不是MySQL或Oracle，這也設計一個漏洞把錯誤信息直接返回給了用戶。

接下假定表名是jobs，而後輸入如下URL：

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or1=(select count(*) from jobs) --

等效SQL語句以下：

SELECT       job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id='1'or 1=(select count(*) from jobs) --'

sqlinjection

圖5 job表查詢結果

如今證實了該表名是jobs，這能夠邁向成功的一大步，因爲咱們知道了表名就能夠對該表進行增刪改操做了，並且咱們還能夠猜想出更多的表對它們做出修改，一旦修改爲功那麼這將是一場災難。

如今你們已經對SQL Injection的攻擊有了初步的瞭解了，接下讓咱們學習如何防止SQL Injection。

總的來講有如下幾點：

1.永遠不要信任用戶的輸入，要對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度，對單引號和雙"-"進行轉換等。

2.永遠不要使用動態拼裝SQL，可使用參數化的SQL或者直接使用存儲過程進行數據查詢存取。

3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。

4.+ @"\s?sysobjects\s?|\s?xp_.*?|\s?syslogins\s?|\s?sysremote\s?|\s?sysusers\s?|\s?sysxlogins\s?|\s?sysdatabases\s?|\s?aspnet_.*?|\s?exec\s?", RegexOptions.Compiled | RegexOptions.IgnoreCase);

上面咱們定義了一個正則表達式對象RegSystemThreats，而且給它傳遞了校驗用戶輸入的正則表達式。

因爲咱們已經完成了對用戶輸入校驗的正則表達式了，接下來就是經過該正則表達式來校驗用戶輸入是否合法了，因爲.NET已經幫咱們實現了判斷字符串是否匹配正則表達式的方法——IsMatch()，因此咱們這裏只需給傳遞要匹配的字符串就OK了。

示意代碼以下：

/// <summary>
/// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause) { return RegSystemThreats.IsMatch(whereClause); } /// <summary> /// A helper method to attempt to discover [known] SqlInjection attacks. /// </summary> /// <param name="whereClause">string of the whereClause to check</param> /// <param name="orderBy">string of the orderBy clause to check</param> /// <returns>true if found, false if not found </returns> public static bool DetectSqlInjection(string whereClause, string orderBy) { return RegSystemThreats.IsMatch(whereClause) || RegSystemThreats.IsMatch(orderBy); }

如今咱們完成了校驗用的正則表達式，接下來讓咱們須要在頁面中添加校驗功能。

/// <summary>
/// Handles the Load event of the Page control. /// </summary> /// <param name="sender">The source of the event.</param> /// <param name="e">The <see cref="System.EventArgs"/> instance containing the event data.</param> protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { // Gets departmentId from http request. string queryString = Request.QueryString["jobId"]; if (!string.IsNullOrEmpty(queryString)) { if (!DetectSqlInjection(queryString) && !DetectSqlInjection(queryString, queryString)) { // Gets data from database. gdvData.DataSource = GetData(queryString.Trim()); // Binds data to gridview. gdvData.DataBind(); } else { throw new Exception("Please enter correct field"); } } } }

當咱們再次執行如下URL時，被嵌入的惡意語句被校驗出來了，從而在必定程度上防止了SQL Injection。

http://localhost:3452/ExcelUsingXSLT/Default.aspx?jobid=1'or'1'='1

sqlinjection9

圖6 添加校驗查詢結果

但使用正則表達式只能防範一些常見或已知SQL Injection方式，並且每當發現有新的攻擊方式時，都要對正則表達式進行修改，這但是吃力不討好的工做。

經過參數化存儲過程進行數據查詢存取

首先咱們定義一個存儲過程根據jobId來查找jobs表中的數據。

-- =============================================
-- Author:        JKhuang
-- Create date: 12/31/2011
-- Description:    Get data from jobs table by specified jobId.
-- =============================================
ALTER PROCEDURE [dbo].[GetJobs] -- ensure that the id type is int @jobId INT AS BEGIN -- SET NOCOUNT ON; SELECT job_id, job_desc, min_lvl, max_lvl FROM dbo.jobs WHERE job_id = @jobId GRANT EXECUTE ON GetJobs TO pubs END

接着修改咱們的Web程序使用參數化的存儲過程進行數據查詢。

using (var com = new SqlCommand("GetJobs", con)) { // Uses store procedure. com.CommandType = CommandType.StoredProcedure; // Pass jobId to store procedure. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteScalar(); gdvData.DataBind(); }

如今咱們經過參數化存儲過程進行數據庫查詢，這裏咱們把以前添加的正則表達式校驗註釋掉。

sqlinjection10

圖7 存儲過程查詢結果

你們看到當咱們試圖在URL中嵌入惡意的SQL語句時，參數化存儲過程已經幫咱們校驗出傳遞給數據庫的變量不是整形，並且使用存儲過程的好處是咱們還能夠很方便地控制用戶權限，咱們能夠給用戶分配只讀或可讀寫權限。

但咱們想一想真的有必要每一個數據庫操做都定義成存儲過程嗎？並且那麼多的存儲過程也不利於平常的維護。

參數化SQL語句

仍是回到以前動態拼接SQL基礎上，咱們知道一旦有惡意SQL代碼傳遞過來，並且被拼接到SQL語句中就會被數據庫執行，那麼咱們是否能夠在拼接以前進行判斷呢？——命名SQL參數。

string sql1 = string.Format("SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs WHERE job_id = @jobId"); using (var con = new SqlConnection(ConfigurationManager.ConnectionStrings["SQLCONN1"].ToString())) using (var com = new SqlCommand(sql1, con)) { // Pass jobId to sql statement. com.Parameters.Add("@jobId", SqlDbType.Int).Value = jobId; com.Connection.Open(); gdvData.DataSource = com.ExecuteReader(); gdvData.DataBind(); }

sqlinjection10

圖8 參數化SQL查詢結果

這樣咱們就能夠避免每一個數據庫操做（尤爲一些簡單數據庫操做）都編寫存儲過程了，並且當用戶具備數據庫中jobs表的讀權限才能夠執行該SQL語句。

添加新架構

數據庫架構是一個獨立於數據庫用戶的非重複命名空間，您能夠將架構視爲對象的容器（相似於.NET中的命名空間）。

首先咱們右擊架構文件夾，而後新建架構。

clip_image002

sqlinjection12

圖9 添加HumanResource架構

上面咱們完成了在pubs數據庫中添加HumanResource架構，接着把jobs表放到HumanResource架構中。

sqlinjection15

sqlinjection13

圖 10 修改jobs表所屬的架構

當咱們再次執行如下SQL語句時，SQL Server提示jobs無效，這是究竟什麼緣由呢？以前還運行的好好的。

SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs

sqlinjection14

圖 11 查詢輸出

當咱們輸入完整的表名「架構名.對象名」（HumanResource.jobs）時，SQL語句執行成功。

SELECT job_id, job_desc, min_lvl, max_lvl FROM HumanResource.jobs

sqlinjection16

爲何以前咱們執行SQL語句時不用輸入完整表名dbo.jobs也能夠執行呢？

這是由於默認的架構（default schema）是dbo，當只輸入表名時，Sql Server會自動加上當前登陸用戶的默認的架構（default schema）——dbo。

因爲咱們使用自定義架構，這也下降了數據庫表名被猜想出來的可能性。

LINQ to SQL

前面使用了存儲過程和參數化查詢，這兩種方法都是很是經常使用的，而針對於.NET Framework的ORM框架也有不少，如：NHibernate，Castle和Entity Framework，這裏咱們使用比較簡單LINQ to SQL。

sqlinjection17

圖 12 添加jobs.dbml文件

var dc = new pubsDataContext(); int result; // Validates jobId is int or not. if (int.TryParse(jobId, out result)) { gdvData.DataSource = dc.jobs.Where(p => p.job_id == result); gdvData.DataBind(); }

相比存儲過程和參數化查詢，LINQ to SQL咱們只需添加jobs.dbml，而後使用LINQ對錶進行查詢就OK了。

1.1.3 總結

咱們在本文中介紹了SQL Injection的基本原理，經過介紹什麼是SQL Injection，怎樣進行SQL Injection和如何防範SQL Injection。經過一些程序源碼對SQL的攻擊進行了細緻的分析，使咱們對SQL Injection機理有了一個深刻的認識，做爲一名Web應用開發人員，必定不要盲目相信用戶的輸入，而要對用戶輸入的數據進行嚴格的校驗處理，不然的 話，SQL Injection將會不期而至。

最後，祝你們新年快樂，身體健康，Code with pleasure。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程