理解安全风险、安全漏洞与安全威胁

Open Table of Contents

前言
什么是安全风险(Security Risks)、什么是安全漏洞(Security Vulnerabilities)
安全威胁
什么是威胁建模 (Threat Model)
- 案例1:
- 案例2:
威胁建模和渗透测试
最后
Reference

前言

注入是漏洞吗？大多数情况下我认为是，但是重新去看了下 OWSP TOP10，发现原文中的标题是 Security Risks (安全风险)。

安全风险和安全漏洞有什么区别？这便是本文主要讨论的内容。

什么是安全风险(Security Risks)、什么是安全漏洞(Security Vulnerabilities)

什么是安全漏洞，什么又是安全风险，两者的区别又是什么？通过两个案例引入我的理解：

验证码复用是安全风险还是安全漏洞？
SQL 注入是安全风险还是安全漏洞？

验证码复用是安全风险还是安全漏洞？

在回答该问题之前，先考虑下验证码复用的危害：

如果是登录场景，这允许我们对登录凭证进行爆破，无论是用户名还是密码
如果是注册场景，这允许我们进行批量用户注册或是去发现系统中已存在的用户
如果是投票场景，这运行我们进行无限制刷票

好，现在让我们专注于登录场景，因为这是在渗透测试中经常遇见的。

假如现在我们利用验证码复用成功爆破出了登录凭证，那此时渗透测试报告上的漏洞项是写弱口令还是验证码复用呢？

好吧，我猜测你会写：验证码复用导致的弱口令。但实际上真正导致系统被攻破的原因是弱口令。

那此时验证码复用此次攻击路径中起到什么作用呢？如果没有成功爆破出登录凭证，验证码复用还有作用吗?

SQL 注入是安全风险还是安全漏洞？

同样，在回答该问题之前，先考虑下SQL注入的危害：

执行SQL语句获取数据库信息，包括存储在数据库中的数据
严重甚至能执行操作系统命令，接管系统

如果此时要在渗透测试报告上写漏洞，毫无以为就是xxx功能点存在SQL注入，没有那么多前缀修饰，比如什么用户登录导致的SQL注入之类的（我知道这个例子很荒谬）。很明显，该项的定义是安全漏洞。

上诉两者的区别

由上面两个例子，也许你能感觉到两者的区别：

安全风险属于潜在的一种攻击路径，虽然无法像SQL注入那样直接造成危害，但是该风险是构成系统被攻破的不可或缺的路径。
安全漏洞，也就是实际造成危害的，比如上述提到的SQL注入，又或者文件上传，这些都直接威胁到系统的安全性。

安全边界

有人认为，服务器SSH允许使用密码登陆是不安全的，因此他们只使用的证书进行登陆。

事实上，这是一个错误的理解。不安全点不是在于使用了密码登陆，而是使用了弱密码。你的社交网站是使用了密码登陆，你能说明这个社交网站的登陆方式不安全吗，事实上只是使用的密码可能是潜在的弱口令，所以存在安全问题。

那么，什么是弱口令，什么又是强口令呢？

毫无疑问，常规的键盘密码就是弱口令。比如：123456

那如果我的密码是 123456AqBJ呢。事实上大多数的攻击者字典里不存在这一密码，此时可以“认为”该密码是属于强口令。

这又不经意会问出一个问题，弱密码和强密码之间的界限在哪里？这个问题中的界限，就是标题中所提到的安全边界。

假如攻击者知道了你的密码是由 123456 + 4位字符组成，如果这四位字符的每一位仅仅是由0-9数字组成，那么密码仅需要10的4次方，也就是理论上10,000次就能便利出你的密码(类似于4位验证码), 但如果这四位字符是数字加上26个英文字符的大小写，那么此时便利的次数就上升到(26*2+10)的4次方，也就是14,776,336，如果再加上一些符号，这个次数还会进一步上升。

就像区块链中的工作量证明一样，对攻击者的算力做要求，也算是防守的一部分。

那此时的安全边界可以认为数字加上26个英文字符的大小写，但处于边界上不一定是安全的，所有更多时候会要求使用数字+字母+特殊符号的形式设置密码，以确保所谓的密码安全。

安全威胁

事实上除了安全风险和安全漏洞，还有一个定义叫做安全威胁(Security Threat)。

根据文章描述，这三者的定义和区别如下：

A vulnerability is a flaw or weakness in an asset’s design, implementation, or operation and management that could be exploited by a threat. 漏洞是资产设计、实施或操作和管理中可能被威胁利用的缺陷或弱点。
A threat is a potential for a threat agent to exploit a vulnerability. 威胁是威胁主体利用漏洞的可能性。
A risk is the potential for loss when the threat happens. 风险是威胁发生时潜在的损失。

通过该定义，或许前文对的安全风险的理解是错误的？前面提到的安全风险应该属于安全威胁的范畴？

个人理解，放到特定场景下的威胁案例：

以电商为例，涉及到的威胁可能有：存在网络钓鱼攻击窃取用户账号密码；篡改交易数据；客户重要信息(信用卡, 身份证等)泄漏等
在线教育平台：信息泄漏导致的如电话诈骗、精准营销等；学习记录，学习成绩串改等
而前面提到的验证码复用，是登陆功能所涉及到的威胁。

什么是威胁建模 (Threat Model)

OWASP官网中专门有一项清单https://owasp.org/www-project-threat-model/，用于讲解威胁建模。总的来说，

Most threat model techniques answer one or more of the following questions 大多数威胁模型技术回答以下一个或多个问题:

What are we working on? 我们正在做什么？

What can go wrong? 会出现什么问题？

What are we going to do about that? 对此我们该怎么办？

Did we do a good enough job? 我们做得足够好吗？

讲解概念是枯燥的，如果你感兴趣，可以通过原文去获取更详细的信息。这里我使用ChatGTP生成两个案例来帮你快速了解威胁建模：

案例1:

Certainly! Let’s use an online photo album web application (like the one you mentioned you wanted to build) as the example system for threat modeling. Here’s how to answer the four key questions:

1. What are we working on?

We are designing an online photo album application that allows users to upload, store, and organize their personal photos. Features include:
	•	User authentication and authorization.
	•	File upload and storage in the cloud.
	•	Sharing albums with other users via unique links.
	•	Viewing and downloading images.

2. What can go wrong?

By identifying threats, we can group them into different categories:

Adversarial Threats:

	•	Unauthorized access: Attackers may gain access to user accounts via credential stuffing or brute-force attacks.
	•	Data theft: Sensitive photos might be exfiltrated if a storage bucket is misconfigured or compromised.
	•	Link abuse: Shared links might be discovered or guessed (e.g., through enumeration).

Operational Threats:

	•	Sensitive data exposure: Photos uploaded over an insecure channel (HTTP instead of HTTPS) could be intercepted.
	•	Poor access control: Improper implementation of user permissions could allow unauthorized access to private albums.

Technological Threats:

	•	Injection attacks: SQL injection or command injection could compromise the database or server.
	•	Server-Side Request Forgery (SSRF): Attackers might abuse the app to send malicious requests to internal resources.

3. What are we going to do about that?

We mitigate risks by implementing security measures for each identified threat:

Mitigation Strategies:

	•	Unauthorized Access:
	•	Enforce strong password policies and implement multi-factor authentication (MFA).
	•	Rate-limit login attempts to prevent brute-force attacks.
	•	Data Theft:
	•	Configure storage buckets (e.g., S3) with proper access controls (e.g., private by default).
	•	Encrypt files both in transit (TLS) and at rest.
	•	Link Abuse:
	•	Use unguessable, random strings for shared links and allow link expiration settings.
	•	Sensitive Data Exposure:
	•	Enforce HTTPS for all communications.
	•	Sanitize file metadata (e.g., location info in EXIF) before storage.
	•	Injection Attacks:
	•	Use parameterized queries to prevent SQL injection.
	•	Validate and sanitize all user inputs.
	•	SSRF:
	•	Restrict the server’s outbound requests using allowlists.
	•	Validate URLs before fetching resources.

4. Did we do a good enough job?

We evaluate the effectiveness of the measures through:

Testing and Validation:

	•	Penetration Testing:
	•	Perform regular pentests to simulate attacks and uncover potential vulnerabilities.
	•	Code Reviews:
	•	Conduct secure code audits, especially for file upload and link-sharing functionality.
	•	Monitoring:
	•	Deploy logging and monitoring solutions to detect suspicious activities, such as unusual login attempts or link enumeration.
	•	Bug Bounty Program:
	•	Invite external researchers to identify security issues.

Assessment:

	•	Compare the threat model and mitigations against the real-world attack surface.
	•	Review logs, security tests, and incident reports to ensure all major threats have been addressed.

This iterative approach helps refine the system and ensure security over time. Does this align with what you were envisioning?

案例2:

Let’s create a simplified threat model example for a web application that handles user registrations and login functionality.

Scenario: User Registration and Login System

	•	What are we working on?
	•	A web application with:
	•	A user registration page where users provide their email, password, and personal details.
	•	A login page for user authentication.
	•	Backend APIs to store and manage user data in a database.

Step 1: Identify Assets

	1.	User credentials (email and password).
	2.	Personally Identifiable Information (PII) (e.g., name, address).
	3.	Session tokens generated upon successful login.
	4.	The web server and database hosting the application.

Step 2: Identify Threats

Using the STRIDE framework:
	1.	Spoofing:
	•	An attacker impersonates another user by guessing or stealing credentials.
	•	Threat: Credential stuffing attack using breached password lists.
	•	Threat: Man-in-the-middle (MITM) attack to intercept login details.
	2.	Tampering:
	•	An attacker modifies data in transit or in the database.
	•	Threat: Interception and modification of API payloads during registration.
	•	Threat: Unauthorized modification of user profiles via poorly secured APIs.
	3.	Repudiation:
	•	Users deny actions they performed.
	•	Threat: Lack of logging makes it impossible to trace malicious activities.
	4.	Information Disclosure:
	•	Sensitive data is exposed to unauthorized parties.
	•	Threat: User passwords are stored in plaintext in the database.
	•	Threat: API responses leak PII.
	5.	Denial of Service (DoS):
	•	The service is made unavailable to legitimate users.
	•	Threat: Brute-force login attempts overwhelm the server.
	•	Threat: A botnet floods the application with requests.
	6.	Elevation of Privilege:
	•	A low-privileged user gains access to admin functions.
	•	Threat: Insecure access control allows regular users to access admin APIs.

Step 3: Mitigations

For each identified threat:
	1.	Spoofing:
	•	Mitigation: Implement rate-limiting on login attempts to prevent credential stuffing.
	•	Mitigation: Enforce HTTPS to protect data in transit.
	•	Mitigation: Use multi-factor authentication (MFA).
	2.	Tampering:
	•	Mitigation: Validate and sanitize all input to prevent malicious payloads.
	•	Mitigation: Use secure tokens (e.g., JWT) with integrity checks.
	3.	Repudiation:
	•	Mitigation: Implement comprehensive logging for user actions with timestamps.
	•	Mitigation: Use non-repudiable actions, such as transaction hashes for sensitive operations.
	4.	Information Disclosure:
	•	Mitigation: Hash passwords using a strong hashing algorithm (e.g., bcrypt) with a salt.
	•	Mitigation: Avoid exposing sensitive data in API responses (e.g., use data minimization).
	•	Mitigation: Enforce strict CORS policies to prevent unauthorized access.
	5.	Denial of Service:
	•	Mitigation: Add rate-limiting and IP-based throttling for login and registration APIs.
	•	Mitigation: Use a web application firewall (WAF) to filter malicious traffic.
	6.	Elevation of Privilege:
	•	Mitigation: Implement role-based access control (RBAC) for all APIs.
	•	Mitigation: Perform rigorous testing for privilege escalation vulnerabilities.

Step 4: Validate

	•	Conduct penetration testing to simulate credential stuffing, privilege escalation, and injection attacks.
	•	Verify that mitigations (e.g., MFA, rate-limiting) are effective.
	•	Monitor logs to ensure visibility into security events and adjust controls as needed.
	
Summary of the Threat Model:

Threat	Mitigation	Impact	Likelihood	Priority
Credential stuffing	Rate-limiting, MFA	High	Medium	High
Plaintext password storage	Hashing with bcrypt	Critical	Low	High
Brute-force login attacks	IP-based throttling, WAF	High	Medium	Medium
API data leakage	Strict CORS, minimize exposed fields	High	Medium	High

This example is a simplified but practical threat model for a commonly used system. In a real-world scenario, more details and iterative refinements would be needed, especially as the system evolves.

威胁建模和渗透测试

两者从目标上都是一致的，都是为了提高系统的安全性。只不过思考的角度不一样：

作为攻击者，如果你熟悉业务功能，你就能从该业务涉及到的威胁入手进行漏洞挖掘。以电商为例：比如常见的“0元购”，”优惠券并发问题“。这也是为什么在大多数情况下，大多数SRC的分享上，关于漏洞挖掘中出现最多的就是需要熟悉业务功能的原因。
作为蓝队防守者，可以提前在SDL中关注该问题，实现所谓的安全左移。

献上一张老图：

最后

本文提到了很多概念，什么安全风险、安全漏洞以及安全风险。事实上到最后，我也没办法准确的区分每个概念的区别。

比如安全风险到低是指：构成系统被攻破的不可或缺的路径还是风险是威胁发生时潜在的损失。但是用“安全威胁“统称的话应该没啥问题。

不过唯一确定的是，漏洞就是实际造成“危害”的地方，这个所谓的“危害”，根据不同业务系统可能定义也不相同，可以参考各个SRC的漏洞等级标准，以货拉拉的SRC的为例：

Reference

Vulnerabilities, Threats, and Risks Explained

OWASP Threat Modeling Project

《货拉拉安全应急响应中心漏洞处理和评分标准V4.1》2024-04-01

guide-to-cyber-threat-modelling.pdf