这个流程的问题：
- 用户和收银模块之间，把金额作为参数传递给收银模块，并且没有做二次金额校验
- 购物模块和用户之间，也是把金额当做参数进行传递
- 购物模块和收银模块之间的交互，只是简单确认是否付款，没有确认付款金额
改进点：用户和购物模块、收银模块以订单号为交互参数，而不是金额
身份认证 （账号安全）
防撞库
黑客拿到用户在社区网站的口令后，尝试使用社区的用户名和口令去购物网站上进行碰撞，如果可以碰撞上，则黑客就有该用户的所有权了。
防撞库的主要手段是前端慢速加盐散列（参见本书第一部分，由于黑客需要执行同样的慢速加盐散列运算，导致撞库时间成本比较高），以及频率限制、总量限制、IP锁定、验证码等技术手段。
防弱口令尝试
在撞库测试无果之后，黑客还可以继续利用人们最常使用的弱口令（如123456），和不同的用户名（来自网络上已泄露的用户名）进行搭配，比如先尝试Alice:123456，接着尝试Bob:123456、Carol:123456等用户和口令，看哪个用户名能否登录成功就记录下来，就可以绕过防撞库的机制。
对来自同一设备的登录次数进行限制，来自同一设备的登录尝试，如果出错达到一定次数，弹出验证码（CAPTCHA）或锁定一定时长. 可以通过 IP+UserAgent 来判定为同一个设备。
防账号数据库泄露
如果没有对账号数据库加以特殊的保护，数据库被拖走，就可能导致全部用户账号泄露。为了达到这个目的，需要假设即使数据库被拖走了，黑客也无法利用。
那就是对数据库中的敏感信息进行加盐加密单向散列等措施
防垃圾账号
垃圾账号一般是使用工具软件批量注册的，被黑产用来薅羊毛、刷单、刷好评等，获取不当利益。
在账号注册过程中，需要将垃圾账号这个场景考虑进去，借助实名认证、邮件认证、手机认证、验证码等手段，防止批量注册。
防账号找回逻辑缺陷
2016年，北京手机用户许先生收到端口为“1065×××”的短信提示，说他订阅了某财经杂志的手机报，花费40元。许先生以为被运营商摊派业务，在退订的过程中回复了一个6位数的校验码之后，自己支付宝、三张银行卡里的所有资金被盗。
？？
授权与访问控制
无论是基于属性、角色、任务授权、动态授权从安全意义上，默认权限越小越好（甚至没有任何权限），满足基本的需要即可。
访问控制就是要保持用户输入的参数可能不是在正常范围下，如何保证数据安全，参数检验方式：
- 边界检查：对参数的范围，和长度进行校验
- 防止 SQL注入：后台不要使用拼接 SQL 的方式
- 防跨站脚本（XSS）:对内容进行转义
- 防止跨站请求伪造(CSRF): 请求中添加一些隐藏参数
- 防跨目录路径操纵：路径参数校验 ../
- 防服务器端请求伪造(SSRF)：指定可以访问的域名，或者修改
审计日志
添加用户操作日志，方便于回溯，优化。
资产保护
无论是对静态数据还是动态数据，为了数据的整个周期上的安全，最直接的方式就是对数据进行加密，加密存储，加密传输，脱敏展示。
B2B交易（保证数据传输安全）
在B2B交易对接的过程中，传输通道是由被请求方提供的HTTPS所保障的。那是因为 HTTPS 比 HTTP 多了 SSL 协议，SSL 协议在交换数据之前就会先进行握手协议，交换数字证书，协商对称加密密钥、加密方式等等。
具体的内容可以查看Wireshark 分析 SSL 协议
在某些极端的情况下，如被黑客窃取了私钥、内部员工离职时带走了私钥等，就有可能发生甲方意愿之外的操作。为了更加安全，推荐采用更强的访问控制，将上述传输过程从公开的互联网搬迁到专用的点对点网络，如专线、VPN等。
网络资源保护：如何防 DDOS、CC 攻击
网页静态化
采用SPA（Single Page Application，单页应用）技术及框架（Angular 5/6/7、React、Vue.js等）构建的网站前端，除了会与后端动态交互（使用JSON Restful API接口）之外，基本也算是静态页面。
缓存机制
如果是后端生成网页，应考虑使用缓存技术将动态网页转换成接近静态网页的效果。这一点，可通过添加缓存机制来实现，借助Memcached、Redis等缓存组件，避免频繁地读取数据库。
消息队列，异步机制
针对消耗资源比较多的功能或接口，可采取分布式异步消息队列等处理机制，相比同步处理可以提高并发能力。
负载均衡
用户被分流到不同的入口，就近访问，从而提升服务能力，且大部分GET请求可以不用回源（回源，就是CDN访问源服务器），因此并不会造成源服务器拥塞。
熔断、降级、依赖隔离
可以利用 Spring Cloud Hystrix 组件，来控制请求。
