常见漏洞的防御措施整理

0x01 注入攻击

风险说明

在以下情况下，应用程序易受攻击：

应用程序不会验证、过滤或清洗用户提供的数据。

动态查询或无上下文感知转义的非参数化调用直接在解释器中使用。

恶意数据在对象关系映射（ORM）搜索参数中用于提取额外的敏感记录。

恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据。

一些更常见的注入包括：SQL、 NoSQL、 OS命令、 对象关系映射 （ORM） 、 LDAP和表达式 语言 （EL） 或对象图导航库 （OGNL） 注入。这一概念在所有解析器中都是相同的。源代码审查是 检测应用程序是否易受注入攻击的最佳方法 。强烈鼓励针对所有参数 、 标题 、 URL、 cookies 、 JSON、 SOAP和XML数据输入的自动测试。组织可以在CI/CD管道中引入静态 （SAST） 、 动态 （DAST） 和交互式 （IAST） 应用程序安全测试工具， 以在产品部署之前识别引入的注入缺陷

预防措施

防止注入需要将数据与命令和查询分开：

推荐的选择是使用安全的API， 这样可以避免完全使用解释器、 提供参数化接口或迁移到对象关系 映射工具 （ORM） 。注意：即使参数化， 如果PL/SQL或T-SQL将查询和数据连接起来， 或者使用 EXECUTE IMMEDIATE或exec （） 执行恶意数据， 则存储过程仍然可以引入SQL注入。

使用肯定 （positive） 或 “白名单”服务器端输入验证。这并不是一种完美的防御， 因为许多应用 程序需要特殊字符， 例如移动应用程序中的文本区域或API。

对于任何残余的动态查询， 请使用该解释器的特定转义语法转义特殊字符。注意：SQL结构 （如表 名、 列名等） 无法转义， 因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。

在查询中使用LIMIT和其他SQL控件， 以防止在SQL注入的情况下大量披露记录。

0x02 文件上传漏洞

系统运行时的防御

1、文件上传的目录设置为不可执行。只要wb容器无法解析该目录下面的文件，即使攻击者上传了脚本文件，服务器本身也不会受到影响。

2、判断文件类型。在判断文件类型时，可以结合使用ME下yp、后缀检查等方式。在文件类型检查中，强烈推荐白名单方式，黑名单的方式已经无数次被证明是不可靠的。此外，对于图片的处理，可以使用压缩函数或者res立e函数，在处理图片的同时破坏图片中可能包含的HTML代码。

3、使用随机数改写文件名和文件路径。文件上传如果要执行代码，则需要用户能够访问到这个文件。在某些环境中，用户能上传，但不能访问。如果应用了随机数改写了文件名和路径，将极大地增加攻击的成本。再来就是像shel.php.rar.rar和crossdomain.xml这种文件，将因为重命名而无法攻击。

4、单独设置文件服务器的域名。由于浏览器同源策略的关系，一系列客户端攻击将失效，比如上传crossdomain.xml、上传包含Javascript的XSS利用等问题将得到解决。

5、使用安全设备防御。文件上传攻击的本质就是将恶意文件或者脚本上传到服务器，专业的安全设备防御，此类漏洞主要是通过对漏洞的上传利用行为和恶意文件的上传过程进行检测。恶意文件千变万化，隐藏手法也不断推陈出新，对普通的系统管理员来说可以通过部署安全设备来帮助防御。

系统开发阶段的防御

对文件上传漏洞来说，最好能在客户端和服务器端对用户上传的文件名和文件路径等项目分别进行严格的检查。客户端的检查虽然对技术较好的攻击者来说可以借助工具绕过，但是这也可以阻挡一些基本的试探。

服务器端的检查最好使用白名单过滤的方法，这样能防止大小写等方式的绕过，同时还需对%00截断符进行检测，对HTTP包头的content-type也和上传文件的大小也需要进行检查。

系统维护阶段

1、系统上线后运维人员应有较强的安全意思，积极使用多个安全检测工具对系统进行安全扫描，及时发现潜在漏洞并修复。

2、定时查看系统日志，Wb服务器日志以发现入侵痕迹。定时关注系统所使用到的第三方插件的更新情况，如有新版本发布建议及时更新，如果第三方插件被爆有安全漏洞更应立即进行修补。

3、对于整个网站都是使用的开源代码或者使用网上的框架搭建的网站来说，尤其要注意漏洞的自查和软件版本及补丁的更新，上传功能非必选可以直接删除。除对系统自身的维护外，服务器应进行合理配置，非必选一般的目录都应去掉执行权限，上传目录可配置为只读。

0x03 认证会话管理

1、预防固定会话

一般来说，解决固定会话是相当容易的。最基本的建议就是：一旦用户登录成功以后，重写SessionlD。

2、保护你的会话令牌

保护Cookie

Cookie有两个很重要的属性：secure和HttpOnly,设置好这两个属性对于保护你的Cookie至关重要。

提供ogoutI功能

上面介绍的是系统自动按照设定的时间使会话过期，一个好的应用程序应该提供一个功能，即用户可以手动地使当前会话过期，这就是我们在几乎所有网站上都看到的logout:按钮。

3、多因素认证

对于很多重要的系统来说，如果只有密码作为唯一的认证手段，从安全上看会略显不足。因此为了增强安全性，大多数网上银行和网上支付平台都会采用双因素认证或多因素认证。

支付宝提供的多种认证方式

除了支付密码外，手机动态口令、数字证书、支付盾、第三方证书等都可用于用户认证。

这些不同的认证手机可以互相结合，使得认证的过程更加安全。

4、身份认证设计完善

密码长度和复杂性策略

密码认证作为当前最流行的身份验证方式，在安全方面最值得考虑的因素就是密码的长度。一个强度高的密码使得人工猜测或者暴力破解密码的难度增加。

实现一个安全的密码恢复策略

一个应用会提供密码恢复功能。

重要的操作应通过HTTPS传输

对于重要的操作，如登录、修改密码等，一定要通过HTTPS进行传输。实现一个安全的密码恢复策略

认证错误信息以及账户锁定

不正确的认证错误信息可能会导致字典攻击或者暴力破解，所以我们要尽可能地给出一个很普遍的错误信息。比如：登录失败，用户名或密码错误。

0x04 访问控制

风险说明

访问控制强制实施策略，使用户无法在其预期权限之外进行操作。失败的访问控制通常会导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：

违反最小特权原则或默认拒绝原则，即访问权限应该只授予特定能力、角色或用户，但实际上任何人都可 以访问。

通过修改 URL （参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用修改 API 请求的攻击 工具来绕过访问控制检查。

通过提供唯一标识符（不安全的直接对象引用）允许查看或编辑其他人的帐户

API没有对POST、PUT 和DELETE强制执行访问控制。

特权提升。在未登录的情况下假扮用户或以用户身份登录时充当管理员。

元数据操作，例如通过重放或篡改 JSONWeb 令牌 (JWT) 来访问控制令牌，或操纵cookie 或隐藏字段以 提升权限，或滥用 JWT 失效。

CORS 配置错误以致允许未授权或不可信的API访问。

以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面。

防御措施

访问控制只在受信服务器端代码或无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据。

除公有资源外，默认为 “拒绝访问”。

使用一次性的访问控制机制，并在整个应用程序中不断重用它们， 包括最小化跨源资源共享 (CORS) 的使 用。

建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、 读取、 更新或删除的任何记录。

特别的业务应用访问限制需求应由领域模型强制执行。

禁用Web服务器目录列表，并确保文件元数据（例如：.git） 和备份文件不存在于Web的根目录中。

在日志中记录失败的访问控制，并在适当时向管理员告警 （例如：重复故障）。

对API和控制器的访问进行速率限制， 以最大限度地降低自动化攻击工具带来的危害。

当用户注销后，服务器上的状态会话标识符应失效。无状态的JWT令牌应该是短暂的，以便让攻击者的攻 击机会窗口最小化。对于时间较长的JWT， 强烈建议遵循OAuth标准来撤销访问。

0x05 加密

风险说明

首先要确认：对传输中数据和存储数据都有哪些保护需求。例如， 密码、 信用卡号、 医疗记录、 个人信 息和商业秘密需要额外保护， 尤其是在这些数据属于隐私保护法 （如：欧盟GDPR) 或法规条例 （如：金融数据保护标准PCI DSS)适用范围的情况下。对于这些数据， 要确定：

在传输数据过程中是否使用明文传输？这和传输协议有关， 如：HTTP 、 SMTP 、 经过TLS升级 （如 STARTTLS ） 的FTP。外部网络流量是有害的。需要验证所有的内部通信， 如， 负载平衡、 Web服务器或 后端系统之间的流量。

无论是在默认情况下还是在旧的代码中， 是否还在使用任何旧的或脆弱的加密算法或传输协议？

是否使用默认加密密钥、 生成或重复使用脆弱的加密密钥， 或者是否缺少适当的密钥管理或密钥回转？加 密密钥是否已经提交到源代码存储库？

是否未执行强制加密， 例如， 是否缺少安全相关的HTTP （浏览器） 指令或标头？

接收到的服务器证书和信任链是否经过正确验证？

初始化向量是否忽略， 重用或生成的密码操作模式是否不够安全？是否正在使用不安全的操作模式， 例如 欧洲央行正在使用的操作模式？当认证加密更合适时是否使用加密？

在缺乏密码基密钥派生函数的情况下， 是否将密码用作加密密钥？

随机性是否用于并非旨在满足加密要求的加密目的？即使选择了正确的函数， 它是否需要由开发人员播种， 如果不需要， 开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能？

是否使用过时的散列函数， 例如 MD5 或 SHA1， 或者在散列函数需要加密时使用非加密散列函数？

是否在使用已弃用的加密填充方法， 例如 PCKS number 1 v1.5？

加密的错误消息或侧信道信息是否可以利用， 例如使用填充预言机攻击的形式？

预防措施

至少执行以下操作， 并查阅参考资料：

对应用程序处理、 存储或传输的数据分类， 并根据隐私法、 监管要求或业务需求确定哪些数据是敏感的。

对于没有必要存储的敏感数据， 应当尽快清除， 或者通过PCI DSS标记化或拦截。未存储的数据不能窃取。

确保加密存储的所有敏感数据。

确保使用了最新的、 强大的标准算法、 协议和密钥；并且密钥管理到位。

确保加密传输过程中的数据， 如使用安全协议 （例如具有前向保密 (FS) 密码的 TLS、 服务器的密码优先级 和安全参数） 。确保强制执行数据加密， 如使用HTTP 严格安全传输协议 (HSTS) 等指令。

禁用缓存对包含敏感数据的响应。

根据数据分类应用实施所需的安全控制。

不要使用FTP 和SMTP 等传统协议来传输敏感数据。

使用具有工作因子 （延迟因子） 的强自适应和加盐散列函数存储密码， 例如 Argon2、 scrypt、 bcrypt 或 PBKDF2。

必须选择适合操作模式的初始化向量。对于大多数模式， 可以使用CSPRNG （密码安全伪随机数生成器） 。对于需要随机数的模式， 则初始化向量 (IV) 不需要使用CSPRNG。在所有情况下， 对于一个固定密钥， 永 远不应该使用两次IV。

始终使用经过验证的加密， 而不仅仅是加密。

密钥应以加密方式随机生成并作为字节数组存储在内存中。如果使用密码， 则必须通过适当的密码基密钥 派生函数将其转换为密钥。

确保在适当的地方使用加密随机性， 并且没有以可预测的方式或低熵进行播种。大多数现代 API 不需要开 发人员为 CSPRNG 设置种子以获得安全性。

避免使用的已废弃的加密函数和填充方案， 例如 MD5、 SHA1、 PKCS number 1 v1.5。

单独验证每个安全配置项的有效性。

0x06 框架漏洞

https://zhuanlan.zhihu.com/p/353034640

0x07 DDOS

防御方法

1、采用高性能的网络设备

首先要保证网络设备不能成为瓶颈，因此选择路由器、交换机、硬件防火墙等设备的时候要尽量选用知名度高、口碑好的产品。再就是假如和网络提供商有特殊关系或协议的话就更好了，当大量攻击发生的时候请他们在网络接点处做一下流量限制来对抗某些种类的DDoS攻击是非常有效的。

2、尽量避免NAT的使用

无论是路由器还是硬件防护墙设备要尽量避免采用网络地址转换NAT的使用，因为采用此技术会较大降低网络通信能力，其实原因很简单，因为NAT需要对地址来回转换，转换过程中需要对网络包的校验和进行计算，因此浪费了很多CPU的时间，但有些时候必须使用NAT,那就没有好办法了。

3、充足的网络带宽保证

网络带宽直接决定了能抗受攻击的能力，假若仅仅有10M带宽的话，无论采取什么措施都很难对抗现在的SYNFIood攻击，当前至少要选择100M的共享带宽，最好的当然是挂在1000M的主干上了。但需要注意的是，主机上的网卡是1000M的并不意味着它的网络带宽就是千兆的，若把它接在100M的交换机上，它的实际带宽不会超过100M,再就是接在100M的带宽上也不等于就有了百兆的带宽，因为网络服务商很可能会在交换机上限制实际带宽为10M,这点一定要搞清楚。

4、升级主机服务器硬件

在有网络带宽保证的前提下，请尽量提升硬件配置，要有效对抗每秒10万个SYN攻击包，服务器的配置至少应该为：

P42.4G/DDR512M/SCS1-HD,起关键作用的主要是CPU和内存，若有志强双CPU的话就用它吧，内存一定要选择DDR的高速内存，硬盘要尽量选择SCS的，别只贪DE价格不贵量还足的便宜，否则会付出高昂的性能代价，再就是网卡一定要选用3COM或Intel等名牌的，若是Realtekl的还是用在自己的PC上吧。

5、把网站做成静态页面或者伪静态

大量事实证明，把网站尽可能做成静态页面，不仅能大大提高抗攻击能力，而且还给黑客入侵带来不少麻烦，至少到现在为止关于HTML的溢出还没出现，看看吧！新浪、搜狐、网易等门户网站主要都是静态页面，若你非需要动态脚本调用，那就把它弄到另外一台单独主机去，免的遭受攻击时连累主服务器，当然，适当放一些不做数据库调用脚本还是可以的，此外，最好在需要调用数据库的脚本中拒绝使用代理的访问，因为经验表明使用代理访问你网站的80%属于恶意行为。

6、增强操作系统的TCP/IP栈

Win2000和Win2003作为服务器操作系统，本身就具备一定的抵抗DDoS攻击的能力，只是默认状态下没有开启而已，

若开启的话可抵挡约10000个SYN攻击包，若没有开启则仅能抵御数百个，具体怎么开启，可以看看微软的文章吧！ 《强化TCPP堆栈安全》

7、安装专业抗DDOS防火墙

8、HTTP请求的拦截

如果恶意请求有特征，对付起来很简单：直接拦截它就行了。

HTTP请求的特征一般有两种：P地址和User Agent字段。比如，恶意请求都是从某个IP段发出的，那么把这个IP段封掉就行了。或者，它们的User Agent字段有特征（包含某个特定的词语），那就把带有这个词语的请求拦截。

9、备份网站

你要有一个备份网站，或者最低限度有一个临时主页。生产服务器万一下线了，可以立刻切换到备份网站，不至于毫无办法。

备份网站不一定是全功能的，如果能做到全静态浏览，就能满足需求。最低限度应该可以显示公告，告诉用户，网站出了问题，正在全力抢修。

这种临时主页建议放到Github Pages或者Netlify,它们的带宽大，可以应对攻击，而且都支持绑定域名，还能从源码自动构建。

10、部署CDN

CDN指的是网站的静态内容分发到多个服务器，用户就近访问，提高速度。因此，CDN也是带宽扩容的一种方法，可以用来防御DDOS攻击。

网站内容存放在源服务器，CDN上面是内容的缓存。用户只允许访问CDN,如果内容不在CDN上，CDN再向源服务器发出请求。这样的话，只要CDN够大，就可以抵御很大的攻击。不过，这种方法有一个前提，网站的大部分内容必须可以静态缓存。对于动态内容为主的网站（比如论坛），就要想别的办法，尽量减少用户对动态数据的请求；本质就是自己搭建一个微型CDN。各大云服务商提供的高防P,背后也是这样做的：网站域名指向高防P,它提供一个缓冲层，清洗流量，并对源服务器的内容进行缓存。

这里有一个关键点，一旦上了CDN,千万不要泄露源服务器的P地址，否则攻击者可以绕过CDN直接攻击源服务器，前面的努力都白费。搜一下"绕过CDN获取真实P地址"，你就会知道国内的黑产行业有多猖獗。

11、其他防御措施

以上几条对抗DDoS建议，适合绝大多数拥有自己主机的用户，但假如采取以上措施后仍然不能解决DDoS问题，就有些麻烦了，可能需要更多投资，增加服务器数量并采用DNS轮巡或负载均衡技术，甚至需要购买七层交换机设备，从而使得抗DDoS攻击能力成倍提高，只要投资足够深入。

0x08 安全配置

风险说明

您的应用程序可能受到攻击， 如果应用程序是：

应用程序栈的任何部分缺少适当的安全加固， 或者云服务的权限配置错误。

应用程序启用或安装了不必要的功能 （例如：不必要的端口、 服务、 网页、 帐户或权限） 。

默认帐户和密码仍然可用且没有更改。

错误处理机制向用户纰漏堆栈信息或其他大量错误信息。

对于升级的系统， 最新的安全特性被禁用或未安全配置。

应用程序服务器、 应用程序框架 （如：Struts、 Spring、 ASP.NET） 、 库文件、 数据库等没有进 行安全配置。

服务器不发送安全标头或指令， 或未被设定安全参数。

您的应用软件已过期或易受攻击 （参见“A6:2021-脆弱和过时的组件”） 。

缺少一个体系的、 可重复的应用程序安全配置过程， 系统将处于高风险中。

防御措施

应实施安全的安装过程， 包括：

一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、 质量保证和生产环境都应 该进行相同配置， 并且在每个环境中使用不同的密码。这个过程应该是自动化的， 以尽量减少安装 一个新安全环境的耗费。

搭建最小化平台， 该平台不包含任何不必要的功能、 组件、 文档和示例。移除或不安装不适用的功 能和框架。

检查和修复安全配置项来适应最新的安全说明、 更新和补丁， 并将其作为更新管理过程的一部分 （参见 “A6:2021-脆弱和过时的组件”） 。在检查过程中， 应特别注意云存储权限 （如：S3桶权 限） 。

一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构， 包括：分段、 容器化和云安 全组 （ACL） 。

向客户端发送安全指令， 例如：安全标头。

一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程。

编辑：黄飞