Security Testing 简明教程

Security Testing - Quick Guide

Security Testing - Overview

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

What is Security Testing?

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

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

Confidentiality − 它可以防止向非预期收件人披露信息。
Integrity − 它允许将准确而正确所需的信息从发送方传输到预期接收方。
Authentication − 它验证并确认用户身份。
Authorization − 它指定用户和资源的访问权限。
Availability − 它确保根据要求提供信息。
Non-repudiation − 它确保发送方或接收方未否认发送或接收邮件。

Example

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

使用有效的凭证登录 Web 应用程序。
注销 Web 应用程序。
单击浏览器的“后退 (BACK)”按钮。
验证系统是否要求您重新登录或是否可以返回已登录页面。

Security Testing - Process

安全性测试可以看作对系统的一次受控攻击，它以真实的方式揭示安全漏洞。其目标是评估 IT 系统的当前状态。它也被称为 penetration test 或更通俗地称为 ethical hacking 。

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

Penetration Test – Workflow

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

These four steps are re-iterated multiple times which goes hand in hand with the normal SDLC.

Security Testing - Malicious Software

Malicious software (malware) is any software that gives partial to full control of the system to the attacker/malware creator.

Malwares

Various forms of malware are listed below −

Virus − A virus is a program that creates copies of itself and inserts these copies into other computer programs, data files, or into the boot sector of the hard-disk. Upon successful replication, viruses cause harmful activity on infected hosts such as stealing hard-disk space or CPU time.
Worm − A worm is a type of malware which leaves a copy of itself in the memory of each computer in its path.
Trojan − Trojan is a non-self-replicating type of malware that contains malicious code, which upon execution results in loss or theft of data or possible system harm.
Adware − Adware, also known as freeware or pitchware, is a free computer software that contains commercial advertisements of games, desktop toolbars, and utilities. It is a web-based application and it collects web browser data to target advertisements, especially pop-ups.
Spyware - 间谍软件是一种入侵软件，它匿名监视用户，使用户的计算机面临敏感信息泄露的风险。间谍软件利用用户和应用程序漏洞，通常会附着在免费在线软件下载或用户点击的链接上。
Rootkit - rootkit 是黑客用来获取计算机/网络管理员级别访问权限的软件，通常通过安装窃取的密码或利用系统漏洞来实现，而且受害者并不知情。

Preventive Measures

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

确保操作系统和应用程序已安装最新的补丁程序/更新。
切勿打开可疑电子邮件，尤其是带附件的电子邮件。
从互联网下载时，务必检查所安装内容。切勿简单点击“确定”关闭弹出窗口。在安装应用程序之前，请验证发行者。
Install anti-virus software.
确保定期扫描和更新防病毒程序。
Install firewall.
始终启用和使用浏览器和应用程序提供的安全功能。

Anti-Malware Software

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

Microsoft Security Essentials
Microsoft Windows Defender
AVG Internet Security
Spybot - 搜索和摧毁
Avast！个人使用家庭版
Panda Internet Security
MacScan 适用于 Mac OS 和 Mac OS X

Security Testing - HTTP Protocol Basics

理解协议对于充分掌握安全测试非常重要。当我们在 Web 服务器和客户端之间截取数据包时，您将能够体会到协议的重要性。

HTTP Protocol

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

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

Basic Features

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

HTTP is connectionless − HTTP 客户端（即浏览器）发起 HTTP 请求。发出请求后，客户端断开与服务器的连接并等待响应。服务器处理请求并重新建立与客户端的连接以将响应发回。
HTTP is media independent − 只要客户端和服务器都知道如何处理数据内容，即可通过 HTTP 发送任何类型的数据。客户端和服务器都需要使用适当的 MIME 类型指定内容类型。
HTTP is stateless − HTTP 是无连接的，这是 HTTP 是无状态协议的直接结果。只有在当前请求期间，服务器和客户端才会互相了解。之后，他们都会忘记对方。由于协议的这种性质，客户端或浏览器都不能在 Web 页面中跨不同请求保留信息。

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

Architecture

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

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

Client − HTTP 客户端以请求方法、URI 和协议版本的形式向服务器发送请求，然后是包含请求修饰符、客户端信息和可能通过 TCP/IP 连接传输的主体内容的 MIME 类似消息。
Server − HTTP 服务器使用状态行（包括消息的协议版本和成功或错误代码）进行响应，然后是包含服务器信息、实体元信息和可能的实体主体内容的 MIME 类似消息。

HTTP – Disadvantages

HTTP 不是一个完全安全的协议。
HTTP 使用端口 80 作为通信的默认端口。
HTTP 在应用程序层运行。它需要创建多个连接以进行数据传输，这会增加管理开销。
使用 HTTP 时不需要加密/数字证书。

Http Protocol Details

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

Security Testing - HTTPS Protocol Basics

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

简而言之，HTTPS = HTTP + SSL

When is HTTPS Required?

When we browse, we normally send and receive information using HTTP protocol. So this leads anyone to eavesdrop on the conversation between our computer and the web server. Many a times we need to exchange sensitive information which needs to be secured and to prevent unauthorized access.

Https protocol used in the following scenarios −

Banking Websites
Payment Gateway
Shopping Websites
All Login Pages
Email Apps

Basic Working of HTTPS

Public key and signed certificates are required for the server in HTTPS Protocol.
Client requests for the https:// page
使用 https 连接时，服务器会通过提供 Web 服务器支持的加密方法列表来响应初始连接。
作为响应，客户端选择连接方法，客户端和服务器交换证书以认证各自的身份。
完成后，Web 服务器和客户端在确保双方使用相同的密钥后交换加密信息，然后关闭连接。
为了托管 https 连接，服务器必须有一个公钥证书，该证书将密钥信息与密钥所有者的身份验证嵌入其中。
几乎所有的证书都由第三方验证，这样可以向客户端保证密钥始终是安全的。

Security Testing - Encoding and Decoding

What is Encoding and Decoding?

编码是将字母、数字和其他特殊字符等一系列字符转换成专门格式以便高效传输的过程。

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

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

URL Encoding

URL 只能使用 ASCII 字符集在 Internet 上发送，并且在 URL 中包含除了 ASCII 字符之外的特殊字符时，需要对 URL 进行编码。URL 不包含空格，空格被加号 (+) 或 %20 替换。

ASCII Encoding

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

下表显示了字符的 ASCII 符号及其等效符号，最后是其在传递给服务器之前可以在 URL 中使用的替换符号。

ASCII	Symbol	Replacement
< 32		用 %xx 编码，其中 xx 是字符的十六进制表示。
32	space	+ or %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

Security Testing - Cryptography

What is Cryptography?

加密学是一门加密和解密数据的学科，它使用户能够存储敏感信息或通过不安全的网络传输它们，以便只有预期的接收者才能读取这些信息。

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

加密的明文称为密文，将加密数据还原回明文的过程称为 decryption 。

分析和破解安全通信的学科称为密码分析。执行相同操作的人也称为攻击者。
加密可以是强加密或弱加密，其强度由恢复实际明文所需的时间和资源来衡量。
因此需要一个适当的解码工具来解读强加密消息。
有一些先进的加密技术可用，即使每秒进行十亿次检查的十亿台计算机也无法解密文本。
随着计算能力的日益增强，人们必须增强加密算法，以保护数据和关键信息免遭攻击者的侵害。

How Encryption Works?

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

因此，加密数据完全依赖几个参数，例如加密算法的强度和密钥的秘密性。

Cryptography Techniques

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

Asymmetric Encryption - 公钥加密使用一对密钥进行加密：公钥用于加密数据，私钥用于解密。公钥向人们公开，同时对私钥保密。例如，RSA、数字签名算法 (DSA)、Elgamal。

Hashing - 哈希是一种单向加密，它会创建一个无法恢复或至少无法轻松恢复的加密输出。例如，MD5 算法。它用于创建数字证书、数字签名、存储密码、验证通信等。

Security Testing - Same Origin Policy

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

What is Same Origin Policy?

根据此策略，它允许从同一站点上获取的页面上运行的脚本，这些站点可以是以下各项的组合 −

Domain
Protocol
Port

Example

The reason behind this behavior is security. If you have try.com in one window and gmail.com in another window, then you DO NOT want a script from try.com to access or modify the contents of gmail.com or run actions in context of gmail on your behalf.

Below are webpages from the same origin. As explained before, the same origin takes domain/protocol/port into consideration.

[role="bare"]http://website.com
[role="bare"]http://website.com/
[role="bare"]http://website.com/my/contact.html

Below are webpages from a different origin.

[role="bare"]http://www.site.co.uk(another domain)
[role="bare"]http://site.org (another domain)
[role="bare"]https://site.com (another protocol)
[role="bare"]http://site.com:8080 (another port)

Same Origin policy Exceptions for IE

Internet Explorer has two major exceptions to SOP.

The first one is related to 'Trusted Zones'. If both domains are in highly trusted zone then the Same Origin policy is not applicable completely.
The second exception in IE is related to port. IE does not include port into Same Origin policy, hence the [role="bare"]http://website.com and [role="bare"]http://wesite.com:4444 are considered from the same origin and no restrictions are applied.

Security Testing - Cookies

What is a Cookie?

Cookie 是 Web 服务器发送的小段信息，存储在 Web 浏览器中以便浏览器以后读取。通过这种方式，浏览器会记住一些特定个人信息。如果黑客掌握了 Cookie 信息，则可能导致安全问题。

Properties of Cookies

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

它们通常是小文本文件，存储在计算机浏览器目录中的 ID 标记。
Web 开发人员使用它们来帮助用户有效浏览其网站并执行特定功能。
当用户再次浏览同一网站时，存储在 Cookie 中的数据将发送回 Web 服务器，以通知网站用户以前的活动。
对于具有大型数据库、需要登录、具有可自定义主题的网站，Cookie 是不可避免的。

Cookie Contents

Cookie 包含以下信息：

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

Types of Cookies

Session Cookies - 这些 Cookie 是临时 Cookie，当用户关闭浏览器时会被删除。即使用户再次登录，也会为该会话创建一个新的 Cookie。
Persistent cookies - 这些 Cookie 会保留在硬盘驱动器中，除非用户将其删除或它们过期。Cookie 的过期取决于它们能持续多长时间。

Testing Cookies

Here are the ways to test the cookies −

Disabling Cookies − As a tester, we need to verify the access of the website after disabling cookies and to check if the pages are working properly. Navigating to all the pages of the website and watch for app crashes. It is also required to inform the user that cookies are required to use the site.
Corrupting Cookies − Another testing to be performed is by corrupting the cookies. In order to do the same, one has to find the location of the site’s cookie and manually edit it with fake / invalid data which can be used access internal information from the domain which in turn can then be used to hack the site.
Removing Cookies − 删除网站的所有 cookies 并检查网站对它的反应。
Cross-Browser Compatibility − 必须查看在所有受支持的浏览器中，是否从所有写入 cookie 的页面中正确地写入 cookie。
Editing Cookies − 如果应用程序使用 cookie 存储登录信息，则作为测试人员，我们应该尝试在 cookie 或地址栏中将用户更改为另一个有效用户。编辑 cookie 不应允许您登录到其他用户的帐户。

Viewing and Editing Cookies

现代浏览器支持在浏览器本身内查看/编辑 cookie 信息。此处有 Mozilla/Chrome 使用的插件，我们可以使用它们成功执行编辑。

适用于 Firefox 的编辑 cookie 插件
适用于 Chrome 的为此 Cookie 编辑插件

编辑 cookie 的步骤如下 −

Download the plugin for Chrome from here
Edit the cookie value just by accessing the 'edit this cookie' plugin from chrome as shown below.

Security Testing - Hacking Web Applications

我们可以将各种方法论/方法用作执行攻击的参考。

Web Application - PenTesting Methodologies

在制定攻击模型时可以考虑以下标准。

在以下列表中，OWASP 最为活跃，并且有许多贡献者。我们将重点关注 OWASP 技术，它在设计 Web 应用程序之前由每个开发团队考虑在内。

OWASP Top 10

The Open Web Application Security Protocol team released the top 10 vulnerabilities that are more prevalent in web in the recent years. Below is the list of security flaws that are more prevalent in a web based application.

Application - Hands On

In order to understand each one of the techniques, let us work with a sample application. We will perform the attack on 'WebGoat', the J2EE application which is developed explicitly with security flaws for learning purposes.

The complete details about the webgoat project can be located https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. To Download the WebGoat Application, Navigate to https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) and goto downloads section.

To install the downloaded application, first ensure that you do not have any application running on Port 8080. It can be installed just using a single command - java -jar WebGoat-6.0.1-war-exec.jar. For more details, visit WebGoat Installation

Post Installation, we should be able to access the application by navigating to http://localhost:8080/WebGoat/attack and the page would be displayed as shown below.

We can use the credentials of guest or admin as displayed in the login page.

Web Proxy

In order to intercept the traffic between client (Browser) and Server (System where Webgoat Application is hosted in our case), we need to use a web proxy. We will use Burp Proxy that can be downloaded from https://portswigger.net/burp/download.html

It is sufficient if you download the free version of burp suite as shown below.

Configuring Burp Suite

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

Step 1 − 应用程序已安装在端口 8080 上，Burp 已安装在端口 8181 上，如下图所示。启动 Burp 套件并进行以下设置，以便在端口 8181 上启用它，如下所示。

Step 2 − 我们应确保 Burp 正在侦听应用程序安装所在的端口 8080，以便 Burp 套件可以截获流量。应在 Burp 套件的范围选项卡上进行此设置，如下所示。

Step 3 − 然后将浏览器的代理设置设为侦听端口 8181（Burp 套件端口）。因此，我们已配置 Web 代理来截获客户端（浏览器）与服务器（Web 服务器）之间的流量，如下所示 −

Step 4 − 配置的快照如下图所示，并附有简单的工作流图表

Security Testing - Injection

Injection technique consists of injecting a SQL query or a command using the input fields of the application.

Web Application - Injection

A successful SQL injection can read, modify sensitive data from the database, and can also delete data from a database. It also enables the hacker to perform administrative operations on the database such as shutdown the DBMS/dropping databases.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Examples

The application uses untrusted data in the construction of the following vulnerable SQL call −

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

Hands On

Step 1 − Navigate to the SQL Injection area of the application as shown below.

Step 2 − As given in the exercise, we use String SQL Injection to bypass authentication. Use SQL injection to log in as the boss ('Neville') without using the correct password. Verify that Neville’s profile can be viewed and that all functions are available (including Search, Create, and Delete).

Step 3 - 我们可以注入 SQL 以便通过将参数发送为 'a' = 'a' 或 1 = 1 来绕过密码

Step 4 - 在利用之后，我们可以以 Neville 身份登录，如下所示，他是管理员。

Preventing SQL Injection

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

Using Parameterized Queries
转义所有用户提供的输入
为最终用户启用数据库的最小权限

Testing Broken Authentication

When authentication functions related to the application are not implemented correctly, it allows hackers to compromise passwords or session ID’s or to exploit other implementation flaws using other users credentials.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

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

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

An authenticated user of the site forwards the URL to their friends to know about the discounted sales. He e-mails the above link without knowing that the user is also giving away the session IDs. When his friends use the link, they use his session and credit card.

Hands ON

Step 1 − 登录到 Webgoat 并导航至“会话管理缺陷”部分。让我们通过伪造 cookie 规避身份验证。以下是该场景的快照。

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

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

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

Step 5 − 如果我们深入查看 AuthCookie 值，则最后一部分与用户名长度相同。因此，很明显用户名与某种加密方法一起使用。在经过反复试验/暴力攻击机制后，我们发现将用户名 webgoat 反转；我们以 taogbew 结束，然后字母之前的字符被用作 AuthCookie。即 ubphcfx.

Step 6 − 如果我们传递此 cookie 值，我们可以看看会发生什么。在以 webgoat 用户身份验证时，通过执行步骤 4 和步骤 5 来查找同一用户 AuthCookie，将 AuthCookie 值更改为模拟用户 Alice。

Preventing Mechanisms

开发健全的身份验证和会话管理控制，使其满足 OWASP 的应用程序安全验证标准中定义的所有身份验证和会话管理要求。
开发人员应确保避免可用来窃取会话 ID 的 XSS 缺陷。

Testing Cross-Site Scripting

Cross-site Scripting (XSS) happens whenever an application takes untrusted data and sends it to the client (browser) without validation. This allows attackers to execute malicious scripts in the victim’s browser which can result in user sessions hijack, defacing web sites or redirect the user to malicious sites.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Types of XSS

Stored XSS − Stored XSS also known as persistent XSS occurs when user input is stored on the target server such as database/message forum/comment field etc. Then the victim is able to retrieve the stored data from the web application.
Reflected XSS − Reflected XSS also known as non-persistent XSS occurs when user input is immediately returned by a web application in an error message/search result or the input provided by the user as part of the request and without permanently storing the user provided data.
DOM Based XSS − DOM Based XSS is a form of XSS when the source of the data is in the DOM, the sink is also in the DOM, and the data flow never leaves the browser.

Example

The application uses untrusted data in the construction without validation. The special characters ought to be escaped.

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

The attacker modifies the query parameter in their browser to −

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

Hands ON

Step 1 − Login to Webgoat and navigate to cross-site scripting (XSS) Section. Let us execute a Stored Cross-site Scripting (XSS) attack. Below is the snapshot of the scenario.

Step 2 − As per the scenario, let us login as Tom with password 'tom' as mentioned in the scenario itself. Click 'view profile' and get into edit mode. Since tom is the attacker, let us inject Java script into those edit boxes.

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

Step 3 − As soon as the update is over, tom receives an alert box with the message "hacked" which means that the app is vulnerable.

Step 4 − Now as per the scenario, we need to login as jerry (HR) and check if jerry is affected by the injected script.

Step 5 − After logging in as Jerry, select 'Tom' and click 'view profile' as shown below.

While viewing tom’s profile from Jerry’s account, he is able to get the same message box.

Step 6 − This message box is just an example, but the actual attacker can perform much more than just displaying a message box.

Preventive Mechanisms

Developers have to ensure that they escape all untrusted data based on the HTML context such as body, attribute, JavaScript, CSS, or URL that the data is placed into.
For those applications that need special characters as input, there should be robust validation mechanisms in place before accepting them as valid inputs.

Insecure Direct Object References

A direct object reference is likely to occur when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key without any validation mechanism which allows attackers to manipulate these references to access unauthorized data.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

The App uses unverified data in a SQL call that is accessing account information.

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

The attacker modifies the query parameter in their browser to point to Admin.

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

Hands ON

Step 1 − Login to Webgoat and navigate to access control flaws Section. The goal is to retrieve the tomcat-users.xml by navigating to the path where it is located. Below is the snapshot of the scenario.

Step 2 − The path of the file is displayed in 'the current directory is' field - C:\Users\userName$\.extract\webapps\WebGoat\lesson_plans\en and we also know that the tomcat-users.xml file is kept under C:\xampp\tomcat\conf

Step 3 − We need to traverse all the way out of the current directory and navigate from C:\ Drive. We can perform the same by intercepting the traffic using Burp Suite.

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

Preventive Mechanisms

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

开发人员应仅对间接对象引用使用一个用户或会话。
还建议在使用来自不可信来源的直接对象引用之前检查访问权限。

Security Misconfiguration

安全性错误配置会在将安全性设置定义、实施并作为默认值维护时发生。良好的安全性需要定义并为应用程序、Web 服务器、数据库服务器和平台部署安全的配置。软件保持最新状态同样重要。

Example

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

如果目录在服务器上未被禁用，并且如果攻击者发现了这一点，那么攻击者只需列出目录即可找到任何文件并执行它。还可以获取包含所有自定义代码的实际代码库，然后在应用程序中找到严重缺陷。
应用程序服务器配置允许向用户返回堆栈轨迹，从而可能暴露底层缺陷。攻击者抓取错误消息提供的那些额外信息，这足以让他们渗透进来。
应用程序服务器通常带有安全性欠佳的示例应用程序。如果不从生产服务器中删除，会导致服务器受到危害。

Hands ON

Step 1 − 启动 Webgoat，导航到不安全的配置部分，让我们尝试解决该挑战。快照如下所示 −

Step 2 − 我们尽可能尝试许多选项。我们需要找到配置文件的 URL，并且我们知道开发人员遵循一种配置文件命名约定。可以是下面列出的任何一项。它通常通过蛮力技术完成。

web.config
config
appname.config
conf

Step 3 − 在尝试各种选项后，我们发现“ http://localhost:8080/WebGoat/conf ”是成功的。如果尝试成功，则会显示以下页面 −

Preventive Mechanisms

所有环境，如开发、质量保证和生产环境应使用不同的密码进行配置，且在每个环境中使用的密码都无法轻易被破解。
确保采用强大的应用程序架构，在组件之间提供有效的安全隔离。
它还可以通过定期运行自动化扫描并执行审计来最大程度减少此攻击的可能性。

Security Testing - Sensitive Data Exposure

随着在线应用程序在互联网上日益泛滥，并非所有应用程序都是安全的。许多 Web 应用程序不能适当保护敏感的用户数据，如信用卡信息/银行账户信息/验证凭据。黑客最终可能会窃取那些受到较弱保护的数据来进行信用卡欺诈、身份盗用或其他犯罪。

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

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

一个站点干脆不为所有经过验证的页面使用 SSL。这使得攻击者能够监视网络流量并窃取用户的会话 Cookie，以劫持用户的会话或访问其私有数据。
一个应用程序以加密格式存储数据库中的信用卡号。检索后，它们会被解密，允许黑客执行 SQL 注入攻击以检索明文中的所有敏感信息。可以使用公钥加密信用卡号并允许后端应用程序使用私钥对其进行解密来避免这种情况。

Hands ON

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

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

Preventive Mechanisms

建议不要不必要地存储敏感数据，如果不再需要，应尽快将其清除掉。
重要的是要确保我们纳入强大的标准加密算法，并采用适当的关键管理。
It can also be avoided by disabling autocomplete on forms that collect sensitive data such as password and disable caching for pages that contain sensitive data.

Missing Function Level Access Control

大多数 Web 应用程序在向用户提供该功能之前验证功能级别访问权限。但是，如果不对服务器执行相同的访问控制检查，则黑客能够在没有适当授权的情况下渗透到应用程序中。

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

以下是不存在功能级别访问控制的一个经典示例 −

黑客只是强制目标 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

Hands ON

Step 1 − 通过首先查看用户列表及其访问权限，我们登录为客户经理。

Step 2 − 在尝试各种组合后，我们可以发现 Larry 具有对客户经理资源的访问权限。

Preventive Mechanisms

身份验证机制应默认拒绝所有访问，并为每个功能提供对特定角色的访问。
在基于工作流的应用程序中，在允许用户访问任何资源之前，请验证其状态。

Cross-Site Request Forgery(CSRF)

A CSRF attack forces an authenticated user (victim) to send a forged HTTP request, including the victim’s session cookie to a vulnerable web application, which allows the attacker to force the victim’s browser to generate request such that the vulnerable app perceives as legitimate requests from the victim.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

Here is a classic example of CSRF −

Step 1 − Let us say, the vulnerable application sends a state changing request as a plain text without any encryption.

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

Step 2 − Now the hacker constructs a request that transfers money from the victim’s account to the attacker’s account by embedding the request in an image that is stored on various sites under the attacker’s control −

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

Hands ON

Step 1 − Let us perform a CSRF forgery by embedding a Java script into an image. The snapshot of the problem is listed below.

Step 2 − Now we need to mock up the transfer into a 1x1 image and make the victim to click on the same.

Step 3 − Upon submitting the message, the message is displayed as highlighted below.

Step 4 − Now if the victim clicks the following URL, the transfer is executed, which can be found intercepting the user action using burp suite. We are able to see the transfer by spotting it in Get message as shown below −

Step 5 − Now upon clicking refresh, the lesson completion mark is shown.

Preventive Mechanisms

CSRF can be avoided by creating a unique token in a hidden field which would be sent in the body of the HTTP request rather than in an URL, which is more prone to exposure.
Forcing the user to re-authenticate or proving that they are users in order to protect CSRF. For example, CAPTCHA.

Components with Vulnerabilities

This kind of threat occurs when the components such as libraries and frameworks used within the app almost always execute with full privileges. If a vulnerable component is exploited, it makes the hacker’s job easier to cause a serious data loss or server takeover.

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

The following examples are of using components with known vulnerabilities −

Attackers can invoke any web service with full permission by failing to provide an identity token.
Remote-code execution with Expression Language injection vulnerability is introduced through the Spring Framework for Java based apps.

Preventive Mechanisms

Identify all components and the versions that are being used in the webapps not just restricted to database/frameworks.
Keep all the components such as public databases, project mailing lists etc. up to date.
为本质上易受攻击的组件添加安全包装器。

Unvalidated Redirects and Forwards

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

Let us understand Threat Agents, Attack Vectors, Security Weakness, Technical Impact and Business Impacts of this flaw with the help of simple diagram.

Example

Some classic examples of Unvalidated Redirects and Forwards are as given −

Let us say the application has a page - redirect.jsp, which takes a parameter redirectrul. The hacker adds a malicious URL that redirects users which performs phishing/installs malware.

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

All web application used to forward users to different parts of the site. In order to achieve the same, some pages use a parameter to indicate where the user should be redirected if an operation is successful. The attacker crafts an URL that passes the application’s access control check and then forwards the attacker to administrative functionality for which the attacker has not got the access.

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

Preventive Mechanisms

It is better to avoid using redirects and forwards.
If it is unavoidable, then it should be done without involving user parameters in redirecting the destination.

AJAX Security

异步 Javascript 和 XML (AJAX) 是用于开发 Web 应用程序的最新技术之一，旨在提供丰富的用户体验。由于它是一项新技术，因此还有很多要建立的安全问题，以下是 AJAX 中的一些安全问题：

攻击面较大，因为有更多要保护的输入内容。
它还暴露了应用程序的内部功能。
未能保护身份验证信息和会话。
客户端和服务器端之间有一条很细的界线，因此有可能会犯安全错误。

Example

以下是 AJAX 安全的一个例子：

2006 年，一个蠕虫病毒感染了 yahoo 邮件服务，它利用了 Yahoo 邮件 onload 事件处理中的一个漏洞，该蠕虫利用了 XSS 和 AJAX。当打开受感染的电子邮件时，蠕虫会执行其 JavaScript，向受感染用户的全部 Yahoo 联系人发送一封副本。

Hands ON

Step 1 − 我们需要尝试使用 XML 注入来向已获准的奖励集中添加更多奖励。以下是该场景的快照。

Step 2 − 确保使用 Burp Suite 拦截请求和响应。设置如下所示。

Step 3 − 输入场景中给出的帐号。我们能够获得我们有资格享受的所有奖励的列表。我们有资格享受 5 个奖励中的 3 个。

Step 4 − 现在，让我们点击“提交”，看看在响应 XML 中会看到什么。如下所示，我们有资格享受的 3 个奖励都以 XML 形式传给了我们。

Step 5 − 现在，让我们编辑那些 XML，加上另外两个奖励。

Step 6 − 现在，用户可以选择所有奖励。选择我们添加的那些奖励，然后点击“提交”。

Step 7 − 出现以下消息，显示“* 恭喜。您已成功完成此课程”。

Preventive Mechanisms

客户端 -

使用 .innerText 代替 .innerHtml。
Do not use eval.
不要依赖于客户端逻辑进行安全保护。
Avoid writing serialization code.
Avoid building XML dynamically.
不要向客户端传输机密信息。
不要在客户端代码中执行加密。
不要在客户端执行影响安全的逻辑。

服务器端-

Use CSRF protection.
Avoid writing serialization code.
用户可以直接调用服务。
避免手动构建 XML，使用框架。
避免手动构建 JSON，使用现有框架。

Security Testing - Web Service

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

Hands ON

Step 1 − 导航到 Webgoat 的 Web 服务区域，然后转到 WSDL 扫描。我们现在需要获取其他帐号的信用卡详细信息。以下是对这种情况的概述。

Step 2 − 如果我们选择名字，则会通过 SOAP 请求 xml 调用“getFirstName”功能。

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

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

Step 5 − 我们可以获得其他用户的信用卡信息。

Preventive Mechanisms

由于 SOAP 消息基于 XML，因此所有传递的凭证都必须转换为文本格式。因此，必须非常小心地传递敏感信息，该信息必须始终加密。
通过实施应用于确保数据包完整性的机制（如校验和）来保护消息完整性。
通过应用非对称加密来保护消息机密性，以保护对称会话密钥，在许多实现中，密钥仅对一次通信有效，之后会被丢弃。

Security Testing - Buffer Overflows

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

Example

以下是缓冲区溢出的经典示例。它展示了一个简单的缓冲区溢出，它是由依赖于外部数据来控制其行为的第一种情况引起的。无法限制用户输入的数据量，并且该程序的行为取决于用户输入的字符数。

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

Hands ON

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

Step 2 − 我们还将在 Burp Suite 中启用“取消隐藏隐藏表单字段”，如下所示 −

Step 3 − 现在我们在姓名和房间号字段中发送输入。我们还尝试在房间号字段中注入一个很大的数字。

Step 4 − 隐藏字段按如下所示显示。我们单击接受条款。

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

Step 6 − 现在，让我们使用显示的数据进行登录。登录后，将显示以下消息 −

Preventive Mechanisms

Code Reviewing
Developer training
Compiler tools
Developing Safe functions
Periodical Scanning

Security Testing - Denial of Service

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

Symptoms of DoS

Unusually slow network performance.
特定网站不可用。
无法访问任何网站。
收到的垃圾邮件数量急剧增加。
长期不允许访问 Web 或任何互联网服务。
特定网站不可用。

Hands ON

Step 1 − 启动 WebGoat 并导航到“拒绝服务”部分。该场景的快照如下所示。我们通过突破最大 DB 线程池大小来多次登录那里。

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

Step 3 − 如果尝试成功，那么它会向用户显示所有有效凭据。

Step 4 − 现在使用其中每个用户登录，至少在 3 个不同的会话中，以便成功执行 DoS 攻击。正如我们所知，DB 连接只能处理两个线程，通过使用所有登录，它将创建三个线程，从而使攻击成功。

Preventive Mechanisms

Perform thorough input validations.
避免高度消耗 CPU 的操作。
最好将数据磁盘与系统磁盘分开。

Security Testing - Malicious File Execution

开发人员通常直接使用或将可能遭到破坏的输入与文件连接，或假设输入文件是真实的。如果数据没有经过正确检查，可能会导致 Web 服务器处理或调用遭到破坏的内容。

Example

以下是几个经典示例：

将 JSP 文件上传到 Web 树。
上传 GIF 文件以调整大小。
Upload huge files.
Upload file containing tags.
将 EXE 文件上传到 Web 树。

Hands ON

Step 1 - 启动 WebGoat 并导航至恶意文件执行部分。该场景的快照如下 -

Step 2 − 为了完成该课程，我们需在上文所说的位置中上传 guest.txt。

Step 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>

Step 4 − 现在，上传 jsp 文件，并在上传后复制该文件的链接位置。上传时系统将接受一张图片，但我们上传的是 jsp。

Step 5 − 通过导航到 jsp 文件，不会有任何信息发送给用户。

Step 6 − 现在，刷新上传 jsp 文件的会话，你会收到以下消息：“* 恭喜你。你已成功完成课程”。

Preventive Mechanisms

使用网站权限保护网站。
针对 Web 应用程序安全性采取对策。
了解 IIS 7.0 中内置的用户和组帐户。

Security Testing - Automation Tools

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

Open Source Tools

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

S.No.	Tool Name
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[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 Editor 允许用户添加、删除、编辑、搜索、保护和阻止 cookie https://chrome.google.com/webstore

Specific Tool Sets

以下工具有助于我们检测系统中的特定类型漏洞−

S.No.	Link
1	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
2	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
3	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
4	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
5	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
6	THC-Hydra − Brute Force Password https://www.kali.org/tools/hydra/
7	Brutus − Brute Force Password https://www.hackercoolmagazine.com/brutus-password-cracker-complete-guide/
8	Ncat − Brute Force Password https://nmap.org/ncat/
9	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
10	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

Commercial Black Box Testing tools

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

S.No	Tool
1	NGSSQuirreL NGSSQuirreL Tool
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
3	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

Free Source Code Analyzers

S.No	Tool
1	OWASP Orizon https://www.owasp.org/index.php
2	SearchDiggity https://www.bishopfox.com/resources/tools
3	FXCOP https://www.owasp.org/index.php/FxCop
4	Splint http://splint.org/
5	Boon https://www.cs.berkeley.edu/daw/boon/
6	W3af https://docs.w3af.org/en/latest/
7	FlawFinder https://www.dwheeler.com/flawfinder/
8	FindBugs http://findbugs.sourceforge.net/

Commercial Source Code Analyzers

这些分析器检查、检测和报告易受漏洞利用的源代码中的弱点 -

S.No	Tool
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
3	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/