Heim  >  Artikel  >  Datenbank  >  SQL查询结果集对防注入的影响分析

SQL查询结果集对防注入的影响分析

WBOY
WBOYOriginal
2016-06-07 17:47:061023Durchsuche

一:逻辑错误

  简单的例子是1=1 1=2这两个,1=1与1=2页面不同的原理是什么?以$sql = "select * from news where id=$_GET[id]"为例。

  select * from news where id=1 and 1=2产生的结果集为NULL,然后程序取值得时候,就会去出空值,无法显示。当然有的程序发现SQL执行结果集为空,就立即跳转,效果就不显鸟。值得注意的是,有的如Oracle Postgresql的在结果集为空情况下会再页面上表现字符型null字样,这算是个特点。如果使用or条件,比如

  select * from news where id=1 or 1=1

  和and 1=2得结果正好相反,他的结果集十分庞大。如果SQL语句如此,再加上程序是循环读取结果集(一些编程上的陋习)那么会取出所有结果,结果可能运行很慢,在数据量巨大的Oracle上容易出现。这个例子会出现什么呢,一般程序取出结果集中的第一条结果,那么很可能已经不是id=1的那条新闻了,这就是由些小菜奇怪有时候or 1=1页面会发生变化的原因。

  归根到底,都是结果集不同造成的,灵活掌握是关键,这并非单纯的经验问题。

  二:语法错误

  语法错误时比较熟悉的,比如对于sql server,PgSQL,Sybase的注入错误提示都很重要,因为利用它的特性来获取信息很快速。语法错误造成的结果可能是SQL错误而中断脚本执行,但是脚本或服务器设置屏蔽错误的情况下,程序得到继续执行,但是结果集不存在,连NULL都算不上,反馈给攻击者的很可能就是结果集为空的情况,其实这是脚本的处理结果。当然Oracle PgSQL表现null。

  三:运行错误不用说了,典型的就是利用MySQL注入benchmark让脚本运行超时得到物理路径,以及利用超时来获得不同的表征进行盲注入。

  四:逻辑错误和语法错误的结合。

  当表征极不明显的时候,利用类似iff这样的函数进行正确与否的区分有时候会成救命稻草。因为语法错误和逻辑错误的表征大多数情况都会有不同。

  iff(1=1,1,'no')这个会产生结果1 注意是数字,而iff(1=2,1,'no')这个会产生'no' 是字符。那么

  id=1 and 1=iff(1=1,1'no')正确是必然成立的,而id=1 and 1=iff(1=2,1,'no')会因为类型不同发生语法错误。不过可惜的是似乎支持iff函数的数据库不多,呵呵。

  现在讲结果集在注入中的利用原理。

  一:从'or''='开始

  这是学习SQL注入的初级课程,登陆漏洞。我简略从SQL结果集上分析。

  $sql = "select top 1 * from admin where username='$username' and password=md5('$password')";

  显而易见,'or''='的加入使SQL语句返回了一条记录,这才使验证通过。

  二:再看现在的验证中的SQL

  $sql = "select top 1 * from admin where username='$username'";

  结果集不为空才根据抽取的记录集中的密码值与用户提交的密码MD5值进行比对来进行验证。这样,你突然发现'or''='的计策失败鸟,但是后台明明有注入,这就是验证方法造成的。跟进这个验证过程,'or''='的确产生了一个结果集(admin表中的第一行记录)但是遗憾的事,后来的密码比对没法通过,验证无法成功。

  思路很简单,网上有案例,我重在原理,利用union来产生想要的结果集。比如'and(1=2)union select top 1 username,'123456得md5值',id from admin where username='admin

  这样产生了admin的记录信息,但是记录集中的密码那个

位置的值被替换成了123456的md5值,这样,使用admin 123456通过验证并且继承他的权利。

 

  更有甚者全部用'xxx'的方法来盲狙,这就很“过分”鸟。不过在sql2000 sybase这些严格要求类型匹配的数据库来说,这样不能撼动“管理员登陆”的,因为执行时发生了语法错误,结果集为NULL。另外以前ewebeditor注入漏洞来上传马也是这个union操作结果集来达到目的的经典案例。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn