【系统设计】 WEB网络安全

1   网络安全学习记录
1.1   访问控制
控制访问入口。
1.1.1   【网络隔离】用户不能通过业务系统入口访问的后台管理系统
目的：为了防止用户攻破管理系统，而管理系统权限都比较搞，从而形成对系统的危险。
手段：
1. 将业务系统和管理系统从网络层面就进行分割
2. SaaS类系统严格保证租户间的隔离，独立部署的网络不打通，共享的虚拟CPU，内存，磁盘等进行逻辑隔离

1.1.2 【主机间访问】防火墙IPTables中的IP限制不能写0.0.0.0

1.1.3 【主机内】对外端口都需要在白名单中，且需要单独罗列出来
目的：控制和管理对外暴露的端口

1.1.4 【对外接口】所有自定义接口都需要有认证，标准协议如SSH，MySQL等有认证的除外
目的：控制访问者权限
对外接口包括：
1. 自定义Tcp，http等接口，包括：外部用户访问和内部服务间互相调用
2. 中间件，系统服务的接口

1.2 漏洞扫描
扫描操作系统，软件，第三方中间件等组件中的漏洞。

1.2.1 【工具】发布前必须使用工具对漏洞进行扫描，高危漏洞必须解决
常见的测试方法 https://blog.csdn.net/qq_34942306/article/details/125537199
主机漏洞扫描组件：
secVas: 自动化的web漏洞扫面工具
openvas:开放性漏洞评估系统，核心部件是一个服务器，一套望楼漏洞测试程序。可以检测远程程序和应用程序的安全问题。
Nexpose：漏洞扫描工具，参考：https://zhuanlan.zhihu.com/p/693721635
RSAS：绿盟科技远程安全评估系统，自动诊断漏洞

web漏洞扫描：
secScan: 自动化主机漏洞扫描工具
Burpsuite: web渗透扫描工具
Appscan: web项目的安全测试工具，扫描网站所有url
AWVS: web漏洞扫描工具

1.2.2 【怎么修复】推荐使用官方推荐方案修复，若官方暂时没有方案，则可自定义修复
为什么推荐用官方推荐方案是因为：这样沟通成本最低，只要说这时官方推荐方案即可，无需再解释。

1.3   服务安全
1.3.1   每一个访问请求都必须认证，例外接口或者css，js，图标文件等需要特殊评审
1.3.2   认证必须由后端完成
1.3.3   SessionID需要保证随机，验证后需修改

1.4 系统开发过程
开发，发布，部署

1.4.1 禁止后门入口
场景：为系统开发一些管理接口。没有提供给客户，但开发了解。

1.4.2 禁止硬编码密码等认证秘钥
新建客户需要随机产生一个密码，而非固定一个密码。
管理员账号也不允许固定在代码中写死一个密码

1.4.3 产品中提供的账号都需要提供给用户
场景：开个不清楚的接口，然后硬编码一个用户和密码，视图用别人不清楚作为安全的屏障。这种是不可行的。

1.4.4 所有的密码都需要有地方可修改

1.4.5 软件中不能有木马病毒，且也不能设计类似功能
产品中恶意恶搞客户，比如：将关闭按钮搞的特别小，用户不小心就会打开很多页面，把自己搞的跟病毒一样

1.4.6 解释成本高，有恶搞嫌疑的组件和功能就不要用了
1.功能：调试工具或者脚本，能被你用来看系统，也能被黑客恶搞，解释起来挺麻烦。一般情况下就删除得了，自己加上自己慢慢解释去
2. 爬虫功能谨慎提供，容易有法律问题

1.4.7 清理代码中公网IP地址，URL，邮箱地址
原因：没法解释，仿佛自己悄悄发送数据一样
如果是页面配置，或者直接给用户资料中有涉及到就可以。否则就需要清理。

1.4.8 操作系统的安全框架轻易不要破坏
比如：修改Linux的SSHD代码

1.4.9 最小化权限运行代码，禁止root类用户启动进程

1.5 加密
1.5.1 不要自定义加密算法
别自不量力，即使很牛逼，解释起来也很麻烦。

1.5.2 算法中随机数必需是严格随机的
Java中推荐使用SecureRandom，禁止使用Random。如下是生成随机字符串代码示例：
public static void main(String[] args) throws NoSuchAlgorithmException {
byte[] bytes = new byte[48];
SecureRandom.getInstanceStrong().nextBytes(bytes);
StringBuffer stringBuffer = new StringBuffer();
for (byte temp : bytes) {
stringBuffer.append(String.format("%02x", temp));
}
System.out.println(stringBuffer.toString());
}

1.5.3 用标准的加密算法，明确不安全的不要用
参考：https://www.cnblogs.com/bigleft/p/18010533

1.5.4 秘钥必须加密存储，最根上的秘钥可以硬编码
用户的秘钥需要加密存储，不能明文存储
但对用户密码加密的秘钥是可以的，否则死锁了，没法解啦

1.6   敏感数据保护
敏感数据的识别，存储，传输过程进行保证。
1.7   敏感数据在系统设计时识别
1.7.1   密码秘钥不能明文存储和传输，需要加密
1.7.2   如果不需要还原的用不可还原的加密方法
1.7.3   个人敏感数据需要严格控制访问权限
1.7.4   日志中不能打印敏感数据
日志文件和日志DB中都不能打印
需要保证异常信息是否包含敏感信息

1.8   系统运维管理
1.8.1   【密码】密码复杂度
1.8.2   【密码】密码错误提示不能太明确防止猜测
1.8.3   【密码】防止爆破
1.8.4   【密码】软件页面密码不能密文展示
1.8.5   【密码】密码不支持复制粘贴
1.8.6   【密码】修改密码需要验证旧密码，两次确认新密码
1.8.7   【密码】密码支持重置密码，重置密码系统自动生成，且需要在第一次登录的时候修改

1.8.8 【日志】需要记录用户所有的操作
包括但不限于：
1. 登录，注销
2. 增加用户，权限，修改权限等
3. 系统配置修改
4. 重要资源的操作CRUD
所有日志都需要记录在文件中，重要日志需要记录到DB中。

1.8.9 【日志】需记录：时间，谁，浏览器&IP，对谁，干什么了，结果是啥
1.8.10 【日志】禁止修改和删除日志，严格控制日志操作权限

1.8.11 【权限】新建的用户默认不给权限，或者最小的权限

1.9 隐私保护
1.9.1 【个人数据】若出于问题定位目的需要个人数据的，可以获取，但需要进行匿名化处理
1. 个人数据的获取：需要严格控制权限，日志记录
2. 采集的个人数据需要明确给用户说明
3. 提前说明法律风险
4. 个人数据采集范围应该最小化
5. 如果要将国外个人数据传出国界，需要经过处理才可以，目的是达到任何手段都没法到达还原定位到个人

1.9.2   【个人数据的收集和使用】收集的目的需要明确，并需要保护
1.9.3   【个人数据清理】需要有删除个人数据的功能
1.9.4   【个人位置】收集用户的手机定位需要通知，并提供清理权限的功能
1.9.5   【隐私声明】什么时候提供；什么时候修改
只要去收集用户数据就需要提供
收集主体，以及收集数据范围变化也需要修改，然后重新同意
1.9.6   【单独同意】在隐私声明同意的基础上，如果涉及：敏感数据，数据出境，公开个人数据，使用人发生变化，目的发生变化都需要用户重新同意
1.9.7   【数据保存】数据保存日期尽量最小化，需要跟隐私声明保持一致

1.10   其他
1.10.1   【软件安装包】安装给用户的软件需要保证是自己出的，比如签名或者hash认证等，防止软件包被篡改而无法自证清白
1.10.2   【依赖包】直接依赖包不能有过期或者漏洞的
1.10.3   高危服务不可对外暴露
端口为默认端口
Ftp：20/21，
ssh/Sftp：22，
Telnet：23，
Tftp：69，
Rpc：135，
SQL:1433-1435，
Oracle:1521-1530，
Rdp：3389，
MySQL：3306

2 附录