① 如何防范sql注入攻击
一、 SQL注入攻击的简单示例。
statement := "SELECT * FROM Users WHERE Value= " + a_variable + "
上面这条语句是很普通的一条SQL语句，他主要实现的功能就是让用户输入一个员工编号然后查询处这个员工的信息。但是若这条语句被不法攻击者改装过后，就可能成为破坏数据的黑手。如攻击者在输入变量的时候，输入以下内容SA001’;drop table c_order--。那么以上这条SQL语句在执行的时候就变为了SELECT * FROM Users WHERE Value= ‘SA001’;drop table c_order--。
这条语句是什么意思呢?‘SA001’后面的分号表示一个查询的结束和另一条语句的开始。c_order后面的双连字符 指示当前行余下的部分只是一个注释，应该忽略。如果修改后的代码语法正确，则服务器将执行该代码。系统在处理这条语句时，将首先执行查询语句，查到用户编号为SA001 的用户信息。然后，数据将删除表C_ORDER(如果没有其他主键等相关约束，则删除操作就会成功)。只要注入的SQL代码语法正确，便无法采用编程方式来检测篡改。因此，必须验证所有用户输入，并仔细检查在您所用的服务器中执行构造 SQL命令的代码。
二、 SQL注入攻击原理。
可见SQL注入攻击的危害性很大。在讲解其防止办法之前，数据库管理员有必要先了解一下其攻击的原理。这有利于管理员采取有针对性的防治措施。
SQL注入是目前比较常见的针对数据库的一种攻击方式。在这种攻击方式中，攻击者会将一些恶意代码插入到字符串中。然后会通过各种手段将该字符串传递到SQLServer数据库的实例中进行分析和执行。只要这个恶意代码符合SQL语句的规则，则在代码编译与执行的时候，就不会被系统所发现。
SQL注入式攻击的主要形式有两种。一是直接将代码插入到与SQL命令串联在一起并使得其以执行的用户输入变量。上面笔者举的例子就是采用了这种方法。由于其直接与SQL语句捆绑，故也被称为直接注入式攻击法。二是一种间接的攻击方法，它将恶意代码注入要在表中存储或者作为原书据存储的字符串。在存储的字符串中会连接到一个动态的SQL命令中，以执行一些恶意的SQL代码。
注入过程的工作方式是提前终止文本字符串，然后追加一个新的命令。如以直接注入式攻击为例。就是在用户输入变量的时候，先用一个分号结束当前的语句。然后再插入一个恶意SQL语句即可。由于插入的命令可能在执行前追加其他字符串，因此攻击者常常用注释标记“—”来终止注入的字符串。执行时，系统会认为此后语句位注释，故后续的文本将被忽略，不背编译与执行。
三、 SQL注入式攻击的防治。
既然SQL注入式攻击的危害这么大，那么该如何来防治呢?下面这些建议或许对数据库管理员防治SQL注入式攻击有一定的帮助。
1、 普通用户与系统管理员用户的权限要有严格的区分。
如果一个普通用户在使用查询语句中嵌入另一个Drop Table语句，那么是否允许执行呢?由于Drop语句关系到数据库的基本对象，故要操作这个语句用户必须有相关的权限。在权限设计中，对于终端用户，即应用软件的使用者，没有必要给他们数据库对象的建立、删除等权限。那么即使在他们使用SQL语句中带有嵌入式的恶意代码，由于其用户权限的限制，这些代码也将无法被执行。故应用程序在设计的时候，最好把系统管理员的用户与普通用户区分开来。如此可以最大限度的减少注入式攻击对数据库带来的危害。
2、 强迫使用参数化语句。
如果在编写SQL语句的时候，用户输入的变量不是直接嵌入到SQL语句。而是通过参数来传递这个变量的话，那么就可以有效的防治SQL注入式攻击。也就是说，用户的输入绝对不能够直接被嵌入到SQL语句中。与此相反，用户的输入的内容必须进行过滤，或者使用参数化的语句来传递用户输入的变量。参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中。采用这种措施，可以杜绝大部分的SQL注入式攻击。不过可惜的是，现在支持参数化语句的数据库引擎并不多。不过数据库工程师在开发产品的时候要尽量采用参数化语句。
3、 加强对用户输入的验证。
总体来说，防治SQL注入式攻击可以采用两种方法，一是加强对用户输入内容的检查与验证;二是强迫使用参数化语句来传递用户输入的内容。在SQLServer数据库中，有比较多的用户输入内容验证工具，可以帮助管理员来对付SQL注入式攻击。测试字符串变量的内容，只接受所需的值。拒绝包含二进制数据、转义序列和注释字符的输入内容。这有助于防止脚本注入，防止某些缓冲区溢出攻击。测试用户输入内容的大小和数据类型，强制执行适当的限制与转换。这即有助于防止有意造成的缓冲区溢出，对于防治注入式攻击有比较明显的效果。
如可以使用存储过程来验证用户的输入。利用存储过程可以实现对用户输入变量的过滤，如拒绝一些特殊的符号。如以上那个恶意代码中，只要存储过程把那个分号过滤掉，那么这个恶意代码也就没有用武之地了。在执行SQL语句之前，可以通过数据库的存储过程，来拒绝接纳一些特殊的符号。在不影响数据库应用的前提下，应该让数据库拒绝包含以下字符的输入。如分号分隔符，它是SQL注入式攻击的主要帮凶。如注释分隔符。注释只有在数据设计的时候用的到。一般用户的查询语句中没有必要注释的内容，故可以直接把他拒绝掉，通常情况下这么做不会发生意外损失。把以上这些特殊符号拒绝掉，那么即使在SQL语句中嵌入了恶意代码，他们也将毫无作为。
故始终通过测试类型、长度、格式和范围来验证用户输入，过滤用户输入的内容。这是防止SQL注入式攻击的常见并且行之有效的措施。
4、 多多使用SQL Server数据库自带的安全参数。
为了减少注入式攻击对于SQL Server数据库的不良影响，在SQLServer数据库专门设计了相对安全的SQL参数。在数据库设计过程中，工程师要尽量采用这些参数来杜绝恶意的SQL注入式攻击。
如在SQL Server数据库中提供了Parameters集合。这个集合提供了类型检查和长度验证的功能。如果管理员采用了Parameters这个集合的话，则用户输入的内容将被视为字符值而不是可执行代码。即使用户输入的内容中含有可执行代码，则数据库也会过滤掉。因为此时数据库只把它当作普通的字符来处理。使用Parameters集合的另外一个优点是可以强制执行类型和长度检查，范围以外的值将触发异常。如果用户输入的值不符合指定的类型与长度约束，就会发生异常，并报告给管理员。如上面这个案例中，如果员工编号定义的数据类型为字符串型，长度为10个字符。而用户输入的内容虽然也是字符类型的数据，但是其长度达到了20个字符。则此时就会引发异常，因为用户输入的内容长度超过了数据库字段长度的限制。
5、 多层环境如何防治SQL注入式攻击?
在多层应用环境中，用户输入的所有数据都应该在验证之后才能被允许进入到可信区域。未通过验证过程的数据应被数据库拒绝，并向上一层返回一个错误信息。实现多层验证。对无目的的恶意用户采取的预防措施，对坚定的攻击者可能无效。更好的做法是在用户界面和所有跨信任边界的后续点上验证输入。如在客户端应用程序中验证数据可以防止简单的脚本注入。但是，如果下一层认为其输入已通过验证，则任何可以绕过客户端的恶意用户就可以不受限制地访问系统。故对于多层应用环境，在防止注入式攻击的时候，需要各层一起努力，在客户端与数据库端都要采用相应的措施来防治SQL语句的注入式攻击。
6、 必要的情况下使用专业的漏洞扫描工具来寻找可能被攻击的点。
使用专业的漏洞扫描工具，可以帮助管理员来寻找可能被SQL注入式攻击的点。不过漏洞扫描工具只能发现攻击点，而不能够主动起到防御SQL注入攻击的作用。当然这个工具也经常被攻击者拿来使用。如攻击者可以利用这个工具自动搜索攻击目标并实施攻击。为此在必要的情况下，企业应当投资于一些专业的漏洞扫描工具。一个完善的漏洞扫描程序不同于网络扫描程序，它专门查找数据库中的SQL注入式漏洞。最新的漏洞扫描程序可以查找最新发现的漏洞。所以凭借专业的工具，可以帮助管理员发现SQL注入式漏洞，并提醒管理员采取积极的措施来预防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 注入攻击的原理，以及对数据库可能产生的不利影响。
SQL注入就是攻击者通过正常的WEB页面,把自己SQL代码传入到应用程序中,从而通过执行非程序员预期的SQL代码,达到窃取数据或破坏的目的。
当应用程序使用输入内容来构造动态SQL语句以访问数据库时，会发生SQL注入攻击。如果代码使用存储过程，而这些存储过程作为包含未筛选的用户输入的字符串来传递，也会发生SQL注入。SQL注入可能导致攻击者使用应用程序登陆在数据库中执行命令。如果应用程序使用特权过高的帐户连接到数据库，这种问题会变得很严重。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或者作为存储过程的输入参数，这些表单特别容易受到SQL注入的攻击。而许多网站程序在编写时，没有对用户输入的合法性进行判断或者程序中本身的变量处理不当，使应用程序存在安全隐患。这样，用户就可以提交一段数据库查询的代码，根据程序返回的结果，获得一些敏感的信息或者控制整个服务器，于是SQL注入就发生了。
一般SQL注入
在Web 应用程序的登录验证程序中,一般有用户名(username) 和密码(password) 两个参数,程序会通过用户所提交输入的用户名和密码来执行授权操作。我们有很多人喜欢将SQL语句拼接起来。例如：
Select * from users where username =’ txtusername.Text ’ and password =’ txtpassword.Text ’
其原理是通过查找users 表中的用户名(username) 和密码(password) 的结果来进行授权访问, 在txtusername.Text为mysql，txtpassword.Text为mary，那么SQL查询语句就为：
Select * from users where username =’ mysql ’ and password =’ mary ’
如果分别给txtusername.Text 和txtpassword.Text赋值’ or ‘1’ = ‘1’ --和abc。那么,SQL 脚本解释器中的上述语句就会变为:
Select * from users where username =’’or ‘1’ = ‘1’ -- and password =’abc’
该语句中进行了两个条件判断,只要一个条件成立,就会执行成功。而'1'='1'在逻辑判断上是恒成立的,后面的"--" 表示注释,即后面所有的语句为注释语句这样我们就成功登录。即SQL注入成功.
如果我们给txtusername.Text赋值为:’;drop table users--即:
Select * from users where username =’’;drop table users-- and password =’abc’
整个用户表就没有了，当然这里要猜出数据表名称。想想是多么可怕的事情。
好我想大家在这里已经大致明白了一般SQL注入了，试想下您的登录程序会不会出现我上述的情况。
防范SQL注入
那么现在大家都在思考怎么防范SQL注入了这里给出一点个人的建议
1.限制错误信息的输出
这个方法不能阻止SQL注入，但是会加大SQL注入的难度，不会让注入者轻易得到一些信息，让他们任意破坏数据库。SQL Server有一些系统变量，如果我们没有限制错误信息的输出，那么注入着可以直接从出错信息获取，例如（假定这里用的string即字符类型并可以发生SQL注入）：http://www.xxx.com/showdetail.aspx?id=49 and user>0 这句语句很简单，但却包含了SQL Server特有注入方法的精髓，。首先看看它的含义：首先，前面的语句是正常的，重点在and user>0，我们知道，user是SQL Server的一个内置变量，它的值是当前连接的用户名，类型为nvarchar。拿一个nvarchar的值跟int的数0比较，系统会先试图将nvarchar的值转成int型，当然，转的过程中肯定会出错，SQL Server的出错提示是：将nvarchar值 ”abc” 转换数据类型为 int 的列时发生语法错误，呵呵，abc正是变量user的值，这样，注入着就拿到了数据库的用户名。
众所周知，SQL Server的用户sa是个等同Adminstrators权限的角色，拿到了sa权限，几乎肯定可以拿到主机的Administrator了。上面的方法可以很方便的测试出是否是用sa登录，要注意的是：如果是sa登录，提示是将”dbo”转换成int的列发生错误，而不是”sa”。
当然注入者还可以输入不同的信息来得到他们想要的信息 ，上面只是其中一个例子，所以我们要限制错误信息的输出，从而保护我们的数据库数据，这里我给出.NET限制错误信息的方法：
在Web.Config文件中设置
<customErrors mode="On" defaultRedirect="error.aspx">
</customErrors>
这样当发生错误时候就不会讲信息泄露给外人。
2.限制访问数据库帐号的权限
对于数据库的任何操作都是以某种特定身份和相应权限来完成的,SQL语句执行前,在数据库服务器端都有一个用户权限验证的过程,只有具备相应权限的帐号才可能执行相应权限内的SQL语句。因此,限制数据库帐号权限,实际上就阻断了某些SQL语句执行的可能。不过,这种方法并不能根本解决SQL注入问题,因为连接数据库的帐号几乎总是比其他单个用户帐号拥有更多的权限。通过限制贴帐号权限,可以防止删除表的攻击,但不能阻止攻击者偷看别人的信息。
3.参数化使用命令
参数化命令是在SQL文本中使用占位符的命令。占位符表示需要动态替换的数据,它们通过Command对象Parameters集合来传送。能导致攻击的SQL代码可以写成:
Select * from employee where userID=@userID;
如果用户输入: 09105022’OR ‘1’=’1,将得不到何记录,因为没有一个用户ID与文本框中输入的’ 09105022’OR ‘1’=’1’相等。参数化命令的语法随提供程序的不同略有差异。对于SQL SERVER提供程序,参数化命令使用命名的占位符(具有唯一的名字),而对于OLE DB提供程序,每个硬编码的值被问号代替。使用OLE DB提供程序时,需要保证参数的顺序和它们出现在SQL字符串中的位置一致。SQL SERVER提供程序没有这样的需求,因为它们用名字和占位符匹配。
4.调用存储过程
存储过程是存储在数据库服务器上的一系列SQL代码,存储过程与函数相似,有良好的逻辑封装结构,可以接收和返回数据。使用存储过程可以使代码更易于维护,因为对存储过程的更改不会导致应用程序的重新编译,使用存储过程还可以节省带宽,提高应用程序性能。因为存储过程是存储在数据库服务端的独立的封装体,调用存储过程可以保证应用程序只执行存储过程中的固定代码,从而杜绝SQL语句注入的可能。结合上述所讲的参数化命令,可以实现SQL代码可以实现的任何功能,并进一步提高应用程序的安全等级。
5.限制输入长度
如果在Web页面上使用文本框收集用户输入的数据,使用文本框的MaxLength属性来限制用户输入过长的字符也是一个很好的方法,因为用户的输入不够长,也就减少了贴入大量脚本的可能性。程序员可以针对需要收集的数据类型作出一个相应的限制策略。
6.URL重写技术
我们利用URL重写技术过滤一些SQL注入字符，从而达到防御SQL注入。因为许多SQL注入是从URL输入发生的。
7.传递参数尽量不是字符
假设我们显示一篇新闻的页面，从URL传递参数中获得newid我们可能会随手写下下面的代码：
string newsid = Request.QueryString["newsid"];
string newssql = "select * from news where newsid=" + newsid;
如果传递过来的参数是数字字符就没有问题。但是如果传递过来的newsid是“1 delete from table ”的话，那么sql的值就变成了“select * from table where newsid=1 delete from news”。发生注入成功。但是这里改为
int newsid=int.Parse(Request.QueryString["newsid"].ToString());
string newssql = "select * from news where newsid=" + newsid.Tostring();
这里如果还是上面"1 delete from table "会发生错误，因为在转换时候出现了错误
从上面的一个小例子，我们得出在传递参数时候尽量不要用字符，免得被注入。
最后是我想扩展下利用URL重写技术来过滤一些SQL注入字符，首先这里有一篇关于URL重写的文章，我的基本思想是可以利用它，屏蔽一些危险的SQL注入字符串，这些字符串我们可以人为的设定，毕竟我们还是根据特定的环境设定我们防御措施。首先我们在MoleRewriter类中的Rewrite函数得到绝对的URL判断其中是否有危险字符，如果有我们就将它链接到一个提示用户您输入危险的URL地址。如果不是我们继续判断是否触发了其他的URL重写的规则，触发了就重写。这样就大致上能在URL上防御危险字符。
代码
<configSections>
<section name="RewriterConfig" type="URLRewriter.Config., URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default_sql_error.aspx</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/d(\d+)\.aspx</LookFor>
<SendTo>~/Default2.aspx</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
<httpMoles>
<add type="URLRewriter.MoleRewriter, URLRewriter" name="MoleRewriter" />
</httpMoles>
上面是要在web.config配置文件加上的内容，这里我加上了两个重写规则，第一个规则是专门针对满足这个正则表达式的页面URL查看是否有危险字符，有危险字符就会发送到Default_sql_error.aspx页面，来示警。这里我假定会发生危险字符注入的页面时以"d"字符开头并加上数字的页面（这里我们可以根据实际情况自己定义，看哪些页面URL容易发生我们就制定这些页面的正则表达式），第二个是一般URL重写。因为这里我采用的是HTTP模块执行URL重写，所以加上<httpMoles></httpMoles>这一块。
第二步就是要在重写Rewrite函数了
代码
protected override void Rewrite(string requestedPath, System.Web.HttpApplication app)
{
// 获得配置规则
RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules;
//获得绝对的URL
Uri url = app.Request.Url;
// 判断url 中是否含有SQL 注入攻击敏感的字符或字符串,如果存在,sqlatFlag = 1 ;
string urlstr = url.AbsoluteUri;
int sqlatFlag = 0;
//这里我们根据实际情况随便编写，我这里这是随便列举了几个
string words = "exec ,xp ,sp ,declare ,cmd ,Union ,--";
string[] split = words.Split(',');
foreach (string s in split)
{
if (urlstr.IndexOf(s.ToUpper()) > 0)
{
sqlatFlag = 1;
break;
}
}
if (sqlatFlag == 1)
{
// 创建regex
Regex re = new Regex(rules[0].SendTo, RegexOptions.IgnoreCase);
// 找到匹配的规则,进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.ToString());
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
}
else
{
// 遍历除rules[0 ]以外的其他URL 重写规则
for (int i = 1; i < rules.Count; i++)
{
// 获得要查找的模式,并且解析URL (转换为相应的目录)
string lookFor = "^" + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rules[i].LookFor) + "$";
// 创建regex
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的规则
if (re.IsMatch(requestedPath))
{
// 找到了匹配的规则, 进行必要的替换
string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rules[i].SendTo));
// 重写URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;
// 退出For 循环
}
}
}
}
那么下一步就是检验例子了
首先我们输入http://localhost:4563/web/Default.aspx?id=1;--
这样http://localhost:4563/web/Default.aspx?id=1;-- 没有改变，就会显示Default_sql_error.aspx里内容“您输入了危险字符”。
再输入http://localhost:4563/web/D11.aspx就会显示 Default2.aspx内容，因为这里触发了第二个重写规则
④ 部分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注入初级(合天网安实验室)
⑤ 求web2.0的SQL注入攻击方法相关论文或资料，急等，24小时，送100分
Title : the Information Security Detection and Prevention of University Database
Abstract: With the increase of network security awareness, the single method of penetration test is unable to satisfy the need of remote penetration. The more effective way of remote penetration test uses comprehensively progressive attack techniques to intrude the internal network and get the target computer's authorization via horizontal privilege escalation so as to obtain the confidential information finally. As the preferred way of intruding an internal network, web scriting attack that mainly uses SQL injection attack has become one of the most important techniques in remote penetration test.SQL injection attack represents the common method that hackers use to attck databases. Like general access to a web page, It accesses the page via normal WWW ports in which case the firewall doesn't sound the alarm. Due to the flexibility of SQL injection, unexpected conditions often occure when using it. This article takes a PHP+MySQL website based on B/S architecture as a good example to deeply analyze the detection and prevention measures of SQL injection.
Key Words: DataBase information security SQL injection solutions
⑥ 如何防范SQL注入式攻击
SQL注入攻击的危害很大，而且防火墙很难对攻击行为进行拦截，主要的SQL注入攻击防范方法，具体有以下几个方面。
1、分级管理
对用户进行分级管理，严格控制用户的权限，对于普通用户，禁止给予数据库建立、删除、修改等相关权限，只有系统管理员才具有增、删、改、查的权限。
2、参数传值
程序员在书写SQL语言时，禁止将变量直接写入到SQL语句，必须通过设置相应的参数来传递相关的变量。从而抑制SQL注入。数据输入不能直接嵌入到查询语句中。同时要过滤输入的内容，过滤掉不安全的输入数据。或者采用参数传值的方式传递输入变量，这样可以最大程度防范SQL注入攻击。
3、基础过滤与二次过滤
SQL注入攻击前，入侵者通过修改参数提交and等特殊字符，判断是否存在漏洞，然后通过select、update等各种字符编写SQL注入语句。因此防范SQL注入要对用户输入进行检查，确保数据输入的安全性，在具体检查输入或提交的变量时，对于单引号、双引号、冒号等字符进行转换或者过滤，从而有效防止SQL注入。
当然危险字符有很多，在获取用户输入提交参数时，首先要进行基础过滤，然后根据程序的功能及用户输入的可能性进行二次过滤，以确保系统的安全性。
4、使用安全参数
SQL数据库为了有效抑制SQL注入攻击的影响。在进行SQLServer数据库设计时设置了专门的SQL安全参数。在程序编写时应尽量使用安全参数来杜绝注入式攻击，从而确保系统的安全性。
5、漏洞扫描
为了更有效地防范SQL注入攻击，作为系统管理除了设置有效的防范措施，更应该及时发现系统存在SQL攻击安全漏洞。系统管理员可以采购一些SQL漏洞扫描工具，通过专业的扫描工具，可以及时的扫描到系统存在的相应漏洞。
6、多层验证
现在的网站系统功能越来越庞大复杂。为确保系统的安全，访问者的数据输入必须经过严格的验证才能进入系统，验证没通过的输入直接被拒绝访问数据库，并且向上层系统发出错误提示信息。同时在客户端访问程序中验证访问者的相关输入信息，从而更有效的防止简单的SQL注入。但是如果多层验证中的下层如果验证数据通过，那么绕过客户端的攻击者就能够随意访问系统。因此在进行多层验证时，要每个层次相互配合，只有在客户端和系统端都进行有效的验证防护，才能更好地防范SQL注入攻击。
7、数据库信息加密
传统的加解密方法大致分为三种：对称加密、非对称加密、不可逆加密。
⑦ sql盲注攻击是什么意思
SQL盲注是一种SQL注入漏洞，攻击者可以操纵SQL语句，应用会针对真假条件返回不同的值。但是攻击者无法检索查询结果。
由于SQL盲注漏洞非常耗时且需要向Web服务发送很多请求，因而要想利用该漏洞，就需要采用自动的技术。
SQL盲注是一种很常见的漏洞，但有时它非常细微，经验不丰富的攻击者可能会检测不到。
⑧ SQL注入攻击与防范
关于SQL注入攻击与防范
随着网络的普及，关系数据库的广泛应用，网络安全越来越重要。下面是我为大家搜索整理了关于SQL注入攻击与防范，欢迎参考阅读，希望对大家有所帮助。想了解更多相关信息请持续关注我们应届毕业生培训网!
一、 SQL注入攻击
简言之，SQL注入是应用程序开发人员未预期地把SQL代码传入到应用程序的过程。它由于应用程序的糟糕设计而成为可能，并且只有那些直接使用用户提供的值构建SQL语句的应用程序才会受影响。
例如：用户输入客户ID后，GridView显示客户的全部行记录。在一个更加真实的案例中，用户还要输入密码之类的验证信息，或者根据前面的登录页面得到用户ID，可能还会有一些用户输入关键信息的文本框，如订单的日期范围或产品名称。问题在于命令是如何被执行的。在这个示例中，SQL语句通过字符串构造技术动态创建。文本框txtID的值被直接复制到字符串中。下面是代码：
在这个示例中，攻击者可以篡改SQL语句。通常，攻击的第一个目标是得到错误信息。如果错误没有被恰当处理，底层的信息就会暴露给攻击者。这些信息可用于进一步攻击。
例如，想象一下在文本一下在文本框中输入下面的字符串会发生什么?
ALFKI'OR '1'='1
再看看因此生成的完整SQL语句：
这条语句将返回所有的订单记录，即便那些订单不是由ALFDI创建，因为对每一行而言而有信1=1总是true。这样产生的后果是没有显示当前用户特定信息，却向攻击者显示了全部资料，如果屏幕上显示的是敏感信息，如社会保险号，生日或信用卡资料，就会带来严重的问题。事实上，这些简单的SQL注入往往是困扰那些大型电子商务公司的麻烦。一般而言，攻击点不在于文本框而在于查询字符串(可被用于向数据库传送值，如列表页向详细信息页面传送唯一标识符)。
还可以进行更复杂的攻击。例如，攻击者可以使用两个连接号(--)注释掉SQL语句的剩余部分。这样的攻击只限于SQL Server，不过对于其他类型的数据库也有等效的办法，如MySql使用(#)号，Oracle使用(;)号。另外攻击者还可以执行含有任意SQL语句的批处理命令。对于SQL Server提供程序，攻击者只需在新命令前加上分号(;)。攻击者可以采用这样的方式删除其他表的内容，甚至调用SQL Server的系统存储过程xp_cmdshell在命令执行任意的程序。
下面是攻击者在文本框中输入的，它的攻击目标是删除Customers表的全部行。
LUNCHUN’;DELETE*FROM Customers--
二、防范
如何预防SQL注入攻击呢?需要记住几点。首先，使用TextBox.MaxLength属性防止用户输入过长的字符是一个好办法。因为它们不够长，也就减少了贴入大量脚本的可能性。其次，要使用ASP.NET验证控件锁定错误的数据(如文本、空格、数值中的特殊字符)。另外，要限制错误信息给出的提示。捕获到数据库异常时，只显示一些通用的信息(如“数据源错误”)而不是显示Exception.Message属性中的信息，它可能暴露了系统攻击点。
更为重要的是，一定要小心去除特殊字符。比如，可以将单引号替换为两个单引号，这样它们就不会和SQL语句的分隔符混淆：
string ID=txtID.Text().Replace(“’”，”’’”);
当然，如果文本确实需要包含单引号，这样做就引入了其他麻烦。另外，某些SQL注入攻击还是可行的。替换单引号可以防止用户提前结束一个字符串，然而，如果动态构建含有数值的SQL语句，SQL注入攻击又有发挥的空间了。这个漏洞常被(这是很危险的)忽视。更好的解决办法是使用参数化的命令或使用存储过程执行转义以防止SQL注入攻击。
另一个好建议是限制用于访问数据库的账号的权限。这样该账号将没有权限访问其他数据库或执行扩展的存储过程。不过这样并不能解决SQL脚本注入的问题，因为用于连接数据库的进程几乎总是需要比任意单个用户更大的权限。通过限制权限，可以预防删除表的攻击，但不能阻止攻击者偷看别人的.信息
三、POST注入攻击
精明的用户可能会知道还有另外一个Web控件攻击的潜在途径。虽然参数化的命令防止了SQL注入攻击，但它们不能阻止攻击者向回发到服务器的数据添加恶意的值。如果不检查这些值，就使得攻击者可以提交本来不可能存在的控件值。
例如，假设你有一个显示当前用户订单的列表。狡诈的攻击者可能保存该页面的一个本地副本，修改HTML内容向列表添加更多的项目，然后选择某个“假”的项目。如果攻击成功，攻击者就能够看到其他用户订单，这显然是一个问题。幸好，ASP.NET使用一个很少被提及的叫做“事件验证”的特性来防止这种攻击。事件验证检查回发到服务器的数据并验证其中值的合法性。例如，如果回发的数据表明用户选择了一个没有意义的数据(因为它在控件中并不存在)，ASP.NET就产生一个错误并停止处理。可以在Page指令中设置EnableEventValidation特性为false来禁用事件验证。创建使用客户端脚本动态改变内容的页面时，需要执行这一步。不过，此时在使用这些值之前要注意检查潜在的POST注入攻击。
;⑨ 什么是sql注入攻击，请结合实例简述其原理
作为一名学生，大家都经历过考试，既然有考试，那将需要时间地点科目：
____月____日____时____分，第____教学楼____层____教室，考________，时长____分。
一个考试应该是这样的：
6月23日9时30分，第13教学楼6层601教室，考高等数学，时长120分。
你是一个学生，你按照学校安排执行：到了6月23号9.30，然后拿着证件和笔去13教学楼6层601考高等数学。
但是如果空格里填写了不正常的值，甚至包含了指令：
6月23日9时30分，第13教学楼6层601教室，考英语，时长90分钟。6月24日9时30分，第13教学楼6层601教室高等数学，时长120分。
作为一名人类，可以轻易发现科目处添了一串指令，但是如果是机器呢？
⑩ sql注入攻击与防御是什么
SQL注入攻击：
恶意用户在提交查询请求的过程中将SQL语句插入到请求内容中，同时程序本身对用户输入内容过分信任而未对恶意用户插入的SQL语句进行过滤，导致SQL语句直接被服务端执行。
SQL注入攻击分类：
①注入点的不同分类：数字类型的注入、字符串类型的注入。
②提交方式的不同分类：GET注入、POST注入、COOKIE注入、HTTP注入。
③获取信息方式的不同分类：基于布尔的盲注、基于时间的盲注、基于报错的盲注。
SQL注入攻击防御方法：
①定制黑名单：将常用的SQL注入字符写入到黑名单中，然后通过程序对用户提交的POST、GET请求以及请求中的各个字段都进行过滤检查，筛选威胁字符。
②限制查询长度：由于SQL注入过程中需要构造较长的SQL语句，因此，一些特定的程序可以使用限制用户提交的请求内容的长度来达到防御SQL注入的目的，但这种效果不太好。
③限制查询类型：限制用户请求内容中每个字段的类型，并在用户提交请求的时候进行检查，凡不符合该类型的提交方式就认为是非法请求。
④白名单法：该方法只对部分程序有效，对一些请求内容相对固定的程序，可以制定请求内容的白名单，比如：某程序接受的请求只有数字，且数字为1-100，这样可以检查程序接受的请求内容是否匹配，如果不匹配，则认为是非法请求。
⑤设置数据库权限：根据程序要求为特定的表设置特定的权限，如：某段程序对某表只需具备select权限即可，这样即使程序存在问题，恶意用户也无法对表进行update或insert等写入操作。
⑥限制目录权限：Web目录应至少遵循可写目录不可执行，可执行目录不可写的原则;在此基础上，对各目录进行必要的权限细化。