文章目录

• OWASP TOP 10
• • OWASP介绍
  • OWASP TOP 10
  • A1 注入injection
  • • SQL注入攻击
    • • 防护方案
    • 命令注入攻击
    • • 防护方案
  • A2 失效的身份认证
  • • 防护方案
  • A3 敏感数据泄露
  • • 防护方案
  • A4 XML外部实体（XXE）
  • • 攻击方式
    • 漏洞原因
    • 漏洞影响
    • 防护方案
  • A5 无效的访问控制（业务逻辑漏洞）
  • • 垂直越权：
    • 水平越权：
    • 防护方案
  • A6：安全配置错误
  • • 漏洞影响
    • 防护方案
  • A7：跨站脚本（XSS）
  • • 防护方案
  • A8 不安全的反序列化
  • • 防护方案
  • A9 使用含有已知漏洞的组件
  • A10 日志记录和监控不足
  • • 防护方案
  • A11 跨站请求伪造（CSRF）
  • • 关键点
    • 目标
    • 防护方案

OWASP TOP 10

OWASP介绍

• 官网：http://www.owasp.org.cn/
• OWASP TOP10 指出了 WEB 应用面临最大风险的 10 类问题，是目前 WEB 应用安全方面最权威的项目。
• OWASP 是一个开源的、非盈利全球性安全组织，致力于应用软件的安全研究。OWASP 的使命是应用软件更加安全，使企业和组织能够对应用安全风险作出更清晰的决策。 目前 OWASP 全球拥有 140 个分会近四万名员，共同推动了安全标准、安全测试工具、安全指导手册等应用安全技术的发展。

OWASP TOP 10

• A1：2017 注入
• A2：2017 失效的身份认证
• A3：2017 敏感数据泄露
• A4：2017 XML外部实体
• A5：2017 失效的访问控制
• A6：2017 安全配置错误
• A7：2017 跨站请求脚本（XSS）
• A8：2013 跨站请求伪造（CSRF）
• A8：2017 不安全的反序列化
• A9：2017 使用含有已知漏洞的组件
• A10：2017 不足的日志记录和监控

A1 注入injection

注入：用户的输入被当成命令/代码执行或者解析了

将不受信用的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入（操作系统命令）和LDAP（轻量目录访问协议）注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。

用户的输入并非固定位置，可能存在于：

• 输入框
• 搜索栏
• 提交表单
• URL链接
• 所有的GET/POST请求的请求头和请求包头
• 留言
• 评论
• 几乎任何数据源都有可能成为注入载体，只要是能被发出的数据位置

可被执行的代码：

• SQL
• LDAP
• Xpath or NoSQL
• 系统命令
• XML语言
• SMTP包头
• 表达式语句
• ORM查询语句
• 危害：该代码能做什么即是危害

注入的分类

通常的注入有sql注入和命令注入

SQL注入攻击

动态页面有时会通过脚本引擎将用户输入的参数按照预先设定的规则构造成SQL语句来进行数据库操作。SQL注入攻击指的是通过构造特殊的输入作为参数传入Web应用程序，改变原有的SQL语句的语义来执行攻击者所要的操作，其主要原因是程序没有采取必要的措施避免用户输入内容改变原有SQL语句的语义。

SQL注入的危害：

• 绕过登陆验证：使用万能密码登陆网站后台等
• 获取敏感数据：获取网站管理员账号、密码等
• 文件系统操作：列目录、读取或写入文件等
• 注册表操作：读取、写入、删除注册表等
• 执行系统命令：远程执行命令

参考链接：https://www.zhiji.icu/2021/03/06/qian-tan-sql-zhu-ru/

防护方案

1、关闭 SQL 错误回显
2、前端输入字符白名单验证（长度、类型等）
3、对输入的特殊字符使用转义处理
4、SQL 操作使用 PreParedStatement
5、SQL 服务运行于专门的账号，并且使用最小权限
6、限制 SQL 服务的远程访问，只开放给特定开发人员
7、代码审计，最有效的检测应用程序的注入风险的方法之一
8、使用成熟的 waf

命令注入攻击

WEB应用代码中，有时会允许接收用户输入一段代码，之后在web应用服务器上执行这段代码并将结果返回给用户，如果这段代码没有进行限制，用户就可能执行恶意代码。

防护方案

1、白名单效验命令参数

2、单引号禁止命令解析功能

A2 失效的身份认证

通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者暂时或永久的冒充其他用户的身份。

危害：

这些漏洞可能导致部分甚至全部账户遭受攻击，一旦攻击成功，攻击者就能执行合法的任何操作

防护方案

1、使用内置的会话管理功能

2、通过认证的问候

3、使用单一的入口点

4、确保在一开始登录SSL保护的网页

A3 敏感数据泄露

一般我们的敏感信息包括密码、财务数据、医疗数据等，由于web应用或者API未加密或不正确的保护敏感数据，这些数据极易遭到攻击者利用，攻击者可能使用这些数据来进行一些犯罪行为，因此，未加密的信息极易遭到破坏和利用，我们应该加强对敏感数据的保护，web应用应该在传输过程中数据、存储的数据以及和浏览器的交互时的数据进行加密，保证数据安全。

实例场景

• 一个应用程序使用自动化的数据加密系统加密信用卡信息，并存储在数据库中。但是，当数据被检索时被自动解密，这就使得SQL注入漏洞能够以明文形式获取所有信用卡卡号
• 一个网站上对所有网页没有使用或强制使用TLS，或者使用弱加密。攻击者通过检测网络流量（如：不安全的无线网络），将网络连接从HTTPS降到HTTP，就可以截取请求并窃取用户会话cookie。之后攻击者可以复制用户cookie并成功劫持经过认证的用户会话、访问或修改用户个人信息。除此之外，攻击者还可以更改所有传输过程中的数据，例如：转款的接受者
• 密码数据库使用未加盐的哈希算法或弱哈希算法去存储每个人的密码，一个文件上传漏洞能使黑客获取密码文件。所有这些未加盐的哈希密码通过彩虹表暴力破解方式破解，由简单或快速散列函数生成加盐的哈希也可以通过GPU破解

防护方案

1、对于 github 泄露，定期对仓库扫描

2、对于应用网站目录定期扫描

3、使用强壮的网络协议与算法

4、注重对敏感数据的保护

A4 XML外部实体（XXE）

XXE 全称为XML External Entity attack 即XML(可扩展标记语言) 外部实体注入攻击，早期或配置错误的XML处理器评估了XML文件外部实体引用，攻击者可以利用这个漏洞窃取URI(统一资源标识符)文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

攻击方式

当应用程序解析 XML文件时包含了对外部实体的引用，攻击者传递恶意包含 XML 代码的文件，读取指定的服务器资源。

漏洞原因

XML 协议文档本身的设计特性，可以引入外部的资源；定义 XML 文件时使用的外部实体引入功能

漏洞影响

读取服务器敏感资料，如、/etc/password
读取应用程序源码

防护方案

1、关闭 DTD (Data Type Definition)
2、禁止外部实体引入

2.1 使用开发语言提供的禁用外部实体的方法
PHP：

libxml_disable_entity_loader(true);

其他语言:

https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet

3、过滤用户提交的XML数据

关键词

system
file://
public
http://
expect
...

A5 无效的访问控制（业务逻辑漏洞）

失效的访问控制就是越权访问漏洞

未对通过身份验证的用户实施恰当的访问控制。攻击者可以利用这些缺陷访问未经授权的功能或数据，例如：访问其他用户的账户、查看敏感文件、修改其他用户数据、更改访问权限等

垂直越权：

低权限用户可以访问更高权限才能访问的页面

水平越权：

同级别权限用户的权限控制失效，攻击者可以从普通用户A的权限提升到普通用户B的权限访问应用程序

防护方案

1、对参数的白名单过滤

2、对权限的控制管理重新设计与限制

3、限制下载文件的类型

A6：安全配置错误

安全配置错误是比较常见的漏洞，由于操作者的不当配置(默认配置，临时配置，开源云存储，http标头配置，以及包含敏感信息的详细错误)，导致攻击者可以利用这些配置获取到更高的权限，安全配置错误可以发生在各个层面，包含平台、web服务器、应用服务器、数据库、架构和代码。

如 python 开发中对于 Django 框架在生产环境启用了 Debug 模式

可能受到攻击的应用程序：

• 缺少适当的安全加固、云服务的权限配置错误
• 应用程序启用或安装了不必要的功能（端口、服务、网页、账户或权限等）
• 默认账户的密码仍然没有更改
• 错误处理机制向用户披露堆栈跟踪或其他大量错误信息
• 对于更新的系统，禁用或不安全地配置最新的安全功能
• 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置
• 服务器不发送安全标头或指令，或未对服务器进行安全配置
• 应用软件已过期或易受攻击

漏洞影响

可让攻击者获取到敏感数据、提升权限，如未修改应用程序配置的默认密码，未删除应用程序安装程序目录文件等

防护方案

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费
• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，在检查过程中应特别注意云存储权限（如：S3桶权限）
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组
• 向客户端发送安全指令，如：安全标头
• 在所有环境中能够进行正确安全配置和设置自动化过程

A7：跨站脚本（XSS）

当应用程序的新网页中包含不受信任的、未经恰当验证、转义的数据或可以使用HTML、JavaScript的浏览器API更新的现有网页时，就会出现xss漏洞，跨站脚本攻击是最普遍的web应用安全漏洞，甚至在某些安全平台都存在xss漏洞。xss会执行攻击者在浏览器中执行的脚本，并劫持用户会话，破坏网站或用户重定向到恶意站点，使用xss还可以执行拒绝服务攻击。

恶意攻击者往Web页面里插入恶意的Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。

存在三种XSS类型，通常针对用户的浏览器：

• 反射式XSS：应用程序或API包括未经验证和未转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器执行任意的HTML和JavaScript。通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，如恶意漏洞网站，广告等
• 存储式XSS：你的应用或API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。存储型XSS一般被认为是高危或严重的风险
• 基于DOM的XSS：会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScript API

典型的XSS攻击可导致盗取session、账户、绕过MFA、DIV替换、对用户浏览器的攻击（如：恶意软件下载、键盘记录）

防护方案

XSS 过滤器的作用是过滤用户（浏览器客户端）提交的有害信息，从而达到防范XSS 攻击的效果。

1、输入过滤

输入验证

• 对用户提交的信息进行“有效性”验证。
• 仅接受指定长度
• 仅包含合法字符
• 仅接收指定范围
• 特殊的格式，例如，email 、IP 地址。

数据消毒

• 过滤或净化掉有害的输入

$code = str_replace('script','',$xsscode);

2、输出编码

HTML 编码是HTML 实体编码。

$code = htmlspecialchars($xsscode);

3、黑白名单策略

不管是采用输入过滤还是输出编码，都是针对信息进行黑、白名单式的过滤。

• 黑名单，非允许的内容
• 白名单，允许的内容

4、防御DOM 型XSS

避免客户端文档重写，重定向或其他敏感操作。

A8 不安全的反序列化

不安全的反序列化可以导致远程代码执行、重放攻击、注入攻击或特权升级攻击

对反序列化的利用是有点困难的。因为在不更改或调整底层可被利用代码的情况下，现场的反序列化漏洞很难被使用

可能的两种主要攻击类型：

• 如果应用中存在可以在反序列化过程中或者之后被改变行为的类，则攻击者可以通过改变应用逻辑或者实现远程代码执行攻击。我们将其称为对象和数据结构攻击
• 典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化

防护方案

1、对数据对象签名，并作完整检查

2、数据对象中的数据做严格的类型检查，限制一部分恶意攻击

3、隔离反序列化操作环境

A9 使用含有已知漏洞的组件

组件（库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响

对于一些漏洞很容易找到其利用程序，但对其他的漏洞则需要定制开发

这种安全漏洞普遍存在。基于组件开发的模式使得多数开发团队根本不了解其应用或API中使用的组件，更谈不上及时更新这些组件了

经常爆出漏洞的组件：

• Weblogic
• Strust-2

防护方案

1、及时更新、修复组件漏洞

2、移除不再使用的依赖组件

A10 日志记录和监控不足

对于日志记录的监控不足，以及事件响应缺失或无效的集成，使得攻击者攻击系统、应用、盗取数据等操作无法被发现和追查。让其能够进一步攻击系统、保持持续性的或攻击更多的系统，以及对数据的不当操作。

防护方案

1、启用日志监控、告警机制

2、启用异地监控，C/S架构的监制机制

3、尽可能的完整记录所有日志

A11 跨站请求伪造（CSRF）

它强制终端用户在当前对其进行身份验证后（登陆 cookie session）的Web 应用程序上执行，非本意操作的攻击。 CSRF 攻击的重点在于更改状态的请求，而不是盗取数据，因为攻击者无法查看伪造请求的响应。

借助于社工的一些帮助，例如，通过电子邮件或聊天发送链接，攻击者可以诱骗用户执行攻击者选择的操作。

如果受害者是普通用户，则成功的CSRF 攻击可以强制用户执行更改状态的请求，例如转移资金、修改密码等操作。

如果受害者是管理账户，CSRF 攻击会危及整个Web 应用程序.

关键点

用户没有退出登陆

CSRF 是一种欺骗受害者提交恶意请求的攻击。它继承了受害者的身份和特权，代表受害者执行非本意 的、恶意的操作。

对于大多数站点，浏览器请求会自动发送与站点关联的所有凭据，例如用户的会话Cookie，IP 地址， Windows 域凭据等。因此，如果用户已对当前站点进行了身份验证，则该站点没有办法区分一个请求 是受害者发送的合法请求还是攻击者伪造受害者身份发送的非法请求。

目标

CSRF 的目标是更改用户账户的状态，攻击者利用CSRF 发送的请求都是更改状态的请求，比如，转账、 更改密码，购买商品等等。

CSRF 的场景中，攻击者是没有办法获得服务器的响应。

防护方案

无效的防御

• 使用秘密的Cookie
• 仅接收POST 请求（get请求容易泄露消息）
• 多步交易 （有可能被恶意攻击者预测）
• URL 重写 （用户身份信息会暴露在url中）
• HTTPS （所有安全机制的前提）

有效的防御

• 验证Referer 字段
• 添加Token 验证，可以参考dvwa csrf*别

一串随机字符串 每次客户端请求，服务器都会刷新token 服务器创建了一个token值，存储在服务器中并下发到浏览器 下次浏览器请求，需要提交该token值，服务器根据浏览器提交的token 与服务器中存储的token进行 对比， 如果二者一致说明请求是正常。 如果二者不一致说明请求可能来自恶意的攻击者 token的设计，在php中通常利用session机制

• 二次验证

在关键操作之前，再输入密码或者验证码。