安全测试速查指南



安全测试 - 概述

安全测试对于保护系统免受网络恶意活动至关重要。

什么是安全测试?

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

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

  • 机密性 - 它防止信息泄露给意外接收者。

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

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

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

  • 可用性 - 它确保信息按需随时可用。

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

示例

发现基于Web应用程序的安全漏洞涉及复杂的步骤和创造性思维。有时,简单的测试可以暴露最严重的安全风险。您可以尝试对任何Web应用程序进行此非常基本的测试:

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

  • 注销Web应用程序。

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

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

安全测试 - 流程

安全测试可以被视为对系统的受控攻击,它以现实的方式揭示安全漏洞。其目标是评估IT系统的当前状态。它也称为渗透测试或更流行的道德黑客

渗透测试分阶段进行,本章将讨论整个过程。每个阶段都应进行适当的记录,以便随时可以使用复制攻击所需的所有步骤。该文档也作为客户在渗透测试结束时收到的详细报告的基础。

渗透测试 - 工作流程

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

这四个步骤会多次重复,这与正常的SDLC(软件开发生命周期)相辅相成。

Security Testing Process

安全测试 - 恶意软件

恶意软件(malware)是任何赋予攻击者/恶意软件创建者对系统部分或全部控制权的软件。

恶意软件

以下是各种形式的恶意软件:

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

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

  • 木马 - 木马是一种非自我复制的恶意软件,它包含恶意代码,执行该代码会导致数据丢失或被盗,或可能对系统造成损害。

  • 广告软件 - 广告软件,也称为免费软件或pitchware,是一种包含游戏、桌面工具栏和实用程序商业广告的免费计算机软件。它是一个基于Web的应用程序,它收集Web浏览器数据以定位广告,尤其是弹出式广告。

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

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

预防措施

可以采取以下措施来避免系统中出现恶意软件:

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

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

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

  • 安装防病毒软件。

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

  • 安装防火墙。

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

反恶意软件软件

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

  • Microsoft Security Essentials
  • Microsoft Windows Defender
  • AVG Internet Security
  • Spybot - Search & Destroy
  • Avast! 个人版
  • Panda Internet Security
  • MacScan for Mac OS and Mac OS X

安全测试 - HTTP协议基础

理解协议对于掌握安全测试至关重要。当我们拦截Web服务器和客户端之间的分组数据时,您将能够理解协议的重要性。

HTTP协议

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

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

基本特性

以下三个基本特性使HTTP成为一个简单而强大的协议:

  • HTTP是无连接的 - HTTP客户端(即浏览器)启动HTTP请求。发出请求后,客户端与服务器断开连接并等待响应。服务器处理请求并重新与客户端建立连接以发送响应。

  • HTTP是媒体无关的 - 只要客户端和服务器都知道如何处理数据内容,任何类型的数据都可以通过HTTP发送。这要求客户端和服务器使用适当的MIME类型来指定内容类型。

  • HTTP是无状态的 - HTTP是无连接的,这是HTTP是无状态协议的直接结果。服务器和客户端仅在当前请求期间知道彼此的存在。之后,它们都会忘记彼此。由于协议的这种性质,客户端或浏览器都不能在Web页面之间不同的请求之间保留信息。

HTTP/1.0为每次请求/响应交换使用新的连接,而HTTP/1.1连接可用于一次或多次请求/响应交换。

架构

下图显示了Web应用程序的非常基本的架构,并描述了HTTP驻留的位置:

HTTP Architecture

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

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

  • 服务器 - HTTP服务器以状态行响应,包括消息的协议版本和成功或错误代码,然后发送包含服务器信息、实体元信息和可能的实体正文内容的类似MIME的消息。

HTTP - 缺点

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

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

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

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

Http协议详情

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

安全测试 - HTTPS协议基础

HTTPS(安全套接字层上的超文本传输协议)或HTTP over SSL是由Netscape开发的一种Web协议。它不是一种协议,而只是将HTTP叠加在SSL/TLS(安全套接字层/传输层安全)之上的结果。

简而言之,HTTPS = HTTP + SSL

何时需要HTTPS?

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

Https协议用于以下场景:

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

HTTPS的基本工作原理

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

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

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

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

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

  • 要承载 https 连接,服务器必须拥有一个公钥证书,该证书嵌入了密钥信息以及对密钥所有者身份的验证。

  • 几乎所有证书都由第三方验证,以确保客户端密钥始终安全。

HTTP Architecture

安全测试 - 编码和解码

什么是编码和解码?

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

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

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

URL 编码

URL 只能使用 ASCII 字符集通过互联网发送,并且在 URL 包含 ASCII 字符以外的特殊字符的情况下,需要对其进行编码。URL 不包含空格,空格将被加号 (+) 或 %20 替换。

ASCII 编码

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

下表显示了字符的 ASCII 符号、等效符号以及最终可在传递给服务器之前用于 URL 的替换字符:

ASCII 符号 替换
< 32   使用 %xx 编码,其中 xx 是字符的十六进制表示。
32 空格 + 或 %20
33 ! %21
34 " %22
35 # %23
36 $ %24
37 % %25
38 & %26
39 ' %27
40 ( %28
41 ) %29
42 * *
43 + %2B
44 , %2C
45 - -
46 . .
47 / %2F
48 0 0
49 1 1
50 2 2
51 3 3
52 4 4
53 5 5
54 6 6
55 7 7
56 8 8
57 9 9
58 : %3A
59 ; %3B
60 > %3C
61 = %3D
62 > %3E
63 ? %3F
64 @ %40
65 A A
66 B B
67 C C
68 D D
69 E E
70 F F
71 G G
72 H H
73 I I
74 J J
75 K K
76 L L
77 M M
78 N N
79 O O
80 P P
81 Q Q
82 R R
83 S S
84 T T
85 U U
86 V V
87 W W
88 X X
89 Y Y
90 Z Z
91 [ %5B
92 \ %5C
93 ] %5D
94 ^ %5E
95 _ _
96 ` %60
97 a a
98 b b
99 c c
100 d d
101 e e
102 f f
103 g g
104 h h
105 i i
106 j j
107 k k
108 l l
109 m m
110 n n
111 o o
112 p p
113 q q
114 r r
115 s s
116 t t
117 u u
118 v v
119 w w
120 x x
121 y y
122 z z
123 { %7B
124 | %7C
125 } %7D
126 ~ %7E
127   %7F
> 127   使用 %xx 编码,其中 xx 是字符的十六进制表示

安全测试 - 密码学

什么是密码学?

密码学是加密和解密数据的科学,它使用户能够存储敏感信息或将其跨不安全网络传输,以便只有预期的接收者才能读取。

无需任何特殊措施即可读取和理解的数据称为明文,而为了隐藏其内容而伪装明文的方法称为加密

加密的明文称为密文,将加密数据转换回明文的过程称为解密

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

  • 密码学可以是强烈的或弱的,其强度取决于恢复实际明文所需的时间和资源。

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

  • 有一些密码技术,即使是十亿台计算机每秒进行十亿次检查,也不可能破译文本。

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

加密是如何工作的?

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

因此,加密数据完全取决于几个参数,例如密码算法的强度和密钥的保密性。

密码技术

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

非对称加密 - 它是公钥密码学,它使用一对密钥进行加密:一个公钥用于加密数据,一个私钥用于解密。公钥发布给公众,同时保持私钥秘密。例如,RSA、数字签名算法 (DSA)、Elgamal。

哈希 - 哈希是一种单向加密,它创建无法反转或至少不容易反转的混淆输出。例如,MD5 算法。它用于创建数字证书、数字签名、存储密码、验证通信等。

安全测试 - 同源策略

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

什么是同源策略?

根据此策略,它允许在源自同一站点的页面上运行的脚本,该站点可以是以下各项的组合:

  • 协议
  • 端口

示例

此行为背后的原因是安全。如果您在一个窗口中拥有 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 是 Web 服务器发送的一小段信息,用于存储在 Web 浏览器中,以便稍后浏览器可以读取它。通过这种方式,浏览器会记住一些特定的个人信息。如果黑客获得了 Cookie 信息,则可能导致安全问题。

Cookie 的属性

以下是 Cookie 的一些重要属性:

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

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

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

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

Cookie 内容

Cookie 包含以下信息:

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

Cookie 的类型

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

  • 持久性 Cookie - 除非用户将其清除或它们过期,否则这些 Cookie 将保留在硬盘驱动器上。Cookie 的过期时间取决于它们可以持续多长时间。

Cookie 测试

以下是测试 Cookie 的方法:

  • 禁用 Cookie - 作为测试人员,我们需要在禁用 Cookie 后验证网站的访问权限,并检查页面是否正常工作。导航到网站的所有页面并注意应用程序崩溃。还需要通知用户需要 Cookie 才能使用该站点。

  • 破坏 Cookie - 另一个要执行的测试是通过破坏 Cookie 来进行。为了做到这一点,必须找到站点 Cookie 的位置,并使用虚假/无效数据手动编辑它,这些数据可用于访问域中的内部信息,进而可用于入侵站点。

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

  • 跨浏览器兼容性 - 还必须检查 Cookie 是否已从写入 Cookie 的任何页面在所有受支持的浏览器上正确写入。

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

查看和编辑 Cookie

现代浏览器支持在浏览器本身内查看/编辑 Cookie 信息。有一些适用于 Mozilla/Chrome 的插件,我们可以使用这些插件成功执行编辑。

  • Firefox 的编辑 Cookie 插件

  • Chrome 的编辑此 Cookie 插件

应执行以下步骤来编辑 Cookie:

  • 从此处下载 Chrome 的插件:此处

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

Cookie Testing

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

我们可以使用各种方法/途径作为执行攻击的参考。

Web 应用 -渗透测试方法

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

在以下列表中,OWASP 最活跃,并且有许多贡献者。我们将重点关注 OWASP 技术,每个开发团队在设计 Web 应用之前都会考虑这些技术。

OWASP Top 10

开放 Web 应用安全项目团队发布了近年来 Web 应用中更普遍存在的十大漏洞。以下是 Web 应用中更普遍存在的安全缺陷列表。

OWASP Top 10

应用 - 实操

为了理解每种技术,让我们使用一个示例应用程序。我们将对“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 安装

安装后,我们应该可以通过导航到 https://127.0.0.1:8080/WebGoat/attack 来访问该应用程序,页面将如下所示。

OWASP Top 10

我们可以使用登录页面中显示的 guest 或 admin 凭据。

Web 代理

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

下载 Burp Suite 的免费版本就足够了,如下所示。

BURP Suite Download.

配置 Burp Suite

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

BURP Suite Download.

步骤 1 - 应用安装在 8080 端口,Burp 安装在 8181 端口,如下所示。启动 Burp Suite 并进行以下设置,以便在 8181 端口启动它,如下所示。

BURP Suite Download.

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

BURP Suite Download.

步骤 3 - 然后将您的浏览器代理设置设置为监听 8181 端口(Burp Suite 端口)。因此,我们已配置 Web 代理以拦截客户端(浏览器)和服务器(Web 服务器)之间的流量,如下所示 -

BURP Suite Download.

步骤 4 - 使用简单的流程图显示配置的快照,如下所示

BURP Suite Download.

安全测试 - 注入攻击

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

Web 应用 - 注入

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

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

SQL Injection

示例

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

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

实操

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

SQL Injection

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

步骤 3 - 我们将注入一个 SQL,以便我们能够通过将参数发送为 'a' = 'a' 或 1 = 1 来绕过密码。

SQL Injection

步骤 4 - 利用完成后,我们能够以 Neville(管理员)的身份登录,如下所示。

SQL Injection

防止 SQL 注入

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

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

测试身份验证漏洞

当与应用程序相关的身份验证功能未正确实现时,它允许黑客泄露密码或会话 ID,或使用其他用户的凭据利用其他实现缺陷。

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

2.Broken Auth and Session Mgmt Flaws

示例

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.Broken Auth and Session Mgmt Flaws

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

2.Broken Auth and Session Mgmt Flaws

2.Broken Auth and Session Mgmt Flaws

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

2.Broken Auth and Session Mgmt Flaws

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

步骤 5 - 如果我们仔细查看 AuthCookie 值,最后一部分与用户名长度相同。因此,很明显用户名使用了某种加密方法。通过反复试验/暴力破解机制,我们发现反转用户名 webgoat 后,我们得到 taogbew,然后使用之前的字母字符作为 AuthCookie,即 ubphcfx。

步骤 6 - 如果我们传递此 cookie 值,让我们看看会发生什么。在以 webgoat 用户身份进行身份验证后,通过执行步骤 4 和步骤 5 为用户 Alice 查找 AuthCookie 来更改 AuthCookie 值以模拟用户 Alice。

2.Broken Auth and Session Mgmt Flaws

2.Broken Auth and Session Mgmt Flaws

预防机制

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

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

测试跨站点脚本

跨站点脚本 (XSS) 发生在应用程序获取不受信任的数据并将其发送到客户端(浏览器)而无需验证时。这允许攻击者在受害者的浏览器中执行恶意脚本,这可能导致用户会话被劫持、网站被篡改或用户被重定向到恶意网站。

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

3. cross site scripting

XSS 类型

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

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

  • 基于 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) 攻击。以下是场景的快照。

3. xss

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

<script> 
   alert("HACKED")
</script> 
3. xss

步骤 3 - 更新完成后,Tom 收到一个带有“hacked”消息的警报框,这意味着该应用程序存在漏洞。

3. xss

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

3. xss

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

3. xss

从 Jerry 的帐户查看 Tom 的个人资料时,他能够获得相同的对话框。

3. xss

步骤 6 - 此消息框只是一个示例,但实际攻击者可以执行比仅显示消息框更多的事情。

预防机制

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

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

不安全的直接对象引用

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

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

insecure direct obj ref

示例

该应用程序在访问帐户信息时使用未经验证的数据进行 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。以下是场景的快照。

1. insecure direct obj ref1

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

步骤 3 - 我们需要遍历当前目录的所有路径并从 C:\ 驱动器导航。我们可以使用 Burp Suite 拦截流量来执行此操作。

2 insecure direct obj ref

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

2 insecure direct obj ref

预防机制

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

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

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

安全错误配置

安全错误配置是指安全设置的定义、实现和维护使用默认值的情况。良好的安全措施要求为应用程序、Web服务器、数据库服务器和平台定义和部署安全的配置。软件保持最新同样重要。

security_misconfiguration

示例

一些典型的安全错误配置示例如下:

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

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

  • 应用程序服务器通常附带安全性不足的示例应用程序。如果未从生产服务器中删除,则会导致服务器受到攻击。

实操

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

security_misconfiguration1

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

  • web.config
  • config
  • appname.config
  • conf

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

security_misconfiguration1

预防机制

  • 所有环境(例如开发、QA 和生产环境)都应使用每个环境中使用的不同密码进行相同配置,这些密码不易被破解。

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

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

安全测试 - 敏感数据泄露

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

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

sensitive_data_exposture

示例

一些典型的安全错误配置示例如下:

  • 某个网站只是没有为所有已验证页面使用 SSL。这使攻击者能够监控网络流量并窃取用户的会话 Cookie 来劫持用户会话或访问其私人数据。

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

实操

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

insecure_storage_1

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

预防机制

  • 建议不要不必要地存储敏感数据,如果不再需要,应尽快将其清除。

  • 务必确保我们结合使用强大且标准的加密算法,并到位适当的密钥管理。

  • 还可以通过禁用收集敏感数据(如密码)的表单上的自动填充功能以及禁用包含敏感数据的页面的缓存来避免这种情况。

缺少函数级访问控制

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

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

missing_fn_level_access_control

示例

这是一个缺少函数级访问控制的典型示例:

黑客只需强制目标 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 - 让我们首先查看用户及其访问权限列表,然后以帐户管理员身份登录。

missing_fn_level_access_control1

步骤 2 - 通过尝试各种组合,我们可以发现 Larry 可以访问资源帐户管理员。

missing_fn_level_access_control1

预防机制

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

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

跨站点请求伪造 (CSRF)

CSRF 攻击会强制经过身份验证的用户(受害者)发送伪造的 HTTP 请求,包括受害者的会话 Cookie 到易受攻击的 Web 应用程序,这允许攻击者强制受害者的浏览器生成请求,以便易受攻击的应用程序将其视为来自受害者的合法请求。

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

csrf

示例

这是一个 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 - 让我们通过将 JavaScript 嵌入图像来执行 CSRF 伪造。问题的快照列在下面。

csrf1

步骤 2 - 现在我们需要将转移模拟到一个 1x1 的图像中,并让受害者点击它。

csrf2

步骤 3 - 提交消息后,消息将显示如下所示:

csrf3

步骤 4 - 现在,如果受害者点击以下 URL,则会执行转移,这可以通过使用 burp suite 拦截用户操作来找到。我们可以通过在 Get 消息中发现它来查看转移,如下所示:

csrf3

步骤 5 - 现在点击刷新,就会显示课程完成标记。

预防机制

  • 可以通过在隐藏字段中创建一个唯一令牌来避免 CSRF,该令牌将发送在 HTTP 请求的主体中,而不是在更容易暴露的 URL 中。

  • 强制用户重新进行身份验证或证明他们是用户以保护 CSRF。例如,CAPTCHA。

存在漏洞的组件

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

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

using_components_with_known_vulnerabilities

示例

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

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

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

预防机制

  • 识别 Web 应用程序中使用的所有组件及其版本,而不仅仅限于数据库/框架。

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

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

未验证的重定向和转发

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

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

unvalidated_redirects_and_forwards

示例

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

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

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com
  • 所有 Web 应用程序都用于将用户转发到站点的不同部分。为了实现相同的目的,某些页面使用参数来指示如果操作成功,则应将用户重定向到的位置。攻击者会创建一个 URL,该 URL 通过应用程序的访问控制检查,然后将攻击者转发到攻击者无权访问的管理功能。

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

预防机制

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

  • 如果不可避免,则应在不涉及用户参数重定向目标的情况下进行。

AJAX 安全性

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

  • 攻击面更大,因为需要保护更多输入。

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

  • 未能保护身份验证信息和会话。

  • 客户端和服务器端之间只有一条非常细的界限,因此有可能犯下安全错误。

示例

这是一个 AJAX 安全性的示例:

2006 年,蠕虫病毒利用 XSS 和 AJAX 感染了雅虎邮件服务,利用了雅虎邮件的 onload 事件处理中的漏洞。当打开受感染的电子邮件时,蠕虫会执行其 JavaScript,将其副本发送给受感染用户的全部雅虎联系人。

实操

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

xml_injection

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

burp_settings

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

xml_injection1

步骤 4 - 现在让我们点击“提交”,看看我们在响应 XML 中得到了什么。如下所示,我们有资格获得的三个奖励作为 XML 传递给我们。

xml_injection2

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

xml_injection3

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

xml_injection4

步骤 7 - 将出现以下消息:“*恭喜。您已成功完成本课程。*

预防机制

客户端 -

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

服务器端 -

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

安全测试 - Web 服务

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

实操

步骤 1 − 导航到 Webgoat 的 Web 服务区域,然后进入 WSDL 扫描。我们现在需要获取其他帐户的信用卡详细信息。场景快照如下所示。

web_services

步骤 2 − 如果我们选择名字,则会通过 SOAP 请求 xml 调用 'getFirstName' 函数。

web_services1

步骤 3 − 通过打开 WSDL,我们可以看到也存在一个用于检索信用卡信息的方法 'getCreditCard'。现在让我们使用 Burp Suite 篡改输入,如下所示 −

web_services2

步骤 4 − 现在让我们使用 Burp Suite 修改输入,如下所示 −

web_services3

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

web_services4

预防机制

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

  • 通过实现诸如应用于确保数据包完整性的校验和之类的机制来保护消息完整性。

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

安全测试 - 缓冲区溢出

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

示例

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

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

实操

步骤 1 − 我们需要使用姓名和房间号登录以获取互联网访问权限。以下是场景快照。

buffer_overflow

步骤 2 − 我们还将在 Burp Suite 中启用“显示隐藏表单字段”,如下所示 −

buffer_overflow1

步骤 3 − 现在,我们在姓名和房间号字段中输入内容。我们还尝试在房间号字段中注入一个很大的数字。

buffer_overflow2

步骤 4 − 隐藏字段如下所示。我们点击接受条款。

buffer_overflow3

步骤 5 − 攻击成功,由于缓冲区溢出,它开始读取相邻的内存位置并显示给用户,如下所示。

buffer_overflow4

步骤 6 − 现在让我们使用显示的数据登录。登录后,将显示以下消息 −

buffer_overflow4

预防机制

  • 代码审查
  • 开发人员培训
  • 编译器工具
  • 开发安全函数
  • 定期扫描

安全测试 - 拒绝服务攻击

拒绝服务 (DoS) 攻击是黑客试图使网络资源不可用的尝试。它通常会暂时或无限期地中断连接到互联网的主机。这些攻击通常针对托管在关键任务 Web 服务器上的服务,例如银行、信用卡支付网关。

DoS 的症状

  • 网络性能异常缓慢。
  • 特定网站不可用。
  • 无法访问任何网站。
  • 接收到的垃圾邮件数量急剧增加。
  • 长期无法访问 Web 或任何互联网服务。
  • 特定网站不可用。

实操

步骤 1 − 启动 WebGoat 并导航到“拒绝服务”部分。场景快照如下所示。我们需要多次登录,从而突破最大数据库线程池大小。

dos

步骤 2 − 首先,我们需要获取有效登录列表。在这种情况下,我们使用 SQL 注入。

dos1

步骤 3 − 如果尝试成功,则会向用户显示所有有效凭据。

dos3

步骤 4 − 现在,在至少 3 个不同的会话中使用这些用户中的每一个登录,以使 DoS 攻击成功。众所周知,数据库连接只能处理两个线程,通过使用所有登录名,它将创建三个线程,从而使攻击成功。

dos4

预防机制

  • 执行彻底的输入验证。

  • 避免高度占用 CPU 的操作。

  • 最好将数据磁盘与系统磁盘分开。

安全测试 - 恶意文件执行

开发人员经常直接使用或将可能存在漏洞的输入与文件连接,或者假设输入文件是真实的。如果数据未正确检查,这可能导致 Web 服务器处理或调用易受攻击的内容。

示例

一些经典示例包括 −

  • 将 .jsp 文件上传到 Web 树。
  • 上传 .gif 以调整大小。
  • 上传大型文件。
  • 上传包含标签的文件。
  • 将 .exe 文件上传到 Web 树。

实操

步骤 1 − 启动 WebGoat 并导航到恶意文件执行部分。场景快照如下所示 −

malacious_file_execution

步骤 2 − 为了完成本课程,我们需要将 guest.txt 上传到上述位置。

步骤 3 − 让我们创建一个 jsp 文件,以便在执行 jsp 时创建 guest.txt 文件。jsp 的命名在此上下文中不起任何作用,因为我们正在执行 jsp 文件的内容。

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

步骤 4 − 现在上传 jsp 文件并在上传后复制其链接位置。上传需要图像,但我们上传的是 jsp。

malacious_file_execution1

步骤 5 − 导航到 jsp 文件时,不会向用户显示任何消息。

步骤 6 − 现在刷新您上传 jsp 文件的会话,您将收到消息“*恭喜。您已成功完成本课程”。

malacious_file_execution2

预防机制

  • 使用网站权限保护网站。
  • 采取网络应用程序安全防御措施。
  • 了解 IIS 7.0 中的内置用户和组帐户。

安全测试 - 自动化工具

有各种工具可用于执行应用程序的安全测试。有些工具可以执行端到端安全测试,而有些工具则专门用于发现系统中特定类型的缺陷。

开源工具

一些开源安全测试工具如下所示 −

序号 工具名称
1

Zed Attack Proxy

提供自动化扫描程序和其他工具来发现安全漏洞。

https://www.zaproxy.org/

2

OWASP WebScarab

用 Java 开发,用于分析 Http 和 Https 请求。

https://www.owasp.org/index.php

3

OWASP Mantra

支持多语言安全测试框架

https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework

4

Burp Proxy

用于拦截和修改流量的工具,并可与自定义 SSL 证书一起使用。

https://www.portswigger.net/Burp/

5

Firefox Tamper Data

使用 tamperdata 查看和修改 HTTP/HTTPS 标头和 POST 参数

6

Firefox Web Developer Tools

Web Developer 扩展程序向浏览器添加各种 Web 开发人员工具。

https://addons.mozilla.org/en-US/firefox

7

Cookie 编辑器

允许用户添加、删除、编辑、搜索、保护和阻止 Cookie

https://chrome.google.com/webstore

特定工具集

以下工具可以帮助我们发现系统中特定类型的漏洞 −

序号 链接
1

OWASP SQLiX − SQL 注入

https://www.owasp.org/index.php

2

Sqlninja − SQL 注入

http://sqlninja.sourceforge.net/

3

SQLInjector − SQL 注入

https://sourceforge.net/projects/safe3si/

4

sqlpowerinjector − SQL 注入

http://www.sqlpowerinjector.com/

5

SSL Digger − 测试 SSL

https://www.mcafee.com/us/downloads/free-tools

6

THC-Hydra − 密码暴力破解

https://www.kali.org/tools/hydra/

7

Brutus − 密码暴力破解

https://www.hackercoolmagazine.com/brutus-password-cracker-complete-guide/

8

Ncat − 密码暴力破解

https://nmap.org/ncat/

9

OllyDbg − 测试缓冲区溢出

http://www.ollydbg.de/

10

Metasploit − 测试缓冲区溢出

https://www.metasploit.com/

商业黑盒测试工具

以下是一些商业黑盒测试工具,它们可以帮助我们发现我们开发的应用程序中的安全问题。

免费源代码分析器

商业源代码分析器

这些分析器检查、检测并报告源代码中的弱点,这些弱点容易受到漏洞的影响 −

广告