利用SQL注入漏洞登录后台

所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.

sql注入

什么时候最易受到sql注入攻击

   当应用程序使用输入内容来构造动态sql语句以访问数据库时,会发生sql注入攻击。如果代码使用存储过程,而这些存储过程作为包含未筛选的用户输入的 字符串来传递,也会发生sql注入。sql注入可能导致攻击者使用应用程序登陆在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库,这种问 题会变得很严重。在某些表单中,用户输入的内容直接用来构造动态sql命令,或者作为存储过程的输入参数,这些表单特别容易受到sql注入的攻击。而许多 网站程序在编写时,没有对用户输入的合法性进行判断或者程序中本身的变量处理不当,使应用程序存在安全隐患。这样,用户就可以提交一段数据库查询的代码, 根据程序返回的结果,获得一些敏感的信息或者控制整个服务器,于是sql注入就发生了。

如何防止SQL注入

  归纳一下,主要有以下几点:

  1.永远不要信任用户的输入。对用户的输入进行校验,可以通过正则表达式,或限制长度;对单引号和

  双"-"进行转换等。

  2.永远不要使用动态拼装sql,可以使用参数化的sql或者直接使用存储过程进行数据查询存取。

  3.永远不要使用管理员权限的数据库连接,为每个应用使用单独的权限有限的数据库连接。

  4.不要把机密信息直接存放,加密或者hash掉密码和敏感的信息。

  5.应用的异常信息应该给出尽可能少的提示,最好使用自定义的错误信息对原始错误信息进行包装

  6.sql注入的检测方法一般采取辅助软件或网站平台来检测,软件一般采用sql注入检测工具jsky,网站平台就有亿思网站安全平台检测工具。

  例子一、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'),'[email protected]');

  接下来,贴上登录界面的源代码:



Sql注入演示



 

    Sql注入演示
   
     
       
       
     
     
       
       
     
     
       
       
     
   
用户名:
密  码:

 



  附上效果图

  当用户点击提交按钮的时候,将会把表单数据提交给validate.php页面,validate.php页面用来判断用户输入的用户名和密码有没有都符合要求(这一步至关重要,也往往是SQL漏洞所在)

  代码如下:



登录验证


       $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 "您的用户名或密码输入有误,请重新登录!";

       }

?>

  注意到了没有,我们直接将用户提交过来的数据(用户名和密码)直接拿去执行,并没有实现进行特殊字符过滤,待会你们将明白,这是致命的。

  代码分析:如果,用户名和密码都匹配成功的话,将跳转到管理员操作界面(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

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表的设计如下:

利用SQL注入漏洞登录后台_第1张图片

图1 jobs表

接着让我们实现Web程序,它根据工作Id(job_id)来查询相应的招聘信息,示意代码如下:

/// 
/// Handles the Load event of the Page control.
/// 
/// The source of the event.
/// The  instance containing the event data.
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程序,接下来让我们查询相应招聘信息吧。

利用SQL注入漏洞登录后台_第2张图片

图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'

利用SQL注入漏洞登录后台_第3张图片

图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) --'
利用SQL注入漏洞登录后台_第4张图片

图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) --'
利用SQL注入漏洞登录后台_第5张图片

图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了。

示意代码如下:

/// 
/// A helper method to attempt to discover [known] SqlInjection attacks.  
/// 
/// string of the whereClause to check
/// true if found, false if not found 
public static bool DetectSqlInjection(string whereClause)
{
    return RegSystemThreats.IsMatch(whereClause);
}

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

现在我们完成了校验用的正则表达式,接下来让我们需要在页面中添加校验功能。

/// 
/// Handles the Load event of the Page control.
/// 
/// The source of the event.
/// The  instance containing the event data.
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

利用SQL注入漏洞登录后台_第6张图片

图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(); 
}

现在我们通过参数化存储过程进行数据库查询,这里我们把之前添加的正则表达式校验注释掉。

利用SQL注入漏洞登录后台_第7张图片

图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(); 
}
利用SQL注入漏洞登录后台_第8张图片

图8 参数化SQL查询结果

这样我们就可以避免每个数据库操作(尤其一些简单数据库操作)都编写存储过程了,而且当用户具有数据库中jobs表的读权限才可以执行该SQL语句。

添加新架构

数据库架构是一个独立于数据库用户的非重复命名空间,您可以将架构视为对象的容器(类似于.NET中的命名空间)。

首先我们右击架构文件夹,然后新建架构。

利用SQL注入漏洞登录后台_第9张图片

利用SQL注入漏洞登录后台_第10张图片

图9 添加HumanResource架构

上面我们完成了在pubs数据库中添加HumanResource架构,接着把jobs表放到HumanResource架构中。

利用SQL注入漏洞登录后台_第11张图片
利用SQL注入漏洞登录后台_第12张图片

图 10 修改jobs表所属的架构

当我们再次执行以下SQL语句时,SQL Server提示jobs无效,这是究竟什么原因呢?之前还运行的好好的。

SELECT job_id, job_desc, min_lvl, max_lvl FROM jobs
利用SQL注入漏洞登录后台_第13张图片

图 11 查询输出

当我们输入完整的表名“架构名.对象名”(HumanResource.jobs)时,SQL语句执行成功。

SELECT job_id, job_desc, min_lvl, max_lvl FROM HumanResource.jobs
利用SQL注入漏洞登录后台_第14张图片

为什么之前我们执行SQL语句时不用输入完整表名dbo.jobs也可以执行呢?

这是因为默认的架构(default schema)是dbo,当只输入表名时,Sql Server会自动加上当前登录用户的默认的架构(default schema)——dbo。

由于我们使用自定义架构,这也降低了数据库表名被猜测出来的可能性。

LINQ to SQL

前面使用了存储过程和参数化查询,这两种方法都是非常常用的,而针对于.NET Framework的ORM框架也有很多,如:NHibernate,Castle和Entity Framework,这里我们使用比较简单LINQ to SQL。

利用SQL注入漏洞登录后台_第15张图片

图 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将会不期而至。

你可能感兴趣的:(计算机,零基础学网络安全,学习路线,web安全,网络安全,经验分享,安全,mysql)