👉🏻TOP1：越权漏洞 Broken Access Control
简介
主要分为水平越权和垂直越权。
水平越权：普通用户拥有其他平行级别用户的权限
垂直越权：跨越自身所属用户组，获取更高级别用户的权限（比如管理员权限）
常见情况
通过修改url、内部应用程序状态或HTML页面绕过访问控制检查，或简单地使用自定义的API攻击工具
网站以用户提交的id判断用户是否具有信息查询权限并返回用户提交id对应的用户信息
避免方式：根据用户本身的Session判断当前用户是否拥有读取个人信息权限
漏洞利用示例：攻击者A利用抓包工具将自动发送的查询请求中的userid修改为B用户的id，就可以查询到B用户的信息；未加密且用的是get请求时，通过修改url里的userid直接登入其他用户的账号
特权提升，垂直越权
用户具有阅读文章权限而不具有编辑文章权限，阅读文章的接口是read_article。权限保护方式基于接口名称的秘密
漏洞出现原因：可以猜测到修改文章的接口是edit_article
漏洞利用示例：攻击者A根据阅读文章的接口名称是read_article猜测修改文章的接口名称是edit_article，调用该接口，实现垂直越权
修改Cookie中参数
早期的网站设计会在Cookie中加入“admin = true”标识用户是否具有管理员权限
漏洞出现原因：Cookie不同于Session，Cookie中的参数存储在用户浏览器上，可以直观展现给用户；Session存储在服务器端，比Cookie安全
漏洞利用示例：攻击者A掌握网站的Cookie规律后
方法①：通过JavaScript代码重置 document.cookie 内容越权
方法②：抓包将“admin = false”修改为“admin = true”
系统权限回收有问题
漏洞出现原因：网站保留了注销用户信息而没有把它从用户表中删除，而仅仅对该用户是否有效这个字段进行了标记
漏洞利用示例：攻击者A注册时保留与注销用户B同样的用户id，覆盖了原用户的信息单保留了元用户的权限
检测方法
未授权访问与水平越权：cookie伪造；修改返回包中某个参数的值（比如false改为true）；水平越权常见与业务系统中，对用户信息或者订单信息进行增删改查操作时，用户编号和订单编号常常有规律可循，测试人员通过burpsuit的intruder对目标参数进行遍历测试即可
垂直越权：将cookie中的false改为true；文件上传与下载漏洞可以通过./和../绕过，admin权限验证绕过也可以尝试这种方法
如何预防？
将访问控制限制在仅在受信任的服务器端代码或者无服务器API中，这样攻击者就无法修改访问控制检查或元数据
合理划分网站权限，设置功能验证，验证失败禁止访问
最小权限原则。除公有资源外，其他资源默认情况下拒绝访问，限制用户不必要的权限，用户权限过期后收回
进行严格的权限判断，用户只能操作属于自己的内容。此处权限判断需要识别用户身份，识别用户身份基于Session而非Cookie验证（即在服务器端进行验证）
记录失败的访问控制，适当时候对管理员进行告警（比如银行卡密码最多输入三次三次输错需要重新验证/找管理员更改密码，不能无限次试。避免了暴力破解）
对API和控制器的访问进行速率限制（避免高速爆破），最大限度降低自动化攻击工具的危害（也会有后续处置，比如后台发现某个ip多次异常尝试且多次失败，就把ip封了）
补充知识
- 网站会给用户分配不同的Session（会话标识符）维持用户对话
👉🏻TOP2：加密机制失效 Cryptographic Failures
简介
通常是缺乏加密措施或者加密失效导致敏感数据泄露
常见情况
- 以明文方式传输数据，未执行加密
- 使用旧or弱加密算法或协议
- 使用弱加密密钥、重复使用弱加密密钥、缺少适当的密钥管理和轮换、不小心将加密密钥提交到了源代码数据库中
- 接收到的服务器证书和信任链没有经过正确验证
如何预防？
- 使用安全协议对所有数据进行传输加密
- 使用最新版且标准的强演算法、协定及密钥；使用适当的密钥管理
- 使用经过身份验证的加密而不仅仅是加密
攻击范例
- 情境1：某应用程序加密了存储在数据库中的信用卡号，但却在检索数据时自动解密，因此容易受到 SQL 注入攻击，导致信用卡号被泄露
- 情境2：网站没有强制使用 TLS 或支持弱加密，导致攻击者能够通过网络监控、降级 HTTPS 连接为 HTTP，并截取会话 cookies，从而劫持用户的会话并访问或修改其隐私数据。攻击者还可以篡改传输的数据，例如修改汇款收款人信息
- 情境3：密码库使用简单的散列函数存储密码，没有使用盐值或者使用了简单的盐值。由于上传文件的漏洞，攻击者可以访问密码库，未经盐值加密的哈希密码可以被预先计算的彩虹表破解。即使使用了盐值，如果哈希函数简单或快速，仍然容易受到 GPU 加速破解（PS：“盐”指随机生成的额外字符串）
👉🏻TOP3：注入攻击 Injection
web对用户输入的内容的合法性判断不严或者过滤不严，攻击者在web应用程序中事先定义好的查询语句的结尾添加额外的执行语句，在管理员不知情的情况下进行非法操作，奇葩数据库执行非授权的任意查询，进一步得到数据信息。
其本质是对于输入的检查不充分，导致SQL语句将用户提交的非法数据当做语句的一部分来执行，简言而之就是用户提交的数据代入数据库的查询。
SQL注入：把SQL命令插入到Web表单递交或者输入域名或者页面请求的查询字符串，欺骗服务器执行恶意SQL命令
SQL注入分类：所有与用户进行交互的地方都可能存在注入
基于数据类型：字符串类型注入；整型注入
基于程度和顺序的注入：一阶注入；二阶注入
基于从服务器收到的响应
基于错误的SQL查询
联合查询的类型
堆查询注射
SQL盲注：基于布尔；时间；报错
注入思路：
- 判断是否存在注入，类型是字符型还是数字型
- 猜解SQL查询语句中的字段数
- 确定显示的字段顺序
- 获取当前数据库
- 获取数据库中的表
盲注思路
- 判断是否存在注入，类型是字符型还是数字型
- 猜解SQL查询语句中的字段数
- 猜解数据库名
- 猜解数据库表名
- 猜解表中字段名
- 猜解数据
防范方式
- 关闭SQL错误回显
- 使用成熟的WAF
- 前端输入字符白名单验证（长度、类型）
- SQL服务运行专门的账号并且使用最小权限
- 对输入的特殊字符进行转义处理
👉🏻TOP4：不安全设计
产生原因
开发软件时在关键的身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计
漏洞利用
业务逻辑的体现
- 支付逻辑
- 密码找回
- 验证码：暴力破解；重复使用；客户端回显；绕过；自动识别
支付逻辑漏洞
修改支付价格、状态；修改购买数量；修改优惠券和积分；修改支付接口；多重替换支付；重复支付；最小额和最大额支付；无限制试用
场景
- 使用burpsuit抓包并且修改原始数据（用户界面数据无法更改，前端有封装），将运费金额30修改为9.9
- 把state的值从2修改为1，这样随机输入的密码也会被识别为真，导致任意密码重置
👉🏻TOP5：安全配置不当
通常由于不安全的默认配置、不完整的临时配置、不必要的功能启用或者安装、开源云储存、错误的http标头配置、包含敏感信息的详细报错信息。因此不仅要对所有的操作系统、框架、库和应用程序进行安全配置，而且必须及时修补和升级
案例
- Tomcat、Apache服务器后台弱口令和服务器的不当配置容易被利用
- 中国电信交换机弱口令
- 行业内设备（比如华为的SmartAXMT调制解调器初始ip和默认密码是xxxxx都是已知的网上能找到的）
防范
- 按照加固手册加固
- 搭建最小化平台，这个平台不包含任何不必要的功能、组件、文档和示例，移除或者不安装不适用的功能和框架
- 临时文件及时删除
👉🏻TOP6：组件问题（API 框架 库 ）
组件（例如库、框架、其他软件模块）拥有和应用程序相同的权限。如果应用程序中有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或者服务器接管，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御，造成攻击产生影响
场景
- 某个组件出现新的漏洞，攻击者可能凭借这个情报利用这个组件漏洞攻击应用程序（信息不对称）
防范
- 移除不使用的依赖、不需要的功能、组件、文件和文档
- 仅从官方渠道获取组件，并使用签名机制来降低组件被篡改或被加入恶意漏洞的风险
- 持续监控CVE、NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能，订阅组件漏洞最新信息的邮件以获取即时信息
👉🏻TOP7：认证及验证机制失效（密码交互存在问题）
错误使用应用程序的身份认证和会话功能管理，使攻击者能够破译密码、密钥或者会话令牌，或者利用其他开发缺陷冒充其他用户身份。web程序开发者过于专注程序功能开发，可能会建立自定义的认证和会话方案，这可能会存在漏洞。可能会在推出、密码管理、超时、密码找回、账户更新等方面存在漏洞。
也就是说在密码等重要数据进行交互的过程中程序存在问题，并且被利用
情景
- 应用程序没有实施自动化威胁保护或撞库攻击保护的情况下，使用已知列表密码撞库（比如旧密码泄露）
- 使用明文、加密或者弱散列密码或者用户重复使用同一种密码，容易被暴力破解（不是特殊加密方法的话密码破解可能会很快）
- 缺少或失效的多因素身份验证
- 暴露url中的会话id
- 会话ID使用时间过长
防范
使用多因素身份验证
检查弱口令，模拟爆破操作
对API和控制器的访问进行速率限制，限制或逐渐延迟失败的登录尝试（避免高速爆破），最大限度降低自动化攻击工具的危害（也会有后续处置，比如后台发现某个ip多次异常尝试且多次失败，就把ip封了
session id 每隔一段时间就生成新的高度负责的新随机会话id。这个id不能出现在url中，登出、闲置、绝对超时的时候就使其失效
👉🏻TOP8：软件和数据完整性失效 Software and Data Integrity Failures
简介
软件更新、关键资料（critical data）、持续集成/持续部署（CI/CD）流程等关键内容没有经过完整性验证导致产生的漏洞
软件更新：指在已发布的软件版本中修复漏洞、增加功能或改进性能等目的而发布的新版本
关键资料：软件更新过程中使用的关键数据，比如用户隐私信息、安全凭证、加密密钥等
持续集成/持续部署（CI/CD）流程：旨在通过自动化构建、测试和部署流程来实现快速、频繁的软件发布。持续集成是指频繁地将开发人员的代码集成到共享存储库中，持续部署是指自动将通过测试的代码部署到生产环境中
没有经过完整性验证：指的是在软件更新过程中，假设了某些关键资料的完整性已经被验证，或者假设了CI/CD流程的整体安全性和正确性，而实际上并没有进行充分的验证。这样的假设可能导致漏洞或安全风险的存在
常见情况
- 不安全的序列化和反序列化：当对象或数据被编码或序列化成攻击者可以看到和修改的结构时，容易受到不安全的反序列化攻击
- 依赖不受信任来源：应用程序来自不被信任的来源，包括一些不被信任的外部库、内容传递网络(CND)、库或者模组
- 不安全的持续集成/持续部署 (CI/CD) 流程：不安全的集成/部署(CI/CD)流程可能导致未经授权的访问、恶意代码注入或系统破坏
- 自动更新的安全性问题：很多应用程序会进行自动更新，在缺乏完整性验证的情况下把更新包应用到之前信任的应用程序上。这里攻击者可以上传自制的所谓“更新”内容在所有应用程序上运行，达到窃取信息等目的
如何预防？
- 使用数字签名或者类似的机制验证软件数据来源正确且未被更改
- 使用可信任度较高的库和依赖项；确保安全工具验证组件不包含已知漏洞；尽量保证代码在构建和部署过程中的完整性；确保有代码审计和配置更改的审查流程，避免恶意代码或者恶意配置被引入软件流程
- 确保未签名或未加密的序列化数据不被发送到不受信任的客户端，除非有完整性检查或者数字签名来检测数据是否被篡改或重放。
防范举例
安卓手机，通过官方的应用商城安装软件相对比较安全，因为应用商城会对更新包和软件包进行检测以防范这种漏洞。如果从浏览器或者其他途径下载软件手机会警告用户软件可能不安全。
👉🏻TOP9：安全记录记录和监控失效
概念
自己内部的检查能力不足，没办法在别人攻击自己的时候发现自己被攻击了
场景
印度一家大型航空公司发生涉及数百万乘客超过十年包括护照及信用卡资料等个人资料的资料泄漏。资料泄漏发生在第三方供应商提供的云端服务，该供应商在资料泄漏发生一段时间后通知航空公司。
未记录可审计的事件，如登录、登录失败、高额交易
告警和错误事件未能产生或者产生不足和不清晰的日志信息
日志信息仅在本地存储，日志信息可能被消掉
没有利用应用系统、API的日志信息监控可以活动
对于实时或者准实时攻击，应用程序无法检测、处理和告警
防范
确保所有的登录、访问控制失效、输入验证失败能够被记录到日志中去，保留足够的用户上下文信息，识别可疑或者恶意账户，为货期取证预留时间
日志集中管理、备份
审计信息保存在只能增加不能删除的数据库中
建立有效的告警机制，使可疑活动在可接受的范围内被发现和应对
👉🏻TOP10：SSRF-服务器端请求伪造
攻击者利用服务器上的应用程序，发送伪造请求到服务器内部或者其他内网，从而达到攻击的目的
限制访问权限：确保服务器上的应用程序只能访问必要的资源，避免访问敏感的内部网络资源。
过滤和验证输入： 对用户输入进行有效的过滤和验证，确保输入的URL是合法的且安全的，防止攻击者利用URL参数进行攻击。
使用白名单： 配置白名单，只允许应用程序访问特定的URL或者IP地址，从而避免访问未经授权的资源。
使用防火墙和WAF： 配置防火墙和Web应用程序防火墙（WAF），监控和过滤服务器上的入站和出站流量，阻止恶意请求和攻击。
更新和维护： 定期更新和维护服务器上的软件和组件，修复已知的漏洞和安全问题
XXE
应用程序解析XML文件时包含了对外部实体的引用，攻击者传递恶意包含XML代码的文件，读取指定服务器资源
防范：
- 使用简单的数据格式（如JSON），避免对敏感数据序列化
- 服务器端实行白名单验证、过滤、清除，防止在XML或者标题中出现恶意数据
- 及时更新或者修复应用程序和底层操作系统使用的所有XML处理器和库
CSRF-跨站请求伪造
利用用户在某个网站上已经登录的身份，在用户不知情的情况下，在另一个网站上执行一些非法操作
已经在购物网站上登录，然后收到一封看起来很正常的电子邮件。点击邮件中的链接，不知不觉地执行了一个操作，比如购买了一件商品或者更改了密码
- 在每个表单提交或者敏感操作中包含一个随机生成的Token，并在后端进行验证。这个Token在每次请求中都会发生变化，攻击者无法伪造有效的Token，从而阻止了CSRF攻击。
- 限制cookie的发送范围，只允许来自同一站点的请求携带Cookie，防止跨站请求伪造
- 服务器端对请求的Referer进行验证（HTTP头中有一个字段叫Referer，它记录了该请求的来源地址），确保请求来源合法
- 执行敏感操作的请求，需要用户进行双重确认，比如输入密码、验证码等
- 对于执行敏感操作的Session，设置短暂有效期，减少攻击者利用的时间窗口
- 使用POST方法而不是GET方法来执行敏感操作
XSS-跨站脚本攻击
将可执行的前端脚本代码（一般为JavaScript）植入到网页中，通过利用网页开发时留下的漏洞，注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。
反射型：攻击者将JS代码作为请求参数放置URL中，诱导用户点击，落入陷阱
存储型：将攻击脚本入库存储，在后面进行查询时，再将攻击脚本渲染进网页，返回给浏览器触发执行
DOM型：它和反射型以及存储型XSS的区别在于，DOM XSS的代码并不需要服务器解析响应的直接参与，触发XSS靠的是浏览器的DOM解析，可以认为完全是客户端的事情。
防御方式
- 输入验证和过滤： 对用户输入的内容进行严格的验证和过滤，确保其中不包含恶意脚本。可以使用白名单过滤、转义特殊字符等方式来防止
- 输出编码：使用合适的编码方式编码，防止浏览器误将其中的内容解析为可执行的脚本。常用的编码方式包括HTML编码、URL编码等。
- HTTP头部设置： 在HTTP响应头中设置合适的Content-Security-Policy（CSP）头部，限制页面加载的资源和执行的脚本
- 将敏感信息存储在HttpOnly Cookie中，这样即使页面存在XSS漏洞，攻击者也无法窃取到Cookie中的敏感信息。
Reference：
OWASP官网
《Web漏洞解析与攻防实战》