软件业务功能---安全设计

安全设计目的

• 软件在恶意攻击下能够正确地完成其功能

产生安全场景

• 意外行为
• 恶意行为

场景1：管理员或普通人员删除数据操作

例如：以下（修复待验证安全问题）删除数据请求，通过参数codes的值，来删除数据。如果没有验证登陆的用户是否有权限删除codes，那么通过遍历codes值，可以删光所有codes数据。这种问题在一般系统应该比较常见。后续修改成本都很高，有些可能修复不了，涉及框架、业务设计都需要修改。应在设计时就考虑：

1. 验证用户合法性、权限
2. 防止用户误操作，如删除有提示
3. 防止恶意操作，如删除3条数据以上，需要输入验证码才能删除成功（需要跟踪业务需求来设计）

GET /companyCard/cardMaintain/delete.do?codes=EY85TE HTTP/1.1
Host: 192.168.210.119:8688
Accept: /
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36
Referer: http://192.168.210.119:8688/global/login/index.do
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
Cookie: JSESSIONID=9A396A304544241E140F07F293F78A5D
Connection: close

场景2：修改帐号密码设计不合理，即使没有手机号也成功修改了密码。

通过修改手机号，便短信发到我的手机号上，我就可以修改用户的密码。即这种场景前端的数据是不可靠的，必须通过用户信息到数据库查用户的手机号，再由服务调第三方短信接口才能防止此类问题。如果app存在这样的问题，手机丢了或手机离开你的视线，被人修改，app绑定银行卡的钱是非常不安全的。

 

 

调用第三方的接口，从安全设计上都应该是从服务端调第三方，前端只做数据采集和展示，如订单支付等，都是基于后台的数据而不是基于前端数据提交。

如下图测试帐号，之前绑定是别人邮箱，在没有别人邮箱和手机号的情况下，成功变成绑定我的邮箱。