首先我们要注意的点就是:
- 不要相信任何客户端传递的参数
- Http Header中的信息不可信
- 请求也可能并非是用户请求
- 不能依赖前端js对于数据的验证
案例:
1.参数被篡改的例子。
对于下面这一条url,是用来查看订单详情的,对于这样的url需要注意什么?需要注意参数被篡改
http://www.domain.com/orderdetail?id=23
正常情况下,一个用户查看的订单只能是属于自己的,但是如果手动修改订单的id,如果服务器不验证是否有权限的话,就会导致当前用户可以看到其他用户的订单,风险很大。
2.自增id引发的问题
我们一般做商城的时候,如果商品的主键是通过自增的形式来形成的,那么对于一些爬虫软件来说,想要爬取商品信息可以大大降低了难度,直接自增id就可以获取商品信息了。但是对于UUID这样的商品主键,爬虫是很难获取到的
3.参数恶意修改参数,导致异常
一个项目中存在一个收入分成的部分,分成分为两部分,服务员和商户。由前端传递过来服务员的比例,去计算出商户的比例。这个前端传递过来的比例,如果我们不经过验证的话,可能会被恶意修改,导致收入分配异常,
4.cookie的值被修改
cookie中的值也是可以被修改的,为了防止修改cookie的值来冒充登录,所以我们一般在cookie存的数据应该是加密过的,或者是随机的,带有有效期的这种数据。
5.Header不可信
假设我们现在设计一个投票系统,最简单的解决恶意投票的方法就是要求用户注册,但是注册会降低参与的人数,需求修改成不进行注册就能进行投票。那怎么进行身份验证呢?其实不依靠注册来进行身份验证是很难的,Header中的信息都是有可能会被恶意篡改的,我们只能说增加篡改的难度,但是不靠注册这种是很难完全解决的。
6.防止传递恶意信息到服务器
对于上面这种情况,我们根据活动是否开启,并且订单金额达到一定金额来进行打折,但是存在一个问题,我们打折的字段是封装在order中的,如果前端传递过来的属性包含discount这个属性,那么也就会被封装进去,这时候就出现问题了。
7.防止恶意刷验证码
我们一般的验证码可能就是4位数,最多的可能会有6位数,这样短的验证码,如果恶意暴力破解,要不了多少次请求就能得到正常的验证码,所以对于验证码,一般我们都会设置失效,尝试几次之后就失效。
8.sql安全
sql注入就不说了,当某些时候我们不得不进行sql拼接的时候需要注意。
某些原生的jdbc不支持占位符的地方我们必须要进行sql拼接,比如在数据库分表的时候,2016表示是2016年的工资,select * from 2016_salary,如果我们使用预编译,其使用原生的JDBC在数据库表名这个地方是不支持预编译的,我们就需要使用sql拼接。
拼接sql时,对于单引号等特殊字符需要转移,如果传递过来的sql中包含字段名,表明,统计函数等,一定要限制范围
例如:
"select id," + requet.getParam('col') + "from user"
对于这样的sql,查询字段是传递过来的,一定要注意,万一传递的字段是密码字段的名称,那岂不是密码都查出来了