浅谈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
"ids" item="item" open="("separator="," close=")"> //in
#{item}

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

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

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