同事都说有SQL注入风险,我非说没有
前言
现在的项目,在操作数据库的时候,我都喜欢用ORM框架,其中EF是一直以来用的比较多的;EF 的封装的确让小伙伴一心注重业务逻辑就行了,不用过多的关注操作数据库的具体细节。但是在某些场景会选择执行SQL语句,比如一些复杂的插入或报表查询等,其实不管用什么方式执行SQL语句,防止SQL注入是必须的,所以就有了下面的讨论。
正文
1. 先来个EF Core执行SQL演示
1.1 准备一个EF Core的项目
关于EF Core在项目中的使用,之前分享了一篇很详细的文章,这里就不重复说了,详细内容请看这里《跟我一起学.NetCore之EF Core 实战入门,一看就会》
1.2 执行原生SQL
前提,已经生成数据库,并且有对应的表(以下只是模拟演示,并不是真实场景):
在操作数据库时,执行如下SQL:
有很多小伙伴看到这时,应该也会怀疑这里会有SQL注入的风险,因为这里的SQL语句看上去就是一个拼接的字符串,只是用了插值运算符的形式,好像没什么特别。
1.2 打印日志查看真正执行的SQL
表面看上去的确会有风险,既然说没有,那就拿出证据证明,直接把EF执行过程的日志打印出来,看看真正执行的SQL语句是什么样子;
EF Core好像在5.0之后就提供了一个便捷的配置,可以方便的打印对应的SQL记录,所以先来开启日志打印功能:
开启日志之后,执行一下程序,看看执行的真正SQL是什么样的,控制台可以看到如下日志:
可以看到,SQL语句已经参数化了,所以是没有注入风险的。那到底是为什么呢?因为ExecuteSqlInterpolatedAsync中的SQL语句参数的类型是FormattableString,EF Core内部根据FormattableString结果,将对应的字符串生成参数化的SQL语句。
2. FormattableString有点料
为了看看FormattableString的作用,建一个简单的控制台程序,看看情况,如下:
可以看到,FormattableString中包含拼接的字符串和对应的参数,拿到这些结果,就可以构造成想要的结果了。
2.1 var使用时还是要稍微注意一下
之前一个项目,因为var的使用,线上出现一个bug,挨个看了代码感觉都没问题,而且开发和测试环境正常,但在线上就是有问题,最后通过模拟线上数据调试才搞定。大概使用如下:
之所以开发和测试环境没有问题,是没有模拟全线上环境,所以让这个bug漏掉了;对于开发来说,var用起来的确很是方便,但对于类似于上面的场景,使用具体的类型会避免一些不必要的Bug;
代码比较简单,就不提交了~~~
总结
在开发过程中,稍微一个小细节的改动,可能效果就不一样;同样,一个小细节的忽视,就可能带来一个很不好排查的Bug,所以小伙伴开发过程中,一定要注意哦!!! 关注“Code综艺圈”,和我一起学习吧。
- Php中用PDO查询Mysql来避免SQL注入风险的方法
- 职场中没有朋友,警惕你的同事(上篇)【IT圈是个什么玩意儿 7 】
- 同事就是同事,职场没有兄弟姐妹
- ASP.NET Core中的OWASP Top 10 十大风险-SQL注入
- 《澄明之境》:二十年期货交易员的经验:投资没有圣杯,控制风险,在市场阶梯式上升过程中赚钱。3星
- 使用PDO查询Mysql来避免SQL注入风险
- 如何使用PDO查询Mysql来避免SQL注入风险?ThinkPHP 3.1中的SQL注入漏洞分析!
- 昨天也没有和家里通话,把时间给了一位同事
- firefox 访问12306.cn提示有风险但没有添加例外选项
- 如何使用PDO查询Mysql来避免SQL注入风险?ThinkPHP 3.1中的SQL注入漏洞分析!
- sql注入风险和案例分析
- Php中用PDO查询Mysql来避免SQL注入风险的方法
- 浅谈SQL注入风险 - 一个Login拿下Server
- 同事说:奇迹是我们没有看惯的自然现象,自然现象是我们看惯了的奇迹。
- Spring MVC通过拦截器处理sql注入、跨站XSS攻击风险(jeecg)
- SQL注入风险小例
- 如果你发现了自己的学习模式,愿意学并且能坚持,我觉得没什么能阻挡你征服软件世界的脚步(对于开发人员来讲,最大的风险是:在职业规划上没有延续性地乱跳槽。时刻要牢记在心的:培养自己的稀缺性),安晓辉大神的感悟 good
- 【职场没有朋友,警惕你的同事】下篇
- 使用PDO查询Mysql来避免SQL注入风险
- 同事使用xib约束,但是好久没有使用xib,忘得差不多了,所以巩固下,附上链接