总结后端开发常见安全问题及应对⽅案
前⾔
本⽂主要梳理到公司参与团队后端开发2年多来，总结开发过的项⽬中遇到的各种安全问题及应对⽅案。
⽬前我们后端团队使⽤的技术主要还是Sprin在这⾥插⼊图⽚描述
gBoot + Mysql + Redis这⼀套 ，暂未涉及到SpringBoot Cloud，后⾯内容主要围绕⽬前团队使⽤的技术框架来讲解的。
mysql下载不了怎么办
平时⼤家可能更多注重业务层⾯的开发（CRUD），然后实现产品的需求就⾏了，但是却忽略了产品上线后的各种安全问题带来的影响。
下⾯总结了⼀些过去发⽣过的（出现频率⾼，影响严重的）开发上的问题及带来的严重影响:
安全问题影响
操作系统、SpringBoot及相关服务jar包等版本漏洞攻击者通过版本漏洞拿到root权限进⼊服务器为所欲为！中招挖矿病毒，这个⼤家都有遇到过吧！
被ddos攻击服务器持续⽆法访问，影响正常⽤户的使⽤
弱⼝令密码出现在登录类的接⼝、以及redis、mysql等服务的连接信息上短信接⼝、下载⽂件消耗类的接⼝被盗刷这个出现⽐较多，短信业务被消耗，下载流量持续被别⼈消耗，带来的是公司钱的损失！！
充值业务问题这个就⽐较严重了，涉及到钱的业务开发都要慎重！慎重！再慎重！
服务器带宽占满等问题同被攻击的常见
22端⼝开放暴⼒破解，重要的端⼝应该加上⽩名单连接
⼀款互联⽹产品开发出来上线后，既然是存在于互联⽹上的东西，如果设计之初没有考虑开发上的安全设计规范和服务器安全防御⽅案，那必然是不安全的，记住这点！ 不管⾃研还是模仿同⾏竞品，在上线后，使⽤你开发产品的⽤户多了，说明就越来越有价值了，关注度也越来越⾼后，就极有可能就会被别⼈攻击、破解等⾏为，特别是当⽼板说这个产品你也给我做出来⼀个的时候…同⾏出现竞争者，⼤家都想吃这块⾁，说不定别⼈就会来搞你，某天周末你正在和朋友在外⾯嗨⽪，突然接到⽼板电话说服务器宕机赶紧看下,⼀看有⼈在ddos攻击…扯远了，扯远了！ 总之，你不知道你写的程序哪⾥突然蹦出个安全漏洞，如果被攻击者发现，就会有安全问题发⽣的风险！ ⽐如前不久出现⼀个shiro
的安全问题，我们有⼀个测试项⽬⽤的⼀个基于SpringBoot+Shiro的旧版本框架，该框架没有升级shiro最新版，安全部门的同事测试就发现通过此漏洞拿到了服务器root权限，其漏洞请点击查看 转发链接: 开发者也不必担⼼在安全设计⽅⾯花太多时间，过去2年我和团队在公司开发的后端项⽬经历了很多安全问题（吃了不少亏换来的经验），所以有了今天的总结，按照所讲的内容⼀⼀对应到平⽇的开发⼯作⾥，就能⼀定程度上减少⽣产事故的发⽣！ 所以本⽂主要⽬的是避免⼤家开发新的项⽬重犯以前的错误，把过去常规的⼀些处理⽅案整理出来，作为⼀个平⽇的开发规范，养成⼤家在开发⽅⾯安全的意识，希望⼤家在平时开发都应该对每⼀个接⼝都有考虑⼀定的安全处理，对⾃⼰每⼀⾏代码负责！ 啰嗦了这么多，还是有必要给⼤家说清楚情况，接下来就是正⽂，下⾯的内容主要是分享经验及解决问题⽅案，涉及到技术的不多，部分⽅案以链接⽅式转载，具体实施根据各⾃公司的情况来。 对与能看到这⾥的⼩伙伴来说，表⽰感谢，如果后⾯有能帮助到你的地⽅，是我莫⼤的荣幸，有错误或者建议也请联系本⼈，及时沟通⼀起进步！ 接下来主要从2个⽅⾯来规范后端开发安全:
1 开发上的安全设计规范
1.1 接⼝安全设计:
（1）所有的开放接⼝建议都应该有鉴权处理
前提：对于XX后台管理系统，后台的相关接⼝除了登录注册等接⼝，肯定是需要登陆鉴权后才能访问
的，这⾥主要针对于⼀些提供给第三⽅使⽤的开放接⼝，直接公开就能访问的接⼝需要做的鉴权！
就⽐如，⼤家应该对登录、短信接⼝、⽀付宝⽀付等其他第三⽅服务有对接过吧，没有对接过的⾃⾏百度看下别⼈写的对接⽂档，是不是接⼝的参数都有什么apiId, apiSecret ,MD5加密校验啥的，对接多了就清楚明⽩了，使⽤别⼈的技术也要去思考为什么要这么设计嘛，⼀是区分渠道（谁来请求的）,⼆就是对应的安全处理。
⽹上有很多优秀的博主发过⽅案，这⾥转发推荐:
转载链接1：
转载链接2：
最好就是公司有⼀个统⼀的鉴权中⼼服务，所有的接⼝鉴权都⾛这个服务，⽬前我们是单个项⽬按照上⾯的⽅式写的鉴权，我正在做这个事情，等后⾯我们搭建好了⼀个这样的统⼀鉴权中⼼发出来总结给⼤家分享⼀下！
（2）接⼝请求都应该有⼀套限流处理⽅案
不知道⼤家平⽇开发的接⼝有没有做并发处理？特别是⼀些新增，更新业务的接⼝，说不定你写的接⼝⼀个简单的并发测试就能看出⼀些问题。
我们设计的接⼝并不需要像淘宝、京东那样亿级⾼并发，做好⼀个符合实际公司业务接⼝性能需求就⾏了（根据公司业务来定），要对症下药。
这⾥说的限流其实和并发相关了，对于⾼并发的技术讨论不在这⾥展开讨论，这个东西太⼤，我们直说场景和处理⽅案：
简单来说就是正常请求量放⼤10倍甚⾄更多后，你的系统如何应对？
换句话说，正常测试的情况是你单台服务器最⾼承受300的并发量，如果突然某个时间并发量3000，6000，1万 ⼜如何应对？
这⾥举个简单例⼦便于理解：
假如⼀个登录接⼝，测试在指定X核XG X带宽 环境下，300并发量同时登录没问题的，突然3000并发，服务器就宕机了。
单台物理机的性能指标总会有⼀个阈值，但为了保证服务的稳定性，我们可以怎么做呢：接⼝限流是⼀个⽅案。
在应对突然增⾼的访问，我们可以拒绝掉部分请求，保证服务器的稳定性，这个其实和设计⼀个抢购
秒杀程序差不多的原理。对于恶意的请求量，也是同样的道理，但也是⼀把双刃剑，缺点是正常⽤户的请求也会被过滤掉。
接⼝限流的对象:
IP
接⼝路径
进⼀步可以拓展到某个⽤户，某个业务对象（任务）限制…
⽬前我们项⽬中在⽤的2个的⽅案:
1. 通过SpringBoot的 +redis，通过注解的⽅式实现：
2. 我们使⽤了nginx代理，nginx层⾯也可以去做限流⽅案:
如果你有更好的⽅案可以评论推荐⼀下！
（3）关于充值模块的接⼝设计
⼀个例⼦： 谈到充值业务的开发，我就想起以前遇到⼀个初级程序员同事（真的不是我）犯过的⼀个典型错： 业务功能是：后台有个充值按钮，选择单个⽤户后点击充值按钮，输⼊⾦额就可以给该⽤户增加⾦额，同时本⼈减少相应⾦额。 看似⼀个很简单的功能，其实就是⼀个银⾏取钱的例⼦，假设我的余额是200块，正常流程就是：我取了100块，剩下100块没⽑病吧，取钱的时候就有⼀个接⼝处理业务逻辑，结果这个接⼝没做任何处理，没加锁，没事务，造成的后果就是，我在0.11111 毫秒内，狂点了100次取钱，然后我钞票机给我了1000块，我的余额还是100块！要是银⾏真这么设计早就倒闭了！ 就是这个场景，发⽣在实际公司业务中，被别⼈撸了⽺⽑，好在有⽇志操作记录把这个⽤户相关操作记录全部给他退回了，最后修复了这个充值接⼝的bug，加锁，加事务，限流（不能被狂点） 那他也受到了相应的惩罚，罚了款！ 这⾥再举例⼀个反例，不要这么设计：⽐如 /api/recharge?userId=100&amount=100, 请求访问后就可以给⽤户id为100的⽤户充值100块，相信⼤家不会这么去设计接⼝，真这么设计怕是要着锤的，这么看也太不专业了，我觉得以后⾯试⼈可以增加这个充值接⼝⽅案设计题，真有⼈这么来搞就可以下⼀个了。 总结： 回归充值业务的设计，作为负责这块写代码的你可得打起⼗⼆分精神，特别是设计到钱的问题，头脑应该马上有⼀个安全意识，结合上⾯（1）（2）点的接⼝安全设计⽅案，我们也不说啥⾼⼤上的设计，该加锁的加，加事务，即使你的代码冗余，也要安全 > 性能当然我不希望你做团队写代码最笨的⼈，要不断去优化⾃⼰的代码，去学习别⼈优秀的⽀付架构设计⽅案！（这个话也是对⾃⼰说的） 此外充值⼀定要有对应的⽇志记录，出现问题也是辅助分析的地⽅，写到这⾥，我觉得⾃⼰也应该提升下这块业务的开发⽅法并总结出来，学习使⼈进步！
1.2 使⽤第三⽅服务(接⼝)注意事项:
（1）短信接⼝
⼤家在公司做项⽬，如果涉及到短信业务，⽂件上传，这种场景，你是如何设计的？
我先说下最原始的版本1：
XX系统对外有⼀个⼿机注册页⾯，正常⽤户注册需要请求接⼝发送⼿机验证码，假如这个发送验证码接⼝张三是这么设计的:
/api/getVerificationCodeByPhone?phone=1234567890,
张三也知道，对⼿机号码做了格式校验，就没其他过多的设计了，看到这⾥你就可能就笑了，突然有⼀天，客户反馈充值充不上了，⽼板赶紧打电话让正在度假的张三看看怎么回事，张三看见服务器的短信接⼝报错余额不⾜了， 结果⼀看⽇志，⼀⼤堆获取验证码的接⼝⽇志，⼀想，肯定是别⼈盗刷接⼝了。
那对于短信接⼝设计:
参照上述 1.1 接⼝安全设计
增加发送验证码
不仅验证⼿机号码格式，⽽且验证数据库⾥⾯有这个⼿机号才会发送
短信接⼝⽅案只是⼀个例⼦，其他类似的需要充值才能使⽤的接⼝，⽐如
⾕歌翻译接⼝
百度地图API
邮箱发送验证接⼝
等等业务中会⽤到的第三⽅接⼝也都应该做类似的处理
（2）对象存储
这⾥说的对象存储指的是使⽤的 或者 或者其他平台的对象存储，各平台使⽤⽅式都差不多，⽤过的⼩伙伴应该清楚，没⽤过的⼩伙伴可以理解为⼀个独⽴的⽂件服务器，和你部署的SpringBoot 服务器隔离开，⽂件的上传下载都⾛这个独⽴的⽂件服务器，不要⼀台服务器集中了所有服务（nginx，springboot，redis，mysql，⽂件存储…）
为什么要这么设计呢？这⾥我推荐⼀篇好朋友写的博客：
⽬前我们项⽬的架构类似这样⼦（nginx 集部署）：
因为公司项⽬的业务会有⼤量的⽂件上传下载，所有服务器都上了云，对象存储这个使⽤也很简单，有对应的各种语⾔的SDK接⼊，我们可以通过API 上传和下载⽂件。
这⾥直接说下使⽤中出现的问题：
问题1：秘钥保存在客户端 最开始有个项⽬，最⾼权限的秘钥保存在客户端上，这⽆疑是最危险的做法，⽽且客户端已经对外公开，有⼀定逆向能⼒的程序员通过反编译APK即可拿到这个秘钥，也等于拿到了我们⽂件服务器所有权限， 可以通过秘钥遍历获取所有⽂件，或者新增删除之类的操作，⾮常危险，随后发现这个问题⽴即禁⽤这个key，重新讨论设计⽂件存储⽅案。 问题2：桶的⽂件下载链接公开，被别⼈盗刷流量 创建对象存储桶的时候有⼀个选项，桶策略：公开还是私有，以下图华为云为例
我们创建⼀个桶后如果是公开的，那么上传的⽂件下载链接可以直接访问，这⾥存在⼀个风险就是华为云的下载流量是按使⽤计费的，如果有对外公开的⽂件，恶意攻击者拿到公开⽂件下载链接就可以
写个循环下载脚本，恶意消耗你的流量，账号上⾯的余额很快被吃完。
围绕这个风险，我们说下做法：
1. 秘钥的保存
秘钥是应该保存在服务端的，并且要加密保存！
绝对不能保存到客户端！
2. 桶应该都私有的，对外上传下载都要鉴权和频率限制
登录⽤户，限制每个⽤户⼀定时间的下载次数
IP, 限制某个ip的下载次数，更严格⼀点限制登录过后的ip才能下载及限制下载次数
业务介质，同上
等等
总之，前⾯围绕的设计思路核⼼都是鉴权 和限制请求频率，要学会灵活运⽤。
1.3开发框架安全注意事项:
（1）版本问题
后端开发⼯作中，我们常⽤技术有： SpringBoot、redis、mysql、shiro、nginx等，这⾥不⼀⼀列举，在⽂本开头有提到⼀个 shiro安全问题的例⼦，就是⼀个典型，得益与我们有优秀的安全⼯程师，他们可以分析你所开的应⽤、使⽤的框架及版本有什么问题，如果你们没有专门的安全部门，也可以⾃⼰⽹上看下相关框架版本漏洞，这⾥整理⼏个会经常公布互联⽹安全漏洞的⽹站：
1. 国家信息安全漏洞共享平台：
2. 阿⾥云或者华为云官⽹也会不定时公布⼀些漏洞:
3. 各个服务官⽹，像什么jdk、gitlab、redis、nginx 官⽹都会有⾃⼰的漏洞修复信息
如果你现在使⽤的框架版本出现了对应的问题，就应该及时升级，同时升级注意各个组件的兼容性，避免出现了问题再来处理，造成了严重后果，就后悔莫及了！
（2）项⽬配置⽂件信息保存
这⾥主要说明⼀下⽐如springboot 的yml配置⽂件信息，像⽐如连接数据库，连接redis的账号密码建议应该加密保存。
其次公司都应该有⾃⼰内⽹的git服务器吧，千万不要把公司项⽬上传到公⽹公开访问，否则你⾯临法律⽅⾯的危险！
相关加密⽅案请参照: ，建议使⽤其⽂档描述的4.2.1 命令⾏加密（推荐）⽅案。
（3）秘钥的保存
这⾥的秘钥指的是⽐如对象存储的秘钥，以及系统接⼝加解密的公钥之类的重要信息。
⽬前我们项⽬接⼝有做参数加密，服务端基于内存保存秘钥，具体⽅案设计到项⽬细节这⾥不展开描述，⼤家如果好的⽅案保存⼀些秘钥可以分享⼀下！
1.4 弱⼝令密码
1. mysql 、redis 的密码
2. 你的服务器登录密码
3. 后台管理系统的密码
2 服务器使⽤及安全防御⽅案
（1）服务器端⼝添加⽩名单
所有云服务重要端⼝都应该加上⽩名单，特别是22端⼝，只能是你所在办公IP才能访问！
（2）DDOS攻击等外部流量攻击
了解DDOS
什么是ddos攻击，⽹上有很多资料，这⾥转载⼀篇，后端开发都应该了解⼀下，点击了解:
简述就是：⼤规模流量（⼏百G或者更⾼）涌⼊服务器，导致服务器处理不过来，只要攻击不停⽌，服务器就⼀直处于"⽆响应状态"，部署的web服务也⽆法正常访问，直接影响项⽬！
公司的项⽬只要是部署⽣产环境上线后，基本上都遭遇了ddos攻击（太难了）。
⾼防服务器
最简单、最有效的⽅法就是购买并部署⾼防服务器应对，缺点是需要加钱。这个时候不是去想着怎么优化代码了，需要从外部去解决，市⾯上有很多⾼防服务器⼚家，这⾥不做⼴告推荐，有被攻击的⼩伙伴不知道怎么做可以我沟通⼀下。
⾼防服务器就等于服务器的⼀个盾牌，所有的请求先到⾼防服务器，由⾼防服务器解析是好是坏，再转发的我们的源站服务器来。
使⽤⾼防后注意的问题：
配置⾼防后要注意回源IP的问题，如果你的业务有跟IP有关，需要配置相应的参数才能拿到
当然，配置了⾼防服务器不代表就100%⽆敌安全了，⼀⼭更⽐⼀⼭⾼，攻击流量⼤于你的防御流量你也防不住，需要不断去优化策略应对。
其他攻击
转载链接:
XSS (Cross-Site Scripting)，跨站脚本攻击
CSRF(Cross Site Request Forgery)，即跨站请求伪造，是⼀种常见的Web攻击
SQL注⼊
除了ddos攻击,⽇常的后台接⼝服务器也会有其他不安全因素，如果使⽤公司提供的⼀套基础框架模版（已经包含处理了上述问题风险）去开发，就不⽤担⼼这些问题的发⽣，毕竟我们最终还是得专注于业务开发呀！
（3）使⽤域名，不要暴露你的源服务器IP
结合第（2）点被ddos攻击的情况，原因是因为你的服务器ip暴露了，攻击者直接攻击源服务器，加上⾼防后，使⽤域名的⽅式，不要暴露你的源服务器IP。
总结：项⽬正式上线前，应该提前考虑好被ddos攻击的风险及应对措施，提前准备好⾼防服务器部署，保证后续服务器的稳定运⾏。
3 安全环境下进⾏开发
（1）使⽤内⽹搭建服务
这⾥主要针对于初创的中⼩公司，开发环境各⽅⾯都不太规范，⽐如使⽤ 外⽹Gitlab，码云 或者GitHub来管理研发项⽬，⼤公司应该都有完善的安全的研发环境，像⽐如华为，阿⾥，腾讯的朋友，特别是华为的员⼯，听说基于内⽹开发，百度还得⽤⼿机这种情况⼤家有没有听说过呢？
为什么要⽤内⽹搭建服务呢？前⾯也说了服务会有各种漏洞，会有被⼊侵风险，⽐如Gitlab官⽅就随时在更新，我们团队⽬前就是内⽹搭建的Gitlab，代码是整个研发团队、公司最重要的资产；
⾸先项⽬代码在公⽹放着本⾝就是⾮常不安全的!
如果因为公⽹原因或者服务漏洞，发⽣代码泄露，这个⽆论是对个⼈和公司，都是灾难级的损失!
内⽹环境下⼀定程度上减少了被泄露的风险，但是管理者也要规范团队每个开发者的⽇常⾏为规范（⼈为因素）。
下⾯列出内⽹搭建的服务及使⽤地⽅：
内⽹搭建使⽤范围
Gitlab管理项⽬代码仓库
禅道项⽬管理
（2）使⽤⾮windows操作系统进⾏开发
由于Windows操作系统其普及性和软件适配性（相⽐Linux），⼤多数中⼩公司研发团队可能都会基于
Windows进⾏开发，但是Windows 太"成熟"了，开发成本低，⼀不⼩⼼点错、下错东西，打开就是各种病毒、⽊马、⼴告，电脑中毒不说，同时⼜间接影响内⽹环境。
所以⽬前我们团队使⽤的操作系统是Ubuntu20.04，⼀样的有图形化界⾯，实践1年多了，前后端开发都不会受影响，和Windows⼀样，强烈建议⼤家还在⽤Windows系统进⾏开发的⼩伙伴换成 ubuntu或者mac，当然mac需要苹果笔记本，成本⽐较⾼。
PS: 写完后发现可以衍⽣出的系列⽂档，后续我将持续更新…
1. ⼀个安全的登录接⼝设计⽅案（待开始）
2. 企业内部鉴权中⼼模块开发实例（待开始）
3. 对象存储模块开发实例（待开始）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。