㈠ sql注入攻击及其防御技术研究
推荐你去看 sql注入天书
㈡ 计算机论文摘要翻译，SQL注入方面的，谢谢了，不要在线翻译软件的！！！好的我还可以加分！
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应该是这样的
select * from accounts where name='此处是用户输入的文本';
那么再看看我们是不是可以改成这样：
select * from accounts where name ='';select * from accounts where 1='1';
这期间，用户只要输入 ';select * from accounts where 1='1 这样的文本，你的整个账号表就都返回给他了。当然，这只是一个简单的实例，具体注入的话，还需要复杂一点的过程。因为他首先要了解你的表结构，select * from sysobjects等等，不过这也都不是问题。
现在明白了么？
㈣ 试解释 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注入代码，致使本次操作无效！"
不能输入
*
%
这2个符号
请删除
㈥ 轻松理解什么是 SQL 注入
所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。
举个简单的例子：
从理论上说，一个验证用户名和密码的功能，会有如下的SQL语句：
String sql = "select * from user_table where username=
' "+userName+" ' and password=' "+password+" '";
然后在这个语句的username=”后面注入 or 1=1 用户名等于 ” 或1=1 这个条件，上面的SQL语句变成：
SELECT * FROM user_table WHERE username=
'’or 1 = 1 -- and password='’
那么不用输入用户名和密码，就可以登陆了。
㈦ php注入与sql注入之间的区别
个人感觉没有什么本质的区别，因为都是通过对数据库的最终操作来完成的。区别可能就是表现形式方法不一样吧。
㈧ sql 注入是什么
SQL注入是一种注入攻击，可以执行恶意SQL语句。它通过将任意SQL代码插入数据库查询，使攻击者能够完全控制Web应用程序后面的数据库服务器。攻击者可以使用SQL注入漏洞绕过应用程序安全措施;可以绕过网页或者Web应用程序的身份验证和授权，并检索整个SQL数据库的内容;还可以使用SQL注入来添加，修改和删除数据库中的记录。
SQL注入漏洞可能会影响使用SQL数据库的任何网站或Web应用程序。犯罪分子可能会利用它来未经授权访问用户的敏感数据：客户信息，个人数据，商业机密，知识产权等。虽然最古老，但非常流行，也是最危险的Web应用程序漏洞之一。
㈨ 部分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注入初级(合天网安实验室)
㈩ SQL注入的特点与危害分别有哪些
1、广泛性：任何一个基于SQL语言的数据库都可能被攻击，很多开发人员在编写Web应用程序时未对从输入参数、Web表单、Cookie等接收到的值进行规范性验证和检测，通常会出现SQL注入漏洞。
2、隐蔽性：SQL注入语句一般都嵌入在普通的HTPP请求中，很难与正常语句区分开，所以当前许多防火墙都无法识别予以警告，而且SQL注入变种极多，攻击者可以调整攻击的参数，所以使用传统的方法防御SQL注入效果非常不理想。
3、危害大：攻击者可以通过SQL注入获取到服务器的库名、表名、字段名，从而获取到整个服务器中的数据，对网站用户的数据安全有极大的威胁。攻击者也可以通过获取到的数据，得到后台管理员的密码，然后对网页页面进行恶意篡改。这样不仅对数据库信息安全造成严重威胁，对整个数据库系统安全也有很大的影响。
4、操作方便：互联网上有很多SQL注入工具，简单易学、攻击过程简单，不需要专业的知识也可以自如运用。