Web开发安全相关的一些注意点

首先我们要注意的点就是:

  1. 不要相信任何客户端传递的参数
  2. Http Header中的信息不可信
  3. 请求也可能并非是用户请求 
  4. 不能依赖前端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,查询字段是传递过来的,一定要注意,万一传递的字段是密码字段的名称,那岂不是密码都查出来了

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值