SQL注入时不能用#号的原因

因为一直在纠结一个问题，为什么有些时候在做sql注入时不能用#做注释，只能拿%23做注释使用，前端代码并没有过滤，所以只能是后台的限制，询问了大佬以后，告诉我去监控一下MYSQL的语句，折腾了半天，终于搞好了。

开启日志

• 先查看mysql日志是否开启

  mysql> show variables like 'log_bin%';
  log_bin | ON 则开启

• 如果没有开启，在/etc/my.cnf中的[mysqld]下加入以下两行命令：

  log-bin=mysql-bin
  log =/tmp/mysql.log

  然后重启mysqld即可。

---

监控日志

通过以下命令来完成mysql日志的监控tail -f /tmp/mysql.log 。

[root@tutu tmp]# tail -f /tmp/mysql.log    
190222  1:08:09     4 Connect   root@localhost on 
                    4 Init DB   security
                    4 Query     SELECT * FROM users WHERE id='1' #' LIMIT 0,1
                    4 Quit
                    //这条是使用%23来注释
190222  1:08:13     5 Connect   root@localhost on 
                    5 Init DB   security
                    5 Query     SELECT * FROM users WHERE id='1' ' LIMIT 0,1
                    5 Quit
					//这条是使用#来注释

还可以使用seay数据库审计系统中的Mysql插件来进行查看日志。

---

总结

由上可以看出，从浏览器输入的#并没有发到数据库来，但是不知道为啥，有说是数据库的编码、数据字段的类型、index.php的编码等等问题，但验证过后都不是，在测试过程中总觉得是浏览器有问题，那接下来用burp试试再看看。
由此可见确实发出来的时候直接将#去掉了，不死心，继续扔到repeater里面测试，结果发现了这么一个东西。。。
于是猜想#号是不是在URL中有特殊含义的，简单去搜索了下才发现#确实是有特殊作用的，并且现在不允许出现在http请求中不允许出现#，但是记得在之前确实也可以拿#(POST方式肯定是可以的)来进行注释的阿。。。有点无语，折腾了几个小时来测试这个东西，当然也掌握到了一些新的东西。