**
从题目inget的解决到注释符#和–的区别及用法
**
一起来看一道攻防世界的web题:inget
题目:
使用本题的核心工具——翻译器(bushi):
根据提示,明确了方向:sql注入
ID传参方式一般是GET(如果不是就用hackbar给url传参)
接着尝试一下符号是否闭合:
猜测闭合,接着尝试万能钥匙:
成功获得flag。
题目本身简单,但做对且看过其他大佬的wp后,我们不妨问自己一下:为什么这么构造?别的构造行不行?
首先是为什么这么构造?
答:对用户提交的表单进行验证时,网站需要查询数据库。而查询数据库就是在执行SQL语句。用户登录时,不妨假定后台执行的数据库查询操作(SQL语句)是:Select ID From users Where ID=’用户名’ 。又由于网站后台在进行数据库查询的时候没有对单引号进行过滤,当输入万能密码1’or’1时,执行的SQL语句为:Select ID From users Where ID=’1’or’1’。由于SQL语句中逻辑运算符具有优先级,=优先于or,因此,该SQL语句在后台解析时,被分成两句:Select ID From users Where ID=’1’和’1’,两句bool值进行逻辑or运算,恒为TRUE。SQL语句的查询结果为TRUE,就意味着认证成功,也可以登录到系统中。
接着是别的构造行不行?
答:了解了以上构造的原理后其实很容易知道还有无数种可行的构造,只要让整个语句的bool值为TRUE便能成功绕过。
其次就是看到一些wp中在句末加了注释符来消掉后台sql语句的’的影响(不消肯定会多个后单引号对嘛qwq),我们之前的方法是在or后面加 '(前引号)和它凑对。
说半天不如举个栗子:
可以看到id=1’ or 1 - - +的构造也是成立的。
既然想到这里了,那么不妨再多问自己一句:用#来注释可不可以?
答案是否定的。这是因为url中#是用来指导浏览器动作的(如锚点),对服务器端完全无用,所以http请求不包括#。所以只要将#改成url编码23%就可以了。
可能在看到- - +后有人想说sql的注释语法不应该是- -吗?为什么会多个+?
了解原理后便知道了:- -无法使用的原因是它和后面的单引号会连在一起,导致无法形成有效的spl语句,而这个+号在加到语句中后就会变成空格,将- -与后面的语句分隔开,从而达到注释的目的。
那么问题又来了,可不可以把+号直接写成空格?(byd这编者怎么这么多问题 =_=)
答:显然这是不行的,因为url并不读空格。这里就又轮到url编码出场了,将空格替换成20%后发现也可以成功。
至此关于这道题我能想到的问题就结束了(完结撒花AWA),剩下就是编者的废话了。