关于Sql注入的那些事

    登陆注册应该是每一个网站的必做的业务,但是在选择使用Django中的ORM还是说执行原生的Sql语句不同的人应该会有不同的建议,有经验的开发人员都喜欢原生的sql语句,因为相对于ORM来说,执行效率高,可以随意地按照自己的思想去查询自己想要的数据,还有一点,就是看上去NB一点,不服不行

    对于sql注入来说,最开始没有一点理解,我认为那是网络安全应该去管理的,但最后自己莫名的摊上事了,说大白话吧,当用户没有注册但是他点击登录的时候,提交上的用户名以及密码是你应该去sql语句去拼接之后去你自己的数据库User表中去查询看一下有没有这个用户名和密码,或者说去判断你用户表中是不是这个人和这个密码,ok,麻烦来了,这就是重点,就一般人而言回不会给你捣乱,但是对于一些攻击者或者说开发来说随意输入,万一用户名输入一个 “or 1 = 1” ,密码随意或者不输入,完蛋了,明明没有这个人没有这个密码但是一看他自己登上去了

    正常的用户登录sql语句

  

select * from User where name = "led" and password = 123

    恶意攻击登录sql语句

    

select * from User where name="or 1 = 1 #and password = 123

    解释一下,恶意攻击的sql语句一定会登陆上,只因为我们在执行sql语句进行身份校验的时候等待的是外边用户输入的信息,我们没有对他进行一个严格的检验,而 # 这个符合在sql语句中代表注释,不会被执行,也就是说在其真正执行的·sql语句不过就是 select * from User where name = “or 1 = 1” ,1=1?√,1=1 True  or这个链接词表示两个检验前面是真后边不管是不是真都是真,So,这就是sql注入

    现在我们知道了sql语句注入,但是我们怎么来避免它呢?用ORM?其实现在网上有不少各自的说法都有,有的说ORM就可以避免这个问题,但是也有人说只要在外部输入的信息我们进行拼接都会有可能出现这种问题,最保险的办法还是说不管是使用sql还是说ORM我们在对于外部信息传入我们在拼接前我们对其进行一个严格的检验,例如正则表达式,不符合我的规则你给我滚一边去

猜你喜欢

转载自www.cnblogs.com/lzqrkn/p/10750009.html
今日推荐