安全测试 - 快速指南

---

安全测试 - 概述

安全测试对于保护系统免受网络上的恶意活动非常重要。

什么是安全测试？

安全测试是一种测试技术，用于确定信息系统是否按预期保护数据并维护功能。安全测试并不能保证系统的完全安全，但将安全测试作为测试过程的一部分很重要。

安全测试采取以下六项措施来提供安全的环境 -

• 保密性- 它可以防止信息泄露给非预期的接收者。

• 完整性- 它允许将准确且正确的所需信息从发送者传输到预期接收者。

• 身份验证- 它验证并确认用户的身份。

• 授权- 它指定对用户和资源的访问权限。

• 可用性- 确保所需信息的准备就绪。

• 不可否认性- 它确保发送者或接收者不会否认发送或接收消息。

例子

发现基于 Web 的应用程序中的安全缺陷涉及复杂的步骤和创造性思维。有时，简单的测试可能会暴露最严重的安全风险。您可以在任何网络应用程序上尝试这个非常基本的测试 -

• 使用有效凭据登录 Web 应用程序。

• 注销 Web 应用程序。

• 单击浏览器的“后退”按钮。

• 验证是否要求您再次登录或者您是否能够再次返回到登录页面。

安全测试 - 流程

安全测试可以看作是对系统的受控攻击，以现实的方式发现安全缺陷。其目标是评估 IT 系统的当前状态。它也被称为渗透测试或更通俗地称为道德黑客。

渗透测试是分阶段进行的，在本章中，我们将讨论完整的过程。应在每个阶段完成适当的记录，以便重现攻击所需的所有步骤都可以轻松获得。该文档还可作为客户在渗透测试结束时收到的详细报告的基础。

渗透测试 – 工作流程

渗透测试包括四个主要阶段 -

• 脚印
• 扫描
• 枚举
• 开发

这四个步骤会重复多次，与正常的 SDLC 齐头并进。

安全测试-恶意软件

恶意软件（恶意软件）是指向攻击者/恶意软件创建者提供部分或完全控制系统的任何软件。

恶意软件

下面列出了各种形式的恶意软件 -

• 病毒- 病毒是一种创建自身副本并将这些副本插入其他计算机程序、数据文件或硬盘引导扇区的程序。成功复制后，病毒会在受感染的主机上引发有害活动，例如窃取硬盘空间或 CPU 时间。

• 蠕虫病毒- 蠕虫病毒是一种恶意软件，它会在其路径上的每台计算机的内存中留下自身的副本。

• 特洛伊木马- 特洛伊木马是一种包含恶意代码的非自我复制类型的恶意软件，执行后会导致数据丢失或被盗或可能的系统损害。

• 广告软件- 广告软件也称为免费软件或推销软件，是一种免费计算机软件，其中包含游戏、桌面工具栏和实用程序的商业广告。它是一个基于网络的应用程序，它收集网络浏览器数据来定位广告，尤其是弹出窗口。

• 间谍软件- 间谍软件是匿名监视用户的渗透软件，使黑客能够从用户的计算机获取敏感信息。间谍软件利用用户和应用程序漏洞，这些漏洞通常附加在免费在线软件下载或用户单击的链接上。

• Rootkit - Rootkit 是黑客用来获得对计算机/网络的管理员级别访问权限的软件，该软件是通过窃取密码或在受害者不知情的情况下利用系统漏洞安装的。

预防措施

可以采取以下措施来避免系统中存在恶意软件 -

• 确保操作系统和应用程序是最新的补丁/更新。

• 切勿打开陌生的电子邮件，尤其是带有附件的电子邮件。

• 当您从互联网下载时，请务必检查您安装的内容。不要简单地单击“确定”来关闭弹出窗口。在安装应用程序之前验证发布者。

• 安装防病毒软件。

• 确保定期扫描并更新防病毒程序。

• 安装防火墙。

• 始终启用和使用浏览器和应用程序提供的安全功能。

反恶意软件

以下软件有助于从系统中删除恶意软件 -

• 微软安全必备
• 微软Windows防御者
• AVG网络安全
• Spybot - 搜索和摧毁
• 阿瓦斯特！供个人使用的家庭版
• pandas网络安全
• 适用于 Mac OS 和 Mac OS X 的 MacScan

安全测试 - HTTP 协议基础知识

了解协议对于更好地掌握安全测试非常重要。当我们截取Web服务器和客户端之间的数据包数据时，你就会体会到协议的重要性。

HTTP协议

超文本传输​​协议 (HTTP) 是分布式协作超媒体信息系统的应用程序级协议。这是自 1990 年以来万维网数据通信的基础。HTTP 是一种通用且无状态的协议，可以用于其他目的，也可以使用其请求方法、错误代码和标头的扩展。

基本上，HTTP 是基于 TCP/IP 的通信协议，用于通过 Web 传送 HTML 文件、图像文件、查询结果等数据。它为计算机之间的通信提供了一种标准化的方式。HTTP 规范指定了客户端请求的数据如何发送到服务器，以及服务器如何响应这些请求。

基本特点

以下三个基本功能使 HTTP 成为一个简单但功能强大的协议 -

• HTTP 是无连接的- HTTP 客户端（即浏览器）发起 HTTP 请求。发出请求后，客户端与服务器断开连接并等待响应。服务器处理请求并重新建立与客户端的连接以发回响应。

• HTTP 是独立于媒体的- 只要客户端和服务器都知道如何处理数据内容，任何类型的数据都可以通过 HTTP 发送。这是客户端和服务器使用适当的 MIME 类型指定内容类型所必需的。

• HTTP 是无状态的- HTTP 是无连接的，这是 HTTP 是无状态协议的直接结果。服务器和客户端仅在当前请求期间彼此了解。后来，两个人都忘记了对方。由于协议的这种性质，客户端和浏览器都无法保留网页上不同请求之间的信息。

HTTP/1.0 对每个请求/响应交换使用一个新连接，而 HTTP/1.1 连接可用于一个或多个请求/响应交换。

建筑学

下图显示了 Web 应用程序的一个非常基本的架构，并描述了 HTTP 所在的位置 -

HTTP协议是基于客户端/服务器架构的请求/响应协议，其中Web浏览器、机器人和搜索引擎等充当HTTP客户端，Web服务器充当服务器。

• 客户端- HTTP 客户端以请求方法、URI 和协议版本的形式向服务器发送请求，随后通过 TCP/IP 连接发送包含请求修饰符、客户端信息和可能的正文内容的类似 MIME 的消息。

• 服务器- HTTP 服务器使用状态行进行响应，包括消息的协议版本和成功或错误代码，后跟包含服务器信息、实体元信息和可能的实体主体内容的类似 MIME 的消息。

HTTP——缺点

• HTTP 不是一个完全安全的协议。

• HTTP 使用端口 80 作为默认通信端口。

• HTTP 运行在应用层。它需要创建多个连接来进行数据传输，这增加了管理开销。

• 使用 HTTP 不需要加密/数字证书。

HTTP 协议详细信息

为了深入了解 HTTP 协议，请单击以下每个链接。

• HTTP 参数

• HTTP消息

• HTTP 请求

• HTTP 响应

• HTTP 方法

• HTTP 状态代码

• HTTP 标头字段

• HTTP 安全

安全测试 - HTTPS 协议基础知识

HTTPS（基于安全套接字层的超文本传输​​协议）或基于 SSL 的 HTTP 是由 Netscape 开发的 Web 协议。它不是一种协议，而是在 SSL/TLS（安全套接字层/传输层安全性）之上分层 HTTP 的结果。

简而言之，HTTPS = HTTP + SSL

什么时候需要 HTTPS？

当我们浏览时，我们通常使用 HTTP 协议发送和接收信息。因此这会导致任何人窃听我们的计算机和网络服务器之间的对话。很多时候，我们需要交换敏感信息，这些信息需要受到保护并防止未经授权的访问。

https 协议用于以下场景 -

• 银行网站
• 支付网关
• 购物网站
• 所有登录页面
• 电子邮件应用程序

HTTPS 的基本工作原理

• HTTPS 协议中的服务器需要公钥和签名证书。

• 客户端请求 https:// 页面

• 使用 https 连接时，服务器通过提供网络服务器支持的加密方法列表来响应初始连接。

• 作为响应，客户端选择连接方法，并且客户端和服务器交换证书以验证其身份。

• 完成此操作后，网络服务器和客户端在确保两者使用相同的密钥后交换加密信息，并关闭连接。

• 对于托管 https 连接，服务器必须具有公钥证书，该证书嵌入密钥信息以及对密钥所有者身份的验证。

• 几乎所有证书都经过第三方验证，以便客户确信密钥始终安全。

安全测试-编码和解码

什么是编码和解码？

编码是将一系列字符（例如字母、数字和其他特殊字符）转换为专用格式以进行有效传输的过程。

解码是将编码格式转换回原始字符序列的过程。它与我们通常误解的加密完全不同。

编码和解码用于数据通信和存储。编码不应用于传输敏感信息。

网址编码

URL 只能使用 ASCII 字符集通过 Internet 发送，并且在某些情况下，URL 包含除 ASCII 字符之外的特殊字符，需要对其进行编码。URL 不包含空格，并替换为加号 (+) 或 %20。

ASCII 编码

浏览器（客户端）将根据网页中使用的字符集对输入进行编码，HTML5 中的默认字符集是 UTF-8。

下表显示了字符的 ASCII 符号及其等价符号以及最终可在将 URL 传递到服务器之前在 URL 中使用的替换符号 -

安全测试-密码学

什么是密码学？

密码学是加密和解密数据的科学，使用户能够存储敏感信息或通过不安全的网络传输信息，以便只能由目标接收者读取。

无需任何特殊措施即可读取和理解的数据称为明文，而对明文进行伪装以隐藏其实质内容的方法称为加密。

加密的明文称为密文，将加密数据恢复为明文的过程称为解密。

• 分析和破解安全通信的科学称为密码分析。执行相同操作的人也称为攻击者。

• 密码学可以是强的，也可以是弱的，强度是通过恢复实际明文所需的时间和资源来衡量的。

• 因此，需要适当的解码工具来破译强加密消息。

• 有一些可用的加密技术，即使十亿台计算机每秒执行十亿次检查，也不可能破译文本。

• 随着计算能力日益增强，人们必须使加密算法变得非常强大，以保护数据和关键信息免受攻击者的侵害。

加密是如何工作的？

密码算法与密钥（可以是单词、数字或短语）结合使用来加密明文，相同的明文使用不同的密钥加密为不同的密文。

因此，加密数据完全依赖于密码算法的强度和密钥的保密性等参数对。

密码技术

对称加密- 传统密码学，也称为常规加密，是一种仅使用一个密钥进行加密和解密的技术。例如，DES、三重 DES 算法、IBM 的 MARS、RC2、RC4、RC5、RC6。

非对称加密- 它是公钥加密，使用一对密钥进行加密：用于加密数据的公钥和用于解密的私钥。公钥公开给人们，同时私钥保密。例如，RSA、数字签名算法 (DSA)、Elgamal。

散列- 散列是单向加密，它会创建无法逆转或至少无法轻易逆转的加扰输出。例如MD5算法。它用于创建数字证书、数字签名、密码存储、通信验证等。

安全测试 - 同源策略

同源策略 (SOP) 是 Web 应用程序安全模型中的一个重要概念。

什么是同源政策？

根据此策略，它允许脚本在源自同一站点的页面上运行，该站点可以是以下内容的组合 -

• 领域
• 协议
• 港口

例子

这种Behave背后的原因是安全。如果您在一个窗口中有try.com ，而在另一个窗口中有gmail.com，那么您不希望来自 try.com 的脚本代表您访问或修改 gmail.com 的内容或在 gmail 上下文中运行操作。

以下是来自同一来源的网页。如前所述，同源考虑了域/协议/端口。

• http://website.com
• http://website.com/
• http://website.com/my/contact.html

以下是来自不同来源的网页。

• http://www.site.co.uk（另一个域）
• http://site.org（另一个域）
• https://site.com（另一个协议）
• http://site.com:8080（另一个端口）

IE 的同源策略例外

Internet Explorer 对于 SOP 有两个主要例外。

• 第一个与“受信任区域”有关。如果两个域都位于高度受信任的区域中，则同源策略不完全适用。

• IE 中的第二个例外与端口有关。IE 不将端口纳入同源策略，因此 http://website.com 和 http://wesite.com:4444 被视为来自同一来源，并且不应用任何限制。

安全测试 - Cookie

什么是 Cookie？

Cookie 是网络服务器发送的一小段信息，存储在网络浏览器上，以便浏览器稍后可以读取。这样，浏览器就会记住一些特定的个人信息。如果黑客掌握了 cookie 信息，可能会导致安全问题。

Cookie 的属性

以下是 cookie 的一些重要属性 -

• 它们通常是小文本文件，带有存储在计算机浏览器目录中的 ID 标签。

• Web 开发人员使用它们来帮助用户有效地浏览其网站并执行某些功能。

• 当用户再次浏览同一网站时，cookie中存储的数据将被发送回网络服务器，以通知网站用户之前的活动。

• 对于拥有庞大数据库、需要登录、具有可定制主题的网站来说，Cookie 是不可避免的。

Cookie 内容

cookie 包含以下信息 -

• 发送 cookie 的服务器的名称。
• cookie 的生命周期。
• 一个值 - 通常是随机生成的唯一数字。

Cookie 的类型

• 会话 Cookie - 这些 Cookie 是临时的，当用户关闭浏览器时会被删除。即使用户再次登录，也会为该会话创建一个新的 cookie。

• 持久 cookie - 这些 cookie 保留在硬盘驱动器上，除非用户将其擦除或过期。Cookie 的有效期取决于它们可以持续多长时间。

测试 Cookie

以下是测试 cookie 的方法 -

• 禁用 Cookie - 作为测试人员，我们需要在禁用 Cookie 后验证网站的访问并检查页面是否正常工作。导航到网站的所有页面并观察应用程序崩溃情况。还需要告知用户需要 cookie 才能使用该网站。

• 损坏 Cookies - 另一项要执行的测试是损坏 cookie。为了做到这一点，人们必须找到网站 cookie 的位置，并使用虚假/无效数据手动编辑它，这些数据可用于从域访问内部信息，然后可用于攻击网站。

• 删除 Cookie - 删除网站的所有 cookie 并检查网站对此的反应。

• 跨浏览器兼容性- 从任何写入 cookie 的页面检查 cookie 是否在所有支持的浏览器上正确写入也很重要。

• 编辑 Cookies - 如果应用程序使用 cookie 来存储登录信息，那么作为测试人员，我们应该尝试将 cookie 或地址栏中的用户更改为另一个有效用户。编辑 cookie 不应让您登录到不同的用户帐户。

查看和编辑 Cookie

现代浏览器支持在浏览器本身内查看/编辑 cookie 信息。mozilla/chrome 有一些插件，我们可以使用它们成功地执行编辑。

• 为 Firefox 编辑 cookies 插件

• 编辑此 chrome cookie 插件

应执行以下步骤来编辑 cookie -

• 从这里下载 Chrome 插件

• 只需从 Chrome 访问“编辑此 cookie”插件即可编辑 cookie 值，如下所示。

安全测试 - 黑客 Web 应用程序

我们可以使用多种方法作为执行攻击的参考。

Web 应用程序 - 渗透测试方法

在开发攻击模型时可以考虑以下标准。

以下列表中，OWASP 最为活跃，贡献者也不少。我们将重点关注每个开发团队在设计 Web 应用程序之前都会考虑的 OWASP 技术。

• PTES - 渗透测试执行标准

• OSSTMM - 开源安全测试方法手册

• OWASP 测试技术 - 开放 Web 应用程序安全协议

OWASP 前 10 名

开放Web应用安全协议团队发布了近年来Web中较为普遍的十大漏洞。以下是基于 Web 的应用程序中更常见的安全缺陷列表。

应用 - 实践

为了理解每一项技术，让我们使用一个示例应用程序。我们将对“WebGoat”进行攻击，该 J2EE 应用程序是出于学习目的而明确开发的，存在安全缺陷。

有关 webgoat 项目的完整详细信息可以位于https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project。要下载 WebGoat 应用程序，请导航至https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0)并转到下载部分。

要安装下载的应用程序，首先确保端口 8080 上没有运行任何应用程序。只需使用一个命令 - java -jar WebGoat-6.0.1-war-exec.jar 即可安装它。更多详情请访问WebGoat安装

安装后，我们应该能够通过导航到http://localhost:8080/WebGoat/attack来访问该应用程序，页面将显示如下。

我们可以使用登录页面中显示的访客或管理员的凭据。

网络代理

为了拦截客户端（浏览器）和服务器（在我们的案例中托管 Webgoat 应用程序的系统）之间的流量，我们需要使用 Web 代理。我们将使用 Burp Proxy，可以从https://portswigger.net/burp/download.html下载

如果您下载 burp suite 的免费版本就足够了，如下所示。

配置 Burp Suite

Burp Suite 是一个 Web 代理，可以拦截浏览器和 Web 服务器发送和接收的每个信息包。这有助于我们在客户端将信息发送到 Web 服务器之前修改内容。

步骤 1 - 应用程序安装在端口 8080 上，Burp 安装在端口 8181 上，如下所示。启动 Burp suite 并进行以下设置，以便在端口 8181 中启动它，如下所示。

步骤 2 - 我们应该确保 Burp 正在侦听安装应用程序的端口#8080，以便 Burp 套件可以拦截流量。此设置应在 Burp Suite 的范围选项卡上完成，如下所示。

步骤 3 - 然后进行浏览器代理设置以侦听端口 8181（Burp Suite 端口）。因此，我们配置了 Web 代理来拦截客户端（浏览器）和服务器（Web 服务器）之间的流量，如下所示 -

步骤 4 - 配置快照如下所示，并借助简单的工作流程图，如下所示

安全测试-注入

注入技术包括使用应用程序的输入字段注入 SQL 查询或命令。

Web 应用程序 - 注入

成功的 SQL 注入可以读取、修改数据库中的敏感数据，也可以从数据库中删除数据。它还使黑客能够对数据库执行管理操作，例如关闭 DBMS/删除数据库。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

该应用程序在构建以下易受攻击的 SQL 调用时使用不受信任的数据 -

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

动手实践

步骤 1 - 导航到应用程序的 SQL 注入区域，如下所示。

步骤 2 - 如练习中所示，我们使用字符串 SQL 注入来绕过身份验证。使用 SQL 注入以老板（'Neville'）身份登录，而无需使用正确的密码。验证 Neville 的个人资料是否可以查看以及所有功能是否可用（包括搜索、创建和删除）。

步骤 3 - 我们将注入 SQL，以便我们能够通过发送参数“a”=“a”或 1 = 1 来绕过密码

第 4 步- 漏洞利用后，我们能够以管理员 Neville 身份登录，如下所示。

防止SQL注入

有很多方法可以防止 SQL 注入。开发人员编写代码时，应确保相应地处理特殊字符。OWASP 提供了备忘单/预防技术，这绝对是开发人员的指南。

• 使用参数化查询
• 转义所有用户提供的输入
• 为最终用户启用数据库的最小权限

测试损坏的身份验证

当与应用程序相关的身份验证功能未正确实现时，黑客就可以破解密码或会话 ID，或者使用其他用户凭据来利用其他实现缺陷。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

该网站经过身份验证的用户会将 URL 转发给他们的朋友，以了解折扣销售情况。他通过电子邮件发送了上述链接，但并不知道用户也泄露了会话 ID。当他的朋友使用该链接时，他们使用他的会话和信用卡。

动手

步骤 1 - 登录 Webgoat 并导航至“会话管理缺陷”部分。让我们通过欺骗 cookie 来绕过身份验证。下面是该场景的快照。

步骤 2 - 当我们使用凭证 webgoat/webgoat 登录时，我们从 Burp Suite 中发现 JSESSION ID 为 C8F3177CCAFF380441ABF71090748F2E，而身份验证成功后 AuthCookie = 65432ubphcf​​x。

步骤 3 - 当我们使用凭据方面/方面登录时，我们从 Burp Suite 中发现 JSESSION ID 为 C8F3177CCAFF380441ABF71090748F2E，而身份验证成功后 AuthCookie = 65432udfqtb。

步骤 4 - 现在我们需要分析 AuthCookie 模式。前半部分“65432”对于两种身份验证都是通用的。因此，我们现在有兴趣分析 authcookie 值的最后部分，例如分别用于 webgoat 用户的 ubphcf​​x 和用于方面用户的 udfqtb。

步骤 5 - 如果我们深入查看 AuthCookie 值，最后一部分的长度与用户名的长度相同。因此，很明显该用户名使用了某种加密方法。经过试错/暴力破解机制，我们发现在逆转用户名webgoat后；我们最终得到 taogbew，然后前面的字母字符被用作 AuthCookie。即 ubphcf​​x。

步骤 6 - 如果我们传递这个 cookie 值，让我们看看会发生什么。以用户 webgoat 身份进行身份验证后，通过执行步骤#4 和步骤#5 查找相同的 AuthCookie，更改 AuthCookie 值以模拟用户 Alice。

预防机制

• 开发强大的身份验证和会话管理控制，使其满足 OWASP 应用程序安全验证标准中定义的所有身份验证和会话管理要求。

• 开发人员应确保避免可用于窃取会话 ID 的 XSS 缺陷。

测试跨站脚本

每当应用程序获取不受信任的数据并将其发送到客户端（浏览器）而不进行验证时，就会发生跨站点脚本（XSS）。这使得攻击者可以在受害者的浏览器中执行恶意脚本，从而导致用户会话劫持、破坏网站或将用户重定向到恶意网站。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

XSS 的类型

• 存储型 XSS - 当用户输入存储在目标服务器（例如数据库/消息论坛/评论字段等）上时，存储型 XSS 也称为持久型 XSS。然后受害者能够从 Web 应用程序检索存储的数据。

• 反射型 XSS - 当 Web 应用程序立即在错误消息/搜索结果中返回用户输入或用户作为请求的一部分提供的输入且不永久存储用户提供的数据时，会发生反射型 XSS 也称为非持久性 XSS 。

• 基于 DOM 的 XSS - 基于 DOM 的 XSS 是 XSS 的一种形式，数据源位于 DOM 中，接收器也在 DOM 中，并且数据流永远不会离开浏览器。

例子

该应用程序在构建过程中使用了不可信的数据，且未经验证。特殊字符应该被转义。

http://www.webpage.org/task/Rule1?query=try

攻击者将浏览器中的查询参数修改为 -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

动手

步骤 1 - 登录 Webgoat 并导航至跨站脚本 (XSS) 部分。让我们执行存储跨站脚本 (XSS) 攻击。下面是该场景的快照。

步骤 2 - 根据场景，让我们以 Tom 身份登录，密码为“tom”，如场景本身所述。单击“查看个人资料”并进入编辑模式。由于 Tom 是攻击者，让我们将 Java 脚本注入到这些编辑框中。

<script> 
   alert("HACKED")
</script> 

步骤 3 - 更新结束后，汤姆会收到一个警告框，其中显示消息“已被黑客攻击”，这意味着该应用程序容易受到攻击。

步骤 4 - 现在根据场景，我们需要以 jerry (HR) 身份登录并检查 jerry 是否受到注入脚本的影响。

步骤 5 - 以 Jerry 身份登录后，选择“Tom”并单击“查看个人资料”，如下所示。

当从杰瑞的帐户查看汤姆的个人资料时，他能够看到相同的消息框。

步骤 6 - 此消息框只是一个示例，但实际攻击者可以执行的不仅仅是显示消息框。

预防机制

• 开发人员必须确保根据 HTML 上下文（例如数据所在的正文、属性、JavaScript、CSS 或 URL）转义所有不受信任的数据。

• 对于那些需要特殊字符作为输入的应用程序，在接受它们作为有效输入之前应该有强大的验证机制。

不安全的直接对象引用

当开发人员公开对内部实现对象（例如文件、目录或数据库密钥）的引用而没有任何验证机制（允许攻击者操纵这些引用来访问未经授权的数据）时，可能会发生直接对象引用。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

该应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据。

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

攻击者修改浏览器中的查询参数以指向 Admin。

http://webapp.com/app/accountInfo?acct=admin

动手

步骤 1 - 登录 Webgoat 并导航至访问控制缺陷部分。目标是通过导航到 tomcat-users.xml 所在的路径来检索它。下面是该场景的快照。

步骤 2 - 文件的路径显示在“当前目录是”字段中 - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en，我们还知道 tomcat-users.xml 文件是保存在 C:\xampp\tomcat\conf 下

步骤 3 - 我们需要一直遍历当前目录并从 C:\ Drive 导航。我们可以通过使用 Burp Suite 拦截流量来执行相同的操作。

步骤 4 - 如果尝试成功，则会显示 tomcat-users.xml 并显示消息“恭喜。您已成功完成本课程。”

预防机制

开发人员可以使用以下资源/要点作为指南，以防止在开发阶段本身出现不安全的直接对象引用。

• 开发人员应该仅使用一个用户或会话来进行间接对象引用。

• 还建议在使用来自不受信任源的直接对象引用之前检查访问权限。

安全配置错误

当安全设置被定义、实施和维护为默认值时，就会出现安全配置错误。良好的安全性需要为应用程序、Web 服务器、数据库服务器和平台定义和部署安全配置。使软件保持最新状态也同样重要。

例子

安全配置错误的一些经典示例如下：

• 如果服务器上未禁用目录列表，并且攻击者发现相同的内容，则攻击者可以简单地列出目录以查找任何文件并执行它。还可以获取包含所有自定义代码的实际代码库，然后找到应用程序中的严重缺陷。

• 应用程序服务器配置允许将堆栈跟踪返回给用户，这可能会暴露潜在的缺陷。攻击者获取错误消息提供的额外信息，这些信息足以让他们渗透。

• 应用程序服务器通常附带安全性不佳的示例应用程序。如果不从生产服务器中删除，将导致您的服务器受到损害。

动手

步骤 1 - 启动 Webgoat 并导航到不安全的配置部分，让我们尝试解决该挑战。下面提供了相同的快照 -

步骤 2 - 我们可以尝试尽可能多的选择。我们只需要找到配置文件的 URL，并且我们知道开发人员遵循配置文件的命名约定。它可以是下面列出的任何内容。它通常是通过暴力技术来完成的。

• 网络配置
• 配置
• 应用程序名称.config
• 会议

步骤 3 - 尝试各种选项后，我们发现“ http://localhost:8080/WebGoat/conf ”成功。如果尝试成功，将显示以下页面 -

预防机制

• 所有环境（例如开发、QA 和生产环境）都应使用每个环境中使用的不同密码进行相同的配置，以免轻易被黑客攻击。

• 确保采用强大的应用程序架构，在组件之间提供有效、安全的分离。

• 它还可以通过运行自动扫描和定期进行审核来最大限度地减少这种攻击的可能性。

安全测试-敏感数据暴露

随着在线应用程序日益充斥互联网，并非所有应用程序都是安全的。许多 Web 应用程序无法正确保护敏感的用户数据，例如信用卡信息/银行帐户信息/身份验证凭据。黑客最终可能会窃取这些保护薄弱的数据，以进行信用卡欺诈、身份盗窃或其他犯罪。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

安全配置错误的一些经典示例如下：

• 站点根本不会对所有经过身份验证的页面使用 SSL。这使得攻击者能够监视网络流量并窃取用户的会话 cookie 以劫持用户会话或访问其私人数据。

• 应用程序以加密格式将信用卡号存储在数据库中。检索后，它们会被解密，从而允许黑客执行 SQL 注入攻击，以明文形式检索所有敏感信息。可以通过使用公钥加密信用卡号并允许后端应用程序使用私钥对其进行解密来避免这种情况。

动手

步骤 1 - 启动 WebGoat 并导航至“不安全存储”部分。下面显示了相同的快照。

步骤 2 - 输入用户名和密码。现在是学习我们之前讨论的不同类型的编码和加密方法的时候了。

预防机制

• 建议不要存储不必要的敏感数据，如果不再需要，应尽快删除。

• 重要的是要确保我们采用强大且标准的加密算法，并采取适当的密钥管理。

• 还可以通过禁用收集密码等敏感数据的表单上的自动完成功能并禁用包含敏感数据的页面的缓存来避免这种情况。

缺少功能级别访问控制

大多数 Web 应用程序在使用户可以访问该功能之前都会验证功能级别的访问权限。但是，如果不在服务器上执行相同的访问控制检查，黑客就能够在未经适当授权的情况下渗透到应用程序中。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

这是缺少功能级别访问控制的典型示例 -

黑客只是强制目标 URL。通常管理员访问需要身份验证，但是，如果应用程序访问未经验证，则未经身份验证的用户可以访问管理页面。

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

动手

步骤 1 - 让我们以帐户经理身份登录，首先浏览用户列表及其访问权限。

步骤 2 - 尝试各种组合后，我们可以发现 Larry 可以访问资源帐户管理器。

预防机制

• 身份验证机制应默认拒绝所有访问，并为每个功能提供对特定角色的访问。

• 在基于工作流的应用程序中，在允许用户访问任何资源之前验证用户的状态。

跨站请求伪造（CSRF）

CSRF 攻击迫使经过身份验证的用户（受害者）向易受攻击的 Web 应用程序发送伪造的 HTTP 请求，包括受害者的会话 cookie，这使得攻击者可以强制受害者的浏览器生成请求，从而使易受攻击的应用程序将其视为来自攻击者的合法请求。受害者。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

这是 CSRF 的经典示例 -

步骤 1 - 假设易受攻击的应用程序以未加密的纯文本形式发送状态更改请求。

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

步骤 2 - 现在，黑客构建了一个请求，通过将请求嵌入到存储在攻击者控制下的各个站点上的图像中，将资金从受害者的帐户转移到攻击者的帐户 -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

动手

步骤 1 - 让我们通过将 Java 脚本嵌入到图像中来执行 CSRF 伪造。下面列出了问题的快照。

步骤 2 - 现在我们需要将传输模拟为 1x1 图像，并让受害者点击相同的图像。

步骤 3 - 提交消息后，消息将显示如下突出显示。

步骤 4 - 现在，如果受害者单击以下 URL，则会执行传输，可以发现使用 burp suite 拦截用户操作。我们可以通过在“获取消息”中发现传输来查看传输，如下所示 -

步骤 5 - 现在单击刷新后，将显示课程完成标记。

预防机制

• 可以通过在隐藏字段中创建唯一令牌来避免 CSRF，该令牌将在 HTTP 请求正文中发送，而不是在 URL 中发送，后者更容易暴露。

• 强制用户重新进行身份验证或证明自己是用户，以保护 CSRF。例如，验证码。

有漏洞的组件

当应用程序中使用的库和框架等组件几乎总是以完全权限执行时，就会发生这种威胁。如果易受攻击的组件被利用，黑客就更容易造成严重的数据丢失或服务器接管。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

以下示例是使用具有已知漏洞的组件 -

• 攻击者可以通过不提供身份令牌来调用具有完全权限的任何 Web 服务。

• 通过基于 Java 的应用程序的 Spring 框架引入了带有表达式语言注入漏洞的远程代码执行。

预防机制

• 识别网络应用程序中使用的所有组件和版本，而不仅仅是数据库/框架。

• 使所有组件（例如公共数据库、项目邮件列表等）保持最新。

• 在本质上易受攻击的组件周围添加安全包装器。

未经验证的重定向和转发

互联网上的大多数 Web 应用程序经常将用户重定向和转发到其他页面或其他外部网站。然而，在不验证这些页面的可信度的情况下，黑客可以将受害者重定向到网络钓鱼或恶意软件网站，或使用转发来访问未经授权的页面。

让我们借助简单的图表了解该缺陷的威胁代理、攻击向量、安全弱点、技术影响和业务影响。

例子

未经验证的重定向和转发的一些经典示例如下 -

• 假设应用程序有一个页面 -redirect.jsp，它采用参数redirectrul。黑客添加恶意 URL，重定向执行网络钓鱼/安装恶意软件的用户。

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

• 所有网络应用程序用于将用户转发到网站的不同部分。为了实现相同的目的，某些页面使用参数来指示如果操作成功，用户应该重定向到哪里。攻击者制作一个通过应用程序访问控制检查的 URL，然后将攻击者转发到攻击者尚未获得访问权限的管理功能。

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

预防机制

• 最好避免使用重定向和转发。

• 如果这是不可避免的，那么应该在重定向目的地时不涉及用户参数。

AJAX 安全

异步 Javascript 和 XML (AJAX) 是用于开发 Web 应用程序以提供丰富的用户体验的最新技术之一。由于它是一项新技术，因此还有许多安全问题尚未完全确定，下面是 AJAX 中的几个安全问题。

• 由于需要保护的输入越多，攻击面就越大。

• 它还公开了应用程序的内部功能。

• 无法保护身份验证信息和会话。

• 客户端和服务器端之间的界限非常窄，因此存在犯安全错误的可能性。

例子

这是 AJAX 安全性的示例 -

2006 年，蠕虫利用 XSS 和 AJAX 感染了雅虎邮件服务，该服务利用了雅虎邮件 onload 事件处理中的漏洞。当打开受感染的电子邮件时，蠕虫会执行 JavaScript，向受感染用户的所有雅虎联系人发送一份副本。

动手

步骤 1 - 我们需要尝试使用 XML 注入向您允许的奖励集中添加更多奖励。下面是该场景的快照。

步骤 2 - 确保我们使用 Burp Suite 拦截请求和响应。设置相同如下图所示。

步骤 3 - 输入场景中给出的帐号。我们将能够获得我们有资格获得的所有奖励的列表。我们有资格获得 5 项奖励中的 3 项。

步骤 4 - 现在让我们单击“提交”并查看响应 XML 中得到的内容。如下所示，我们有资格获得的三个奖励以 XML 形式传递给我们。

步骤 5 - 现在让我们编辑这些 XML 并添加其他两个奖励。

步骤 6 - 现在所有奖励将显示给用户供他们选择。选择我们添加的并单击“提交”。

步骤 7 - 将显示以下消息：“* 恭喜。您已成功完成本课程。”

预防机制

客户端 -

• 使用 .innerText 而不是 .innerHtml。
• 不要使用评估。
• 不要依赖客户端逻辑来确保安全。
• 避免编写序列化代码。
• 避免动态构建 XML。
• 切勿将秘密传输给客户。
• 不要在客户端代码中执行加密。
• 不要在客户端执行影响安全的逻辑。

服务器端 -

• 使用 CSRF 保护。
• 避免编写序列化代码。
• 用户可以直接调用服务。
• 避免手动构建 XML，而使用框架。
• 避免手动构建 JSON，而使用现有框架。

安全测试 - Web 服务

在现代基于 Web 的应用程序中，Web 服务的使用是不可避免的，并且它们也容易受到攻击。由于 Web 服务请求从多个网站获取数据，因此开发人员必须采取一些额外措施以避免黑客的任何形式的渗透。

动手

步骤 1 - 导航到 Webgoat 的 Web 服务区域并转到 WSDL 扫描。我们现在需要获取其他帐号的信用卡详细信息。该场景的快照如下所述。

步骤 2 - 如果我们选择名字，则通过 SOAP 请求 xml 进行“getFirstName”函数调用。

步骤 3 - 通过打开 WSDL，我们可以看到有一个方法可以检索信用卡信息以及“getCreditCard”。现在让我们使用 Burp 套件篡改输入，如下所示 -

步骤 4 - 现在让我们使用 Burp 套件修改输入，如下所示 -

步骤 5 - 我们可以获得其他用户的信用卡信息。

预防机制

• 由于 SOAP 消息是基于 XML 的，因此所有传递的凭据都必须转换为文本格式。因此，在传递必须始终加密的敏感信息时必须非常小心。

• 通过实施校验和等机制来确保数据包的完整性，从而保护消息的完整性。

• 保护消息机密性 - 应用非对称加密来保护对称会话密钥，在许多实现中，对称会话密钥仅对一次通信有效，随后会被丢弃。

安全测试 - 缓冲区溢出

当程序试图在临时数据存储区域（缓冲区）中存储比预期容纳的数据更多的数据时，就会出现缓冲区溢出。由于缓冲区被创建为包含有限数量的数据，因此额外的信息可能会溢出到相邻的缓冲区中，从而破坏其中保存的有效数据。

例子

这是缓冲区溢出的经典示例。它演示了由第一个场景引起的简单缓冲区溢出，其中依赖外部数据来控制其Behave。无法限制用户输入的数据量，程序的Behave取决于用户输入的字符数量。

   ...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

动手

步骤 1 - 我们需要使用姓名和房间号登录才能访问互联网。这是场景快照。

步骤 2 - 我们还将在 Bu 中启用“取消隐藏隐藏的表单字段”