什么是sql注入,怎么防止注入

SQL注入攻击是通过 *** 作输入来修改SQL语句，用以达到执行代码对WEB服务器进行攻击的方法。
简单的说就是在post/getweb表单、输入域名或页面请求的查询字符串中插入SQL命令，最终使web服务器执行恶意命令的过程。
可以通过一个例子简单说明SQL注入攻击。假设某网站页面显示时URL为>网站虽然防SQL注入 只是加了一段防止输入 ‘；and select等等sql语句的代码。
不一定他加了这个代码就可以真正达到防止SQL注入的目的。
cookies注入，某些情况下，就是根据漏洞 跳过了他的防注入代码来实现注入。
如果你要渗透测试，给你个软件。百度搜索WVS，扫他一把，看他还有什么漏洞，根据漏洞实施渗透测试就可以了

SQL注入属于注入式攻击，这种攻击是因为在项目中没有将代码与数据隔离，在读取数据的时候，错误地将数据作为代码的一部分执行而导致的。
如何处理SQL注入情况三个方面：
1、过滤用户输入参数中的特殊字符，降低风险;
2、禁止通过字符串拼接sql语句，严格使用参数绑定来传入参数;
3、合理使用数据库框架提供的机制。

下面我要谈到一些Sqlserver新的Bug 虽然本人经过长时间的努力 当然也有点幸运的成分在内 才得以发现 不敢一个人独享 拿出来请大家鉴别

．关于Openrowset和Opendatasource

可能这个技巧早有人已经会了 就是利用openrowset发送本地命令 通常我们的用法是（包括MSDN的列子）如下

select from openrowset( sqloledb myserver ; sa ; select from table )

可见（即使从字面意义上看)openrowset只是作为一个快捷的远程数据库访问 它必须跟在select后面 也就是说需要返回一个recordset

那么我们能不能利用它调用XP_cmdshell呢？答案是肯定的！

select from openrowset( sqloledb server ; sa ; set fmtonly off

exec master dbo XP_cmdshel l dir c:\ )

必须加上setfmtonlyoff用来屏蔽默认的只返回列信息的设置 这样XP_cmdshell返回的output集合就会提交给前面的select显示 如果采用默认设置 会返回空集合导致select出错 命令也就无法执行了

那么如果我们要调用sp_addlogin呢 他不会像XP_cmdshell返回任何集合的 我们就不能再依靠fmtonly设置了 可以如下 *** 作

select from openrowset( sqloledb server ; sa ; select OK!

exec master dbo sp_addlogin Hectic )

这样 命令至少会返回select OK! 的集合 你的机器商会显示OK! 同时对方的数据库内也会增加一个Hectic的账号 也就是说 我们利用select OK! 的返回集合欺骗了本地的select请求 是命令能够正常执行 通理sp_addsrvrolemember和opendatasource也可以如此 *** 作！至于这个方法真正的用处 大家慢慢想吧

．关于Msdasql两次请求的问题

不知道大家有没有试过用msdasql连接远程数据库 当然这个api必须是sqlserver的管理员才可以调用 那么如下

select from openrowset( msdasql driver={sql server};server=server;address=server ;uid=sa;pwd=;database=master;neork=dbmssocn s elect from table select from table )

当table 和table 的字段数目不相同时 你会发现对方的sqlserver崩溃了 连本地连接都会失败 而系统资源占用一切正常 用pskill杀死 sqlserver进程后 如果不重启机器 sqlserver要么无法正常启动 要么时常出现非法 *** 作 我也只是碰巧找到这个bug的 具体原因我还没有摸透 而且很奇怪的是这个现象只出现在msdasql上 sqloledb就没有这个问题 看来问题不是在于请求集合数目和返回集合数目不匹配上 应该还是msdasql本身的问题 具体原因 大家一起慢慢研究吧

．可怕的后门

以前在网上看到有人说在 sqlserver上留后门可以通过添加triger jobs或改写sp_addlogin和sp_addsrvrolemember做到 这些方法当然可行 但是很容易会被发现 不知道大家有没有想过sqloledb的本地连接映射 呵呵 比如你在对方的sqlserver上用sqlserver的管理员账号执行如下的命令

select from openrowset( sqloledb trusted_connection=yes;data source=Hectic set fmtonly off exec master XP_cmdshell dir c:\ )

这样在对方的sqlserver上建立了一个名为Hectic的本地连接映射 只要sqlserver不重启 这个映射会一直存在下去 至少我现在还不知道如何发现别人放置的连接映射 好了 以上的命令运行过后 你会发现哪怕是sqlserver没有任何权限的guest用户 运行以上这条命令也一样能通过！而且权限是 localsystem！（默认安装）呵呵！这个方法可以用来在以被入侵过获得管理员权限的sqlserver上留下一个后门了 以上的方法在 sqlserver sqlserver SP 上通过！

另外还有一个猜测 不知道大家有没有注意过windows默认附带的两个dsn 一个是localserver一个是msqi 这两个在建立的时候是本地管理员账号连接sqlserver的 如果对方的 sqlserver是通过自定义的power user启动 那么sa的权限就和power user一样 很难有所大作为 但是我们通过如下的命令

select from openrowset

( msdasql dsn=locaserver;trusted_connection=yes set fmtonly off execmaster XP_cmdshell dir c:\ )

应该可以利用localserver的管理员账号连接本地sqlserver然后再以这个账号的权限执行本地命令了 这是后我想应该能突破sa那个power user权限了 现在的问题是sqloledb无法调用dsn连接 而msdasql非管理员不让调用 所以我现在正在寻找guest调用msdasql 的方法

lishixinzhi/Article/program/SQL/201311/16324

关于SQL注入攻击与防范

随着网络的普及，关系数据库的广泛应用，网络安全越来越重要。下面是我为大家搜索整理了关于SQL注入攻击与防范，欢迎参考阅读，希望对大家有所帮助。想了解更多相关信息请持续关注我们应届毕业生培训网!

一、 SQL注入攻击

简言之，SQL注入是应用程序开发人员未预期地把SQL代码传入到应用程序的过程。它由于应用程序的糟糕设计而成为可能，并且只有那些直接使用用户提供的值构建SQL语句的应用程序才会受影响。

例如：用户输入客户ID后，GridView显示客户的全部行记录。在一个更加真实的案例中，用户还要输入密码之类的验证信息，或者根据前面的登录页面得到用户ID，可能还会有一些用户输入关键信息的文本框，如订单的日期范围或产品名称。问题在于命令是如何被执行的。在这个示例中，SQL语句通过字符串构造技术动态创建。文本框txtID的值被直接复制到字符串中。下面是代码：

在这个示例中，攻击者可以篡改SQL语句。通常，攻击的第一个目标是得到错误信息。如果错误没有被恰当处理，底层的信息就会暴露给攻击者。这些信息可用于进一步攻击。

例如，想象一下在文本一下在文本框中输入下面的字符串会发生什么

ALFKI'OR '1'='1

再看看因此生成的完整SQL语句：

这条语句将返回所有的订单记录，即便那些订单不是由ALFDI创建，因为对每一行而言而有信1=1总是true。这样产生的后果是没有显示当前用户特定信息，却向攻击者显示了全部资料，如果屏幕上显示的是敏感信息，如社会保险号，生日或xyk资料，就会带来严重的问题。事实上，这些简单的SQL注入往往是困扰那些大型电子商务公司的麻烦。一般而言，攻击点不在于文本框而在于查询字符串(可被用于向数据库传送值，如列表页向详细信息页面传送唯一标识符)。

还可以进行更复杂的攻击。例如，攻击者可以使用两个连接号(--)注释掉SQL语句的剩余部分。这样的攻击只限于SQL Server，不过对于其他类型的数据库也有等效的办法，如MySql使用(#)号，Oracle使用(;)号。另外攻击者还可以执行含有任意SQL语句的批处理命令。对于SQL Server提供程序，攻击者只需在新命令前加上分号(;)。攻击者可以采用这样的方式删除其他表的内容，甚至调用SQL Server的系统存储过程xp_cmdshell在命令执行任意的程序。

下面是攻击者在文本框中输入的，它的攻击目标是删除Customers表的全部行。

LUNCHUN’;DELETEFROM Customers--

二、防范

如何预防SQL注入攻击呢需要记住几点。首先，使用TextBoxMaxLength属性防止用户输入过长的字符是一个好办法。因为它们不够长，也就减少了贴入大量脚本的可能性。其次，要使用ASPNET验证控件锁定错误的数据(如文本、空格、数值中的特殊字符)。另外，要限制错误信息给出的提示。捕获到数据库异常时，只显示一些通用的信息(如“数据源错误”)而不是显示ExceptionMessage属性中的信息，它可能暴露了系统攻击点。

更为重要的是，一定要小心去除特殊字符。比如，可以将单引号替换为两个单引号，这样它们就不会和SQL语句的分隔符混淆：

string ID=txtIDText()Replace(“’”，”’’”);

当然，如果文本确实需要包含单引号，这样做就引入了其他麻烦。另外，某些SQL注入攻击还是可行的。替换单引号可以防止用户提前结束一个字符串，然而，如果动态构建含有数值的SQL语句，SQL注入攻击又有发挥的空间了。这个漏洞常被(这是很危险的)忽视。更好的解决办法是使用参数化的命令或使用存储过程执行转义以防止SQL注入攻击。

另一个好建议是限制用于访问数据库的账号的权限。这样该账号将没有权限访问其他数据库或执行扩展的存储过程。不过这样并不能解决SQL脚本注入的问题，因为用于连接数据库的进程几乎总是需要比任意单个用户更大的权限。通过限制权限，可以预防删除表的攻击，但不能阻止攻击者偷看别人的信息

三、POST注入攻击

精明的用户可能会知道还有另外一个Web控件攻击的潜在途径。虽然参数化的命令防止了SQL注入攻击，但它们不能阻止攻击者向回发到服务器的数据添加恶意的值。如果不检查这些值，就使得攻击者可以提交本来不可能存在的控件值。

例如，假设你有一个显示当前用户订单的列表。狡诈的攻击者可能保存该页面的一个本地副本，修改HTML内容向列表添加更多的项目，然后选择某个“假”的项目。如果攻击成功，攻击者就能够看到其他用户订单，这显然是一个问题。幸好，ASPNET使用一个很少被提及的叫做“事件验证”的特性来防止这种攻击。事件验证检查回发到服务器的数据并验证其中值的合法性。例如，如果回发的数据表明用户选择了一个没有意义的数据(因为它在控件中并不存在)，ASPNET就产生一个错误并停止处理。可以在Page指令中设置EnableEventValidation特性为false来禁用事件验证。创建使用客户端脚本动态改变内容的页面时，需要执行这一步。不过，此时在使用这些值之前要注意检查潜在的POST注入攻击。

;

---