安全相关笔记

安全漏洞和攻击事件无法避免，首先要提升自身产品安全性、健壮性，其次要建立网络安全漏洞和
攻击事件的快速响应能力，及时消除风险，支撑客户构建安全韧性的网络

安全定义

安全：是系统对恶意威胁的防护能力，可能的威胁包括但不限于未授权访问，使用、泄漏、破坏、修改、毁灭;
防护目标是保持信息的机密性、完整性和可用性
(华为)网络安全理解：指在法律合规下保护产品、解决方案和服务的可用性、完整性、机密性、可追溯性和抗攻击性，
以及保护其所承载的客户或用户的通信内容、个人数据及隐私、客观信息流动

正确说法：
1、网络安全是基于风险管理，是对潜在的安全威胁的防护
2、没有绝对安全的技术、产品和系统
3、网络安全没有银弹Sliver Bullet，没有任何一个技术或产品够100%解决网络安全问题，网络安全是一个持续攻防的过程

错误说法：
1、没有被攻破的产品和系统是安全的
2、没有出安全问题的产品和系统是安全的
3、安全问题是安全体系的责任

• 脆弱性：一种软件、硬件或过程缺陷
• 威胁：信息或系统意外事件的潜在原因，
• 威胁因素：利用脆弱点的实体被称为威胁因素
• 风险：威胁因素利用脆弱性进行攻击的可能性
• 安全漏洞：在硬件、软件、协议的具体实现或系统安全策略上存在缺陷
  

产品声明周期安全开发流程：
需求分析 -> 安全设计 -> 安全开发 -> 安全测试 -> 发布 -> 安全响应
研发过程：在产品开发生命周期中，嵌入安全开发最佳工程实践，确保产品的安全可信

采用先进的安全技术和产品：
数据安全：数据加密(存储、传输)、数据库加密、视频加密、DLP、加密搜索、隐私数据保护
访问控制：IAM(身份识别与访问管理)、CA管理、堡垒机
网络安全：FW/GNFW、IDS/IPS、Anti-DDoS、VPN
平台安全：安全芯片(TPM)、安全启动、可信启动、系统加固、安全存储等
安全技术&规范：以安全硬件建立信任基础，采用最新、最先进的安全技术和产品，构建纵深防御系统

遵从标准、合格认证：
安全标准：ISO/IEC、ITU、3GPP、NIST、TC260、ENISA、TCG
安全认证：CC、FIPS、ISO、PCI-DSS、CSA STAR

密码算法分类

• 加密系统的保密性只应建立在对秘钥的保密上，不应取决于加密算法的保密
• 密码算法的安全程度：是对破解密码算法或系统所需要的工作的一个数值度量，用来衡量密码算法或密码系统的安全性，由算法本身和使用密码长度决定
• 密钥管理应满足：口令、默认设置的可见字符等，均不能直接作为密钥使用；密钥用途需单一化；密钥在本地存储时需提供机密性保护，应加密存储；不再使用的密钥，应当立即销毁

安全技术&规范

原则

1、开放设计原则

设计不应该是密码，开放设计更安全
a、安全性不应依赖机制设计和实现的保密性和攻击者的无知，应当使产品的设计经受充分的检验
b、使用业界成熟的算法和协议
c、注意：密码算法须遵循公开设计，密钥却不能随意泄漏公开，密钥禁止硬编码

2、失败-默认安全原则

访问决策应当基于允许，而不是拒绝。默认情况下是不允许访问的，保护机制仅用来识别允许访问的情况
a、失败安全：任何一个复杂系统应该有一个处理功能失效后的应急安全机制，另外对错误消息和日志要小心，防止信息泄露
b、默认安全：系统在初始状态下，默认配置是安全的，通过使用最少的系统和服务来提供最大的安全性

3、权限分离原则

权限分离的目的主要有两个：
a、防利益冲突、个别权力滥用
b、对某一重要权限分解为多个权限，让需要保护的对象更难被非法获取，从而也更安全

4、最小权限原则

系统的每一个用户、每一个程序，都应该使用最小且必须的权限集来完成工作
a、确保应用程序使用最低的权限运行
b、对系统中各用户运行各类程序，如数据库、WEB服务器等，要注意最小权限的账户运行、连接，不能是系统最高权限的账号
c、新建账号时默认赋给最小权限的角色

5、经济适用原则

保持系统的设计和代码尽可能简单、紧凑
a、软件设计愈复杂，代码中出现bug的几率越高，如果设计尽可能精巧，出现问题的几率也小
b、删除不需要的冗余代码和功能模块，保留该代码只会增加系统的攻击面
c、设计可以重复使用的组件减少冗余代码

6、最小公共化原则

尽量避免提供多个对象共享同一资源的场景，对资源访问的共享数量和使用应尽可能最小化
a、共享对象提供了信息流和无意的相互作用的潜在危险通道，尽量避免提供多个对象共享同一资源的场景
b、如果一个或多个对象不满共享机制提供的服务，可不用共享机制，以避免被其他对象的bug间接攻击到

7、完全仲裁原则

完全仲裁原则要求，对于每个对象的每次访问都必须经过安全检查审核
a、当主体试图访问客体的时候，系统每次都会校验主体是否拥有该权限
b、尽可能有资源所有者做出访问控制的决定
c、特别注意缓存的使用和检查。无法保证每次访问缓存的信息，都没有被黑客篡改过，都是安全的

8、心理可承受原则

安全机制可能为用户增加额外的负担，但这种负担必须是最小的而且是合理的
a、安全机制应该尽可能对系统用户友好，方便他们对系统的使用和理解
b、如果配置方法过于复杂繁琐，系统管理员可能无意配置了一个错误选项，反而让系统变得不安全
c、该原则一般与人机交互、UCD界面相关

9、纵深防御原则

纵深防御是一个综合型性很高的防御原则，一般要求系统架构师综合运用其他的各类安全设计原则，采用多点、多重的
安全校验机制，高屋建瓴的从系统架构层面来关注整个系统级的安全防御机制，而不能只依赖单一安全机制

风险及应对方法

1、缓冲区溢出带来的风险及应对

攻击描述：利用缓冲区溢出漏洞所进行的攻击行动，缓冲区溢出的是一种针对操作系统、应用软件中广泛存在的攻击方式，攻击可以导致获取shell权限或让程序运行失败、系统关机、重新启动等后果
攻击场景：与缓冲区交互的编程语言中，容易遭受缓冲区溢出攻击
消减措施：

• 产品开发设计时，选用开发语言时，需考虑缓冲区溢出攻击的风险，JAVA风险小
• 选用C/C++开发语言，可通过使用安全函数、启用编译选项降低缓冲区溢出攻击的安全操作系统加固，如启用Linux系统的ASLR保护
• 进程低权限运行，防止溢出后直接获取root权限

2、命令注入带来的风险及应对

攻击描述：利用命令注入漏洞所进行的攻击行动，命令注入漏洞是一种针对应用系统中广泛存在的攻击方式，攻击可执行任意shell命令，如删除/变更文件、添加账号、关机/重启等后果
攻击场景：系统中存在直接或间接调用操作系统shell/CMD的接口，且参数由外部可以控制
命令注入主要攻击途径：
a、应用主动调用系统命令或shell脚本完成特定功能时导致的命令注入
b、通过语言解释器(如OGNL)或eval函数注入代码，调用对应语言的系统调用函数调用系统命令
c、通过SQL注入调用数据库的系统存储过程
消减措施：

• C/C++开发语言中，建议Linux/Unix下使用exec系列函数来避免命令注入
• 进程低权限运行，防止命令注入成功后直接获取root权限

3、SQL注入带来的风险及应对

攻击描述：程序中如果使用了未经校验的外部输入来拼接SQL语句，攻击者可通过构造恶意输入来改变原本的SQL逻辑或执行额外的SQL语句，如拖库，获取管理员、获取WebShell权限等
攻击场景：系统中存在数据库的场景
SQL注入问题主要来源：
a、执行外部拼接的SQL语句
b、执行外部传入的整条SQL语句
c、在配置文件中的SQL语句没有使用预编译方式占位符
d、校验函数有缺陷或占位符使用错误
消减措施：

• 要使用预编译，并正确使用；无法使用预编译的场景，优先考虑白名单判断
• 权限最小化：数据库进程权限必须为第权限运行，禁止使用root启动。数据库账号需要使用低权限，禁止使用SA、root、DBA权限这类管理权限
• Web解决方案中使用WAF可以拦截绝大部分的SQL攻击

4、跨站脚本(XSS)带来的风险及应对

攻击描述：攻击者利用网站程序对用户输入过滤不足，输入可以显示在页面上对其他用户造成影响的HTML代码，从而盗取用户资料、利用用户身份进行某种动作或对访问者进行病毒侵害的一种攻击方式
攻击场景：系统存在外部输入数据的功能或调用接口；对外部输入数据会显示到页面上并且未做合法性校验
XSS注入主要攻击途径：
a、通过HTTP请求对输入参数注入脚本，利用HTML协议多样性，使用不同的编码方式构造复杂的脚本，绕过防火墙、参数校验，在页面展现，执行输入数据
b、对数据来源于数据库、文件系统等不可信数据源，直接在页面展现，执行输入数据
c、设计上就允许输入HTML标签，脚步(富文本框)，内容校验被绕过，导致最后在页面展现，执行恶意脚本数据
消减措施：

• 不要信任任何来自外部的参数，外部参数包括请求头，请求体，cookie、流对象，文件等，任何来自外部的参数都有可能被篡改，所有都需要做防XSS处理
• 对于XSS防御可采用输入校验和输出编码两种方式，但为了达到所见既得的目的，建议根据输出点的类型不同，采用不同的转义函数对不可信参数进行输出编码