浅谈Java代码安全(三)

说完了内部一些代码安全的问题,再来谈谈外部可能会引起的代码安全问题,以前在一个老项目里用过拼接sql的方式去请求数据库:
登陆接口,要求用户输入用户名和密码:

    用户名: ' or 1=1 --   
    密 码:   

点登陆,如若没有做特殊处理,而只是一条带条件的查询语句如:
String sql=”select * from users where username=’”+userName+”’ and password=’”+password+”’ ”
那么这个非法用户就很得意的登陆进去了.(当然现在的有些语言的数据库API已经处理了这些问题)
这是为什么呢?我们来看看这条语句,将用户输入的数据替换后得到这样一条语句:
select * from users where username=” or 1=1 –’ and password=”
为了更明白些,可以将其复制到SQL分析器中,将会发现,这条语句会将数据库的数据全部读出来,为什么呢?

很简单,看到条件后面 username=” or 1=1 用户名等于 ” 或 1=1 那么这个条件一定会成功,然后后面加两个-,这意味着什么?没错,注释,它将后面的语句注释,让他们不起作用,这样就可以顺利的把数据库中的数据读取出来了。

这还是比较温柔的,如果是执行
select * from users where username=” ;DROP Database (DB Name) –’ and password=”

…….其他的您可以自己想象。。。
当然现在的框架以及编程规范越发的成熟,基本上是已经杜绝了sql注入的机会,很多时候我们都用预编译的sql去执行,或者使用参数化语句去传参,但是有些情况或者老的项目框架下还是要做到检查,举个例子:在mybatis中,或许你会要使用关键词like,in以及order by ,
在其xml里你可能不得不用到${xxx}去传参,这就给了sql注入机会了,那有解决的办法么,当然
正确的使用方法是:

 select * from user where name like concat('%', #{name}, '%')   //like

 select * from user where id in
<foreach collection="ids" item="item" open="("separator="," close=")"> //in
#{item}
</foreach>

至于order by怎么防止,我并没有找到什么好的方法,或许你得查询一下输入的参数是否在预期的参数集合中,做好入参的检查了。

至于别的安全方面问题我还没有遇到过,可能存在的比如XML注入,XSS攻击,zip bomp等特定攻击我们也应该有所了解,以做防范。

部分转载自:https://www.cnblogs.com/gpdm/p/6101968.html

发布了3 篇原创文章 · 获赞 0 · 访问量 3014
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览