feat: add cybersecurity topic with 6 subtopics (204 questions)
Deploy Examination / deploy (push) Successful in 7s
Deploy Examination / deploy (push) Successful in 7s
New topic group: 网络安全专题 (cybersecurity) Subtopics: - web-security: Web 安全基础 (34 questions) - crypto-basics: 密码学基础 (34 questions) - buffer-overflow: 缓冲区溢出与漏洞利用 (34 questions) - os-security: 操作系统安全 (34 questions) - network-attack: 网络攻防 (34 questions) - secure-coding: 安全编程实践 (34 questions) Question types per subtopic: - single_choice × 20 - true_false × 10 - short_answer × 3 - code_reading × 1 Difficulty range: 1-3 (基础)
This commit is contained in:
@@ -0,0 +1,74 @@
|
||||
{
|
||||
"topic": "web-security",
|
||||
"type": "code_reading",
|
||||
"schema_version": "1.0.0",
|
||||
"generated": "2026-09-17T00:00:00+08:00",
|
||||
"questions": [
|
||||
{
|
||||
"id": "cr-001",
|
||||
"type": "code_reading",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入",
|
||||
"xss",
|
||||
"ssrf",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "阅读以下 PHP 代码，该代码实现了一个简单的文件处理功能。请分析其中存在的安全漏洞。",
|
||||
"source": null,
|
||||
"related": [],
|
||||
"code": "<?php\n// 文件上传处理\nif ($_SERVER['REQUEST_METHOD'] === 'POST' && isset($_FILES['avatar'])) {\n $file = $_FILES['avatar'];\n $filename = $file['name'];\n $target = \"uploads/\" . $filename;\n move_uploaded_file($file['tmp_name'], $target);\n echo \"File uploaded: <a href='$target'>$filename</a>\";\n}\n\n// 用户搜索功能\nif (isset($_GET['keyword'])) {\n $keyword = $_GET['keyword'];\n $conn = new mysqli('localhost', 'root', 'password123', 'mydb');\n $sql = \"SELECT * FROM products WHERE name LIKE '%$keyword%'\";\n $result = $conn->query($sql);\n echo \"<h2>Results for: $keyword</h2>\";\n while ($row = $result->fetch_assoc()) {\n echo \"<p>{$row['name']} - {$row['price']}</p>\";\n }\n}\n\n// URL 抓取功能\nif (isset($_GET['url'])) {\n $content = file_get_contents($_GET['url']);\n echo $content;\n}\n?>",
|
||||
"language": "php",
|
||||
"sub_questions": [
|
||||
{
|
||||
"index": 1,
|
||||
"type": "single_choice",
|
||||
"question": "代码中的文件上传部分存在哪些安全问题？",
|
||||
"options": {
|
||||
"A": "仅缺少文件大小限制",
|
||||
"B": "未验证文件类型和扩展名、使用原始文件名、存在存储型 XSS",
|
||||
"C": "仅存在目录遍历风险",
|
||||
"D": "仅缺少 CSRF Token"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "文件上传代码存在多个严重问题：①未验证文件类型和扩展名，攻击者可上传 .php 等可执行脚本；②使用原始文件名 $file['name']，可能导致路径遍历（如 ../../etc/cron.d/evil）或文件名解析漏洞；③直接将文件名输出到 HTML 中（`<a href='$target'>$filename</a>`），未做转义，存在存储型 XSS。选项 A 只提到大小限制，选项 C 只提到目录遍历，选项 D 只提到 CSRF，均不够全面。因此正确答案是 B。"
|
||||
},
|
||||
{
|
||||
"index": 2,
|
||||
"type": "single_choice",
|
||||
"question": "搜索功能中的 SQL 查询存在什么漏洞？以下哪个 payload 可以利用该漏洞获取所有用户数据？",
|
||||
"options": {
|
||||
"A": "keyword=test",
|
||||
"B": "keyword=' UNION SELECT username, password, email FROM users--",
|
||||
"C": "keyword=<script>alert(1)</script>",
|
||||
"D": "keyword=127.0.0.1"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "搜索功能中 `$keyword` 直接拼接到 SQL 查询中，存在 SQL 注入漏洞。选项 B 使用联合查询注入（UNION SELECT），通过闭合原有的 LIKE 条件，注入 UNION 查询来读取 users 表中的敏感数据（用户名、密码、邮箱）。`--` 用于注释掉后续 SQL。选项 C 是 XSS payload，虽然代码中也存在 XSS 漏洞（`$keyword` 未经转义输出），但不能获取数据库数据。选项 A 是正常搜索，选项 D 是 IP 地址，均不能利用该 SQL 注入。"
|
||||
},
|
||||
{
|
||||
"index": 3,
|
||||
"type": "single_choice",
|
||||
"question": "URL 抓取功能存在什么类型的漏洞？攻击者可以如何利用？",
|
||||
"options": {
|
||||
"A": "XSS 漏洞，注入脚本到 URL 参数",
|
||||
"B": "SQL 注入，通过 URL 参数修改数据库查询",
|
||||
"C": "SSRF 漏洞，可以读取本地文件或访问内网服务",
|
||||
"D": "文件上传漏洞，通过 URL 上传文件到服务器"
|
||||
},
|
||||
"answer": "C",
|
||||
"explanation": "`file_get_contents($_GET['url'])` 直接使用用户输入的 URL 发起请求，且未对协议和目标地址做任何限制，存在严重的 SSRF 漏洞。攻击者可以：①使用 `file:///etc/passwd` 读取服务器本地文件；②使用 `http://169.254.169.254/latest/meta-data/` 获取云实例元数据和临时凭证；③访问内网服务如 `http://192.168.1.1:8080/admin`。此外，`echo $content` 将远程内容直接输出，还可被利用进行 XSS 攻击（存储型或反射型），但该功能的核心漏洞是 SSRF。因此正确答案是 C。"
|
||||
},
|
||||
{
|
||||
"index": 4,
|
||||
"type": "short_answer",
|
||||
"question": "请针对代码中的三个功能模块，分别给出至少一条关键修复建议。",
|
||||
"answer": "1. 文件上传：①使用白名单验证文件扩展名（仅允许 jpg/png/gif 等）；②使用 move_uploaded_file 前检查文件 MIME 类型和 Magic Number；③将文件重命名为 UUID 等随机名称；④对输出的文件名使用 htmlspecialchars() 转义。\n2. 搜索功能：①使用参数化查询替换字符串拼接（如 $stmt = $conn->prepare(\"SELECT * FROM products WHERE name LIKE ?\"); $stmt->bind_param('s', $keyword)）；②对输出的 $keyword 使用 htmlspecialchars() 转义防止 XSS；③不要在代码中硬编码数据库密码，使用环境变量或配置文件。\n3. URL 抓取：①建立允许访问的域名/IP白名单；②限制协议只能为 http/https；③解析 URL 域名后的 IP 地址，拒绝内网 IP 段；④对返回内容做 htmlspecialchars() 转义后再输出。",
|
||||
"explanation": "该答案针对每个功能模块给出了具体的修复建议。文件上传需要类型验证、重命名和输出转义；搜索功能需要参数化查询、输出转义和凭证安全；URL 抓取需要白名单、协议限制、内网 IP 过滤和输出转义。这些建议涵盖了代码中识别出的所有主要漏洞。"
|
||||
}
|
||||
],
|
||||
"explanation": ""
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,29 @@
|
||||
{
|
||||
"slug": "web-security",
|
||||
"name": "Web 安全基础",
|
||||
"description": "XSS / SQL 注入 / CSRF / SSRF / 文件上传",
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss",
|
||||
"sql注入",
|
||||
"csrf",
|
||||
"ssrf",
|
||||
"文件上传"
|
||||
],
|
||||
"created": "2026-09-17",
|
||||
"question_files": [
|
||||
"code_reading.json",
|
||||
"short_answer.json",
|
||||
"single_choice.json",
|
||||
"true_false.json"
|
||||
],
|
||||
"stats": {
|
||||
"total": 34,
|
||||
"by_type": {
|
||||
"code_reading": 1,
|
||||
"short_answer": 3,
|
||||
"single_choice": 20,
|
||||
"true_false": 10
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,92 @@
|
||||
{
|
||||
"topic": "web-security",
|
||||
"type": "short_answer",
|
||||
"schema_version": "1.0.0",
|
||||
"generated": "2026-09-17T00:00:00+08:00",
|
||||
"questions": [
|
||||
{
|
||||
"id": "sa-001",
|
||||
"type": "short_answer",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "请简述 XSS 攻击的三种主要类型（存储型、反射型、DOM 型），并分别说明其攻击流程和典型场景。",
|
||||
"answer": "1. 存储型 XSS（持久型）：攻击者将恶意脚本提交并存储到服务器端（如论坛帖子、评论区），当其他用户访问包含该内容的页面时，恶意脚本从服务器返回并在浏览器中执行。典型场景：论坛评论、用户资料、站内消息。\n\n2. 反射型 XSS（非持久型）：攻击者构造包含恶意脚本的 URL，诱导用户点击后，服务器将恶意脚本作为参数值「反射」回 HTML 响应中执行。典型场景：搜索结果页显示搜索关键词、错误消息显示用户输入。\n\n3. DOM 型 XSS：攻击者构造的 URL 中包含恶意数据，前端 JavaScript 直接从 URL（如 location.hash、document.referrer）读取数据并写入 DOM（如 innerHTML），不经过服务器处理。典型场景：单页应用（SPA）、前端路由处理。",
|
||||
"source": null,
|
||||
"related": [],
|
||||
"keywords": [
|
||||
"存储型",
|
||||
"反射型",
|
||||
"DOM型",
|
||||
"恶意脚本",
|
||||
"服务器存储",
|
||||
"URL参数",
|
||||
"DOM操作",
|
||||
"innerHTML",
|
||||
"浏览器执行"
|
||||
],
|
||||
"scoring_rubric": "满分标准：正确列出三种类型（各1分），每种类型需说明攻击流程（各2分）和至少一个典型场景（各1分）。总分9分。若仅列出类型名称但无流程和场景，最高得3分。",
|
||||
"explanation": ""
|
||||
},
|
||||
{
|
||||
"id": "sa-002",
|
||||
"type": "short_answer",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入",
|
||||
"csrf"
|
||||
],
|
||||
"question": "对比 SQL 注入和 CSRF 两种攻击方式，从攻击目标、利用条件和防御策略三个方面进行分析。",
|
||||
"answer": "攻击目标：\n- SQL 注入：针对后端数据库，通过篡改 SQL 查询语义来窃取、修改或删除数据库数据，甚至执行系统命令。\n- CSRF：针对已认证用户的会话，利用浏览器自动携带凭据的特性，以用户身份执行非预期的操作（如转账、改密码）。\n\n利用条件：\n- SQL 注入：需要应用程序存在将用户输入直接拼接至 SQL 语句的代码缺陷，攻击者构造恶意输入即可触发，不需要用户登录。\n- CSRF：需要用户已登录目标站点且浏览器保存了有效的会话凭证，同时目标站点的状态更改请求缺少有效的来源验证。\n\n防御策略：\n- SQL 注入：使用参数化查询/预编译语句、输入验证与过滤、最小权限原则、使用 ORM 框架。\n- CSRF：使用 CSRF Token 验证、SameSite Cookie 属性、验证 Referer/Origin 头、关键操作要求二次确认。",
|
||||
"source": null,
|
||||
"related": [],
|
||||
"keywords": [
|
||||
"SQL注入",
|
||||
"CSRF",
|
||||
"数据库",
|
||||
"会话",
|
||||
"参数化查询",
|
||||
"CSRF Token",
|
||||
"SameSite",
|
||||
"输入验证",
|
||||
"拼接",
|
||||
"自动携带Cookie"
|
||||
],
|
||||
"scoring_rubric": "满分标准：三个维度（攻击目标、利用条件、防御策略）各占3分，每个维度中两种攻击的对比各1.5分。回答需体现关键差异，表述准确完整。总分9分。仅对比一个维度或泛泛而谈，酌情扣分。",
|
||||
"explanation": ""
|
||||
},
|
||||
{
|
||||
"id": "sa-003",
|
||||
"type": "short_answer",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "请分别描述防御文件上传漏洞和 SSRF 漏洞的最佳实践（至少各列出三点）。",
|
||||
"answer": "文件上传防御最佳实践：\n1. 服务端验证文件类型：检查文件扩展名白名单、MIME 类型和文件头签名（Magic Number），不依赖前端验证。\n2. 重命名上传文件：使用随机名称（如 UUID）替换原始文件名，避免路径遍历和文件名解析漏洞。\n3. 隔离存储：将上传文件存储在 Web 根目录之外，或使用独立的文件存储服务（如对象存储）。\n4. 禁用执行权限：确保上传目录不可执行脚本。\n5. 限制文件大小：防止 DoS 攻击。\n\nSSRF 防御最佳实践：\n1. URL 白名单：只允许访问预定义的可信域名和 IP 范围。\n2. 协议限制：只允许 http:// 和 https:// 协议，禁止 file://、gopher://、dict:// 等危险协议。\n3. IP 地址校验：解析域名为 IP 后检查是否为内网地址（127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、169.254.0.0/16 等），防止 DNS 重绑定。\n4. 响应处理：限制响应大小和类型，避免将完整响应返回给客户端。\n5. 禁用不必要的 URL 重定向跟随。",
|
||||
"source": null,
|
||||
"related": [],
|
||||
"keywords": [
|
||||
"文件类型验证",
|
||||
"白名单",
|
||||
"重命名",
|
||||
"UUID",
|
||||
"隔离存储",
|
||||
"执行权限",
|
||||
"Magic Number",
|
||||
"协议限制",
|
||||
"内网地址",
|
||||
"DNS重绑定",
|
||||
"URL白名单",
|
||||
"IP校验"
|
||||
],
|
||||
"scoring_rubric": "满分标准：文件上传防御列出至少3点（每点1.5分，共4.5分），SSRF防御列出至少3点（每点1.5分，共4.5分）。每点需表述清楚且正确。总分9分。少于3点或表述错误酌情扣分。",
|
||||
"explanation": ""
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,408 @@
|
||||
{
|
||||
"topic": "web-security",
|
||||
"type": "single_choice",
|
||||
"schema_version": "1.0.0",
|
||||
"generated": "2026-09-17T00:00:00+08:00",
|
||||
"questions": [
|
||||
{
|
||||
"id": "sc-001",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "以下哪种攻击方式的核心原理是在网页中注入恶意脚本并在其他用户的浏览器中执行？",
|
||||
"options": {
|
||||
"A": "SQL 注入",
|
||||
"B": "跨站脚本攻击（XSS）",
|
||||
"C": "跨站请求伪造（CSRF）",
|
||||
"D": "服务端请求伪造（SSRF）"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "XSS（Cross-Site Scripting）的核心是将恶意脚本注入到网页中，当其他用户访问该页面时，恶意脚本在受害者浏览器中执行。SQL 注入针对数据库查询，CSRF 利用用户已认证身份伪造请求，SSRF 是让服务端发起非预期的请求。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-002",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "以下哪种 XSS 攻击类型的恶意脚本不会被存储在服务器端？",
|
||||
"options": {
|
||||
"A": "存储型 XSS",
|
||||
"B": "反射型 XSS",
|
||||
"C": "DOM 型 XSS",
|
||||
"D": "B 和 C 都对"
|
||||
},
|
||||
"answer": "D",
|
||||
"explanation": "存储型 XSS 的恶意脚本被持久化存储在服务器（如数据库），每次用户访问都会触发。反射型 XSS 的恶意脚本通过 URL 参数等方式传递，服务器将其「反射」回响应中，不会存储。DOM 型 XSS 完全在客户端通过修改 DOM 执行，不经过服务器处理。因此 B 和 C 都不会存储在服务器端，正确答案是 D。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-003",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "以下哪个 HTML 代码片段存在反射型 XSS 漏洞？",
|
||||
"options": {
|
||||
"A": "<p>Welcome, <b>admin</b></p>",
|
||||
"B": "<p>Welcome, <?php echo htmlspecialchars($_GET['name']); ?></p>",
|
||||
"C": "<p>Welcome, <?php echo $_GET['name']; ?></p>",
|
||||
"D": "<p>Welcome, <script>document.write('user')</script></p>"
|
||||
},
|
||||
"answer": "C",
|
||||
"explanation": "选项 C 直接将用户输入的 `name` 参数未经任何转义或过滤就输出到 HTML 页面中，攻击者可以构造 `<script>alert(1)</script>` 等恶意参数值实现注入。选项 B 使用了 `htmlspecialchars()` 对特殊字符进行转义，是安全的做法。选项 A 是硬编码内容，不存在注入点。选项 D 中的脚本是开发者写死的，不涉及用户输入。因此正确答案是 C。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-004",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "为了防御 XSS 攻击，Content-Security-Policy（CSP）头中最关键的作用是什么？",
|
||||
"options": {
|
||||
"A": "加密传输数据",
|
||||
"B": "限制浏览器只执行来自可信来源的脚本",
|
||||
"C": "阻止所有表单提交",
|
||||
"D": "过滤用户输入中的特殊字符"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "CSP（内容安全策略）通过 HTTP 响应头告诉浏览器只允许加载和执行来自指定可信来源的脚本，从而有效阻止内联脚本和未授权外部脚本的执行。加密传输是 HTTPS 的功能，过滤用户输入是服务端输入验证的工作，阻止表单提交与 CSP 无关。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-005",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "SQL 注入攻击的根本原因是什么？",
|
||||
"options": {
|
||||
"A": "数据库软件存在漏洞",
|
||||
"B": "用户输入未经过充分的验证和参数化处理就拼接到 SQL 语句中",
|
||||
"C": "服务器操作系统不安全",
|
||||
"D": "网络传输未加密"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "SQL 注入的根本原因是应用程序将用户提供的输入直接拼接到 SQL 查询语句中，而没有进行参数化处理或充分的验证与过滤，使得攻击者可以通过构造特殊输入来改变 SQL 语句的语义。数据库本身、操作系统和网络加密都不是 SQL 注入的直接原因。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-006",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "以下哪种技术是防御 SQL 注入最有效的方法？",
|
||||
"options": {
|
||||
"A": "使用存储过程",
|
||||
"B": "使用参数化查询（Prepared Statements）",
|
||||
"C": "对输入进行长度限制",
|
||||
"D": "禁用错误信息显示"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "参数化查询（Prepared Statements）是防御 SQL 注入最有效的方法，它将 SQL 语句结构与数据完全分离，数据库引擎不会将参数值解释为 SQL 命令的一部分。存储过程也可以防御，但如果存储过程内部仍然使用动态拼接 SQL，仍然存在注入风险。长度限制只是降低了攻击面，不能从根本上阻止注入。禁用错误信息显示只是减少了信息泄露，不能阻止注入本身。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-007",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "在 SQL 注入中，以下 payload `1' OR '1'='1` 主要利用的是什么原理？",
|
||||
"options": {
|
||||
"A": "利用数据库权限过大",
|
||||
"B": "利用 SQL 语句中字符串拼接后 OR 条件永远为真",
|
||||
"C": "利用数据库的联合查询功能",
|
||||
"D": "利用时间延迟来获取数据"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "该 payload 的原理是在原本的查询条件后闭合单引号，添加 `OR '1'='1'`，使 WHERE 条件永远为真。例如原 SQL 为 `SELECT * FROM users WHERE name='[输入]' AND password='...'`，拼接后变成 `WHERE name='1' OR '1'='1' AND password='...'`，由于 `'1'='1'` 恒为真，整个 OR 表达式为真，绕过了正常验证。利用权限过大和联合查询是其他类型的注入手法，时间延迟是盲注的一种手段。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-008",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "以下哪种 SQL 注入方式在无法直接看到查询结果时，通过观察页面响应时间来推断数据？",
|
||||
"options": {
|
||||
"A": "联合查询注入",
|
||||
"B": "报错注入",
|
||||
"C": "基于时间的盲注",
|
||||
"D": "堆叠查询注入"
|
||||
},
|
||||
"answer": "C",
|
||||
"explanation": "基于时间的盲注（Time-based Blind SQL Injection）是在无法通过页面回显或报错获取数据时使用的一种技术。攻击者通过在注入 payload 中加入 `SLEEP()`、`WAITFOR DELAY` 等时间延迟函数，根据服务器响应时间的长短来判断注入条件是否成立，从而逐位推断出数据。联合查询注入依赖可见的查询结果回显，报错注入依赖数据库错误信息，堆叠查询注入依赖执行多条 SQL 语句。因此正确答案是 C。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-009",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"csrf"
|
||||
],
|
||||
"question": "CSRF（跨站请求伪造）攻击成功的前提条件是什么？",
|
||||
"options": {
|
||||
"A": "目标网站存在 XSS 漏洞",
|
||||
"B": "用户已在目标网站登录且浏览器保存了认证凭据",
|
||||
"C": "目标网站没有使用 HTTPS",
|
||||
"D": "目标网站的数据库未加密"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "CSRF 攻击的本质是利用浏览器自动携带 Cookie 等认证凭据的特性。当用户已登录目标网站并在浏览器中保存了有效的会话凭证后，攻击者诱导用户访问恶意页面，浏览器会自动在请求中附带目标网站的认证信息，从而以用户身份执行非预期操作。XSS 可以辅助 CSRF 但不是必要条件，HTTPS 和数据库加密与 CSRF 无直接关系。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-010",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"csrf"
|
||||
],
|
||||
"question": "以下哪种措施能最有效地防御 CSRF 攻击？",
|
||||
"options": {
|
||||
"A": "使用验证码",
|
||||
"B": "在请求中添加并验证 CSRF Token",
|
||||
"C": "限制密码长度",
|
||||
"D": "使用 MD5 加密密码"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "CSRF Token 是防御 CSRF 攻击的标准方案。服务器为每个用户会话生成一个随机且不可预测的令牌，在执行敏感操作时要求客户端随请求一起提交该令牌。由于攻击者无法获知这个令牌，因此无法伪造有效请求。验证码虽然也能在一定程度上防御 CSRF，但会影响用户体验且不适合所有场景。限制密码长度和使用 MD5 加密密码与 CSRF 防御无关。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-011",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"csrf"
|
||||
],
|
||||
"question": "浏览器的 SameSite Cookie 属性设置为 `Lax` 时，以下哪种请求会携带 Cookie？",
|
||||
"options": {
|
||||
"A": "第三方网站发起的 POST 表单提交",
|
||||
"B": "用户从第三方网站点击链接跳转到目标网站（顶层导航 GET）",
|
||||
"C": "第三方网站通过 JavaScript 发起的 XMLHttpRequest",
|
||||
"D": "第三方网站通过 img 标签发起的 GET 请求"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "SameSite=Lax 是一种折中策略。它允许第三方发起的顶层导航（即用户主动点击链接导致的 GET 请求）携带 Cookie，但阻止第三方发起的 POST 表单提交、AJAX 请求以及嵌入在 img/script 等标签中的跨站请求携带 Cookie。这样既保留了用户正常点击链接跳转的功能，又阻止了大部分 CSRF 攻击场景。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-012",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "SSRF（服务端请求伪造）攻击的攻击面是什么？",
|
||||
"options": {
|
||||
"A": "受害者浏览器",
|
||||
"B": "目标服务器的后端应用",
|
||||
"C": "DNS 服务器",
|
||||
"D": "数据库客户端"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "SSRF（Server-Side Request Forgery）是攻击者利用服务器端应用程序发起请求的功能，让服务器代替攻击者访问内部或外部资源。攻击面是服务器的后端应用——攻击者通过控制应用的请求目标 URL，使服务器向内网服务、云元数据接口等非预期地址发起请求。受害者浏览器是 XSS 的攻击面，DNS 服务器和数据库客户端不是 SSRF 的直接攻击面。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-013",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "攻击者利用 SSRF 访问 AWS 实例元数据服务时，通常请求的地址是？",
|
||||
"options": {
|
||||
"A": "http://127.0.0.1:8080",
|
||||
"B": "http://169.254.169.254/latest/meta-data/",
|
||||
"C": "http://10.0.0.1",
|
||||
"D": "http://localhost:3306"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "AWS EC2 实例元数据服务监听在特殊的链路本地地址 169.254.169.254 上，通过 HTTP 协议提供实例的临时凭证、安全组、用户数据等敏感信息。攻击者通过 SSRF 漏洞让目标服务器访问该地址，即可窃取云实例的 IAM 角色凭证等敏感信息。127.0.0.1:8080 和 localhost:3306 通常是本地服务端口，10.0.0.1 是常见的内网网关地址，但都不是 AWS 元数据服务的标准地址。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-014",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "以下哪项是防御 SSRF 攻击的推荐做法？",
|
||||
"options": {
|
||||
"A": "仅对用户输入进行前端校验",
|
||||
"B": "建立 URL 白名单并校验请求目标 IP 地址，拒绝内网地址",
|
||||
"C": "禁用服务器的 DNS 解析",
|
||||
"D": "要求所有请求必须使用 POST 方法"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "防御 SSRF 最有效的方法是在服务端建立 URL 白名单，同时校验解析后的 IP 地址，拒绝向内网地址（如 127.0.0.0/8、10.0.0.0/8、169.254.0.0/16 等）发起请求。前端校验可以被轻易绕过，禁用 DNS 解析会影响正常功能，使用 POST 方法并不能阻止 SSRF（服务端仍可向任意地址发送 POST 请求）。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-015",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "文件上传漏洞最直接的危害是什么？",
|
||||
"options": {
|
||||
"A": "占用服务器存储空间",
|
||||
"B": "攻击者可上传恶意文件（如 WebShell）从而控制服务器",
|
||||
"C": "导致其他用户密码泄露",
|
||||
"D": "造成网站排名下降"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "文件上传漏洞最直接也最严重的危害是攻击者可以上传恶意脚本文件（如 PHP WebShell），然后通过浏览器访问该文件，使恶意代码在服务器上执行，从而获得对服务器的控制权限。虽然占用存储空间是可能的附带影响，但远不及代码执行的危害。密码泄露和网站排名下降与文件上传漏洞没有直接因果关系。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-016",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "仅通过前端 JavaScript 验证文件扩展名来限制上传文件类型，为什么不够安全？",
|
||||
"options": {
|
||||
"A": "JavaScript 运行太慢会影响用户体验",
|
||||
"B": "攻击者可以禁用 JavaScript 或使用代理工具修改请求绕过前端验证",
|
||||
"C": "JavaScript 不支持正则表达式",
|
||||
"D": "浏览器会自动修改文件扩展名"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "前端验证完全在客户端执行，攻击者可以通过多种方式绕过：禁用浏览器 JavaScript、使用 Burp Suite 等代理工具拦截并修改上传请求、直接发送 HTTP 请求而不经过浏览器页面等。因此仅靠前端验证是不可靠的，必须在服务端再次验证文件类型、扩展名和内容。JavaScript 的运行速度和正则表达式支持都不是安全问题的原因，浏览器也不会自动修改扩展名。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-017",
|
||||
"type": "single_choice",
|
||||
"difficulty": 3,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "以下哪种文件上传防御策略最容易被绕过？",
|
||||
"options": {
|
||||
"A": "验证文件的 Magic Number（文件头签名）",
|
||||
"B": "仅通过检查 Content-Type 请求头判断文件类型",
|
||||
"C": "将上传文件重命名为随机字符串并存储在非 Web 根目录",
|
||||
"D": "使用独立的文件处理服务并禁用执行权限"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "Content-Type 请求头是由客户端自行设置的，攻击者可以使用代理工具轻松将其修改为任意值（如 image/png），而实际文件内容仍然可以是恶意脚本。因此仅检查 Content-Type 是最容易被绕过的方式。检查文件头签名需要伪造更深层的文件格式信息，重命名和非 Web 根目录存储使攻击者难以定位和执行恶意文件，独立服务加禁用执行权限从架构层面消除风险。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-018",
|
||||
"type": "single_choice",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "以下哪个 HTTP 响应头设置有助于防止浏览器嗅探 MIME 类型，从而降低 XSS 风险？",
|
||||
"options": {
|
||||
"A": "X-Frame-Options",
|
||||
"B": "X-Content-Type-Options: nosniff",
|
||||
"C": "Strict-Transport-Security",
|
||||
"D": "Access-Control-Allow-Origin"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "X-Content-Type-Options: nosniff 告诉浏览器必须遵守服务器声明的 Content-Type，不要进行 MIME 类型嗅探。这可以防止攻击者上传看似图片但实际是 HTML/JavaScript 的文件被浏览器当作脚本执行。X-Frame-Options 防止页面被嵌入 iframe（防点击劫持），Strict-Transport-Security 强制 HTTPS，Access-Control-Allow-Origin 用于 CORS 跨域控制。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-019",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "以下 Python 代码中，哪一段能有效防止 SQL 注入？",
|
||||
"options": {
|
||||
"A": "cursor.execute(\"SELECT * FROM users WHERE name='\" + user_input + \"'\")",
|
||||
"B": "cursor.execute(\"SELECT * FROM users WHERE name=%s\", (user_input,))",
|
||||
"C": "cursor.execute(f\"SELECT * FROM users WHERE name='{user_input}'\")",
|
||||
"D": "cursor.execute(\"SELECT * FROM users WHERE name=\" + user_input.strip())"
|
||||
},
|
||||
"answer": "B",
|
||||
"explanation": "选项 B 使用了参数化查询（占位符 %s 加元组参数），数据库驱动会自动处理参数转义和类型安全，SQL 结构与数据完全分离，是防止 SQL 注入的标准做法。选项 A 和 C 使用字符串拼接/f-string，用户输入直接嵌入 SQL 语句，存在注入风险。选项 D 仅做了 strip() 去空格，仍是字符串拼接，同样不安全。因此正确答案是 B。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "sc-020",
|
||||
"type": "single_choice",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "攻击者通过 SSRF 利用 `file:///etc/passwd` 协议读取服务器本地文件，这说明应用程序存在什么问题？",
|
||||
"options": {
|
||||
"A": "应用程序未限制请求使用的协议类型",
|
||||
"B": "应用程序的防火墙配置错误",
|
||||
"C": "应用程序使用了弱密码",
|
||||
"D": "应用程序的数据库未授权"
|
||||
},
|
||||
"answer": "A",
|
||||
"explanation": "如果应用程序允许用户控制 URL 并未限制协议类型，攻击者可以使用 file://、gopher://、dict:// 等非 HTTP 协议来读取本地文件或探测内部服务。正确的做法是严格限制只允许 http:// 和 https:// 协议，并校验请求目标。防火墙配置错误、弱密码和数据库未授权都与 SSRF 中的协议滥用无关。因此正确答案是 A。",
|
||||
"source": null,
|
||||
"related": []
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,148 @@
|
||||
{
|
||||
"topic": "web-security",
|
||||
"type": "true_false",
|
||||
"schema_version": "1.0.0",
|
||||
"generated": "2026-09-17T00:00:00+08:00",
|
||||
"questions": [
|
||||
{
|
||||
"id": "tf-001",
|
||||
"type": "true_false",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "XSS 攻击的目标是窃取或篡改客户端（浏览器端）的数据，而不是直接攻击服务器。",
|
||||
"answer": true,
|
||||
"explanation": "正确。XSS 攻击的主要目标是在受害者的浏览器中执行恶意脚本，从而窃取 Cookie、会话令牌、篡改页面内容或进行钓鱼等操作。它是一种客户端攻击，虽然恶意脚本可能存储在服务器上（存储型），但攻击效果发生在用户浏览器端。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-002",
|
||||
"type": "true_false",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "使用了 HTTPS 加密传输的 Web 应用不会受到 SQL 注入攻击。",
|
||||
"answer": false,
|
||||
"explanation": "错误。HTTPS 只负责加密客户端与服务器之间的通信传输过程，防止数据在传输中被窃听或篡改。但 SQL 注入发生在服务端应用层——恶意输入通过 HTTPS 传输后仍然会被拼接到 SQL 查询中。加密传输与应用层输入验证是两个不同层面的安全问题。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-003",
|
||||
"type": "true_false",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"csrf"
|
||||
],
|
||||
"question": "CSRF 攻击中，攻击者需要窃取用户的 Cookie 才能完成攻击。",
|
||||
"answer": false,
|
||||
"explanation": "错误。CSRF 攻击的关键在于浏览器会在请求中自动携带目标站点的 Cookie，攻击者无需窃取或知道 Cookie 的具体内容。攻击者只需诱导用户访问恶意页面或点击恶意链接，浏览器会自动在请求中附带目标站点的有效 Cookie，从而使请求被服务器认为是合法的。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-004",
|
||||
"type": "true_false",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "SSRF 漏洞只能用于访问内网资源，无法对外网发起请求。",
|
||||
"answer": false,
|
||||
"explanation": "错误。SSRF 不仅可以让服务器访问内网资源（如内网数据库、管理后台），也可以对外网发起请求。攻击者可以利用 SSRF 进行端口扫描、访问外部 API、探测云服务元数据等。SSRF 的「伪造请求」特性意味着它可以访问服务器能够触及的任何网络地址。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-005",
|
||||
"type": "true_false",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "在文件上传功能中，仅将上传目录的文件执行权限禁用，就可以完全防止文件上传漏洞。",
|
||||
"answer": false,
|
||||
"explanation": "错误。禁用上传目录的执行权限是一种有效的缓解措施，但不能「完全防止」文件上传漏洞。在某些配置下（如 Nginx 的 misconfiguration、解析漏洞、或配合本地文件包含 LFI 漏洞），攻击者仍可能利用上传的文件。安全防御应采用多层策略：验证文件类型、重命名文件、限制大小、扫描恶意内容、设置正确的目录权限等。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-006",
|
||||
"type": "true_false",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"xss"
|
||||
],
|
||||
"question": "HttpOnly 标志的 Cookie 无法被 JavaScript 的 document.cookie 读取，因此可以完全防止 XSS 攻击。",
|
||||
"answer": false,
|
||||
"explanation": "错误。HttpOnly 标志确实可以防止 JavaScript 读取 Cookie，从而保护会话令牌不被 XSS 窃取。但 XSS 的危害远不止窃取 Cookie——攻击者仍可以通过注入脚本来篡改页面内容、进行钓鱼攻击、记录键盘输入、发起 CSRF 请求等。HttpOnly 只是减轻了 XSS 的一种具体危害，而非防止 XSS 攻击本身。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-007",
|
||||
"type": "true_false",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"sql注入"
|
||||
],
|
||||
"question": "参数化查询（Prepared Statements）通过将 SQL 结构与数据分离来防止 SQL 注入。",
|
||||
"answer": true,
|
||||
"explanation": "正确。参数化查询的核心机制是先定义 SQL 语句的结构（使用占位符），然后单独传递参数值。数据库引擎会将参数值严格作为数据处理，不会将其解释为 SQL 命令的一部分，从而从根本上杜绝了通过输入改变 SQL 语义的可能性。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-008",
|
||||
"type": "true_false",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"csrf"
|
||||
],
|
||||
"question": "GET 请求不会受到 CSRF 攻击，只有 POST 请求才需要 CSRF 防护。",
|
||||
"answer": false,
|
||||
"explanation": "错误。GET 请求同样可能受到 CSRF 攻击。如果应用程序使用 GET 请求执行状态更改操作（如 `GET /delete?id=1`），攻击者可以通过 img 标签、链接等方式诱导浏览器发起 GET 请求。正确的做法是：所有状态更改操作应使用 POST/PUT/DELETE 等方法，并对所有修改数据的请求实施 CSRF 防护。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-009",
|
||||
"type": "true_false",
|
||||
"difficulty": 2,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"ssrf"
|
||||
],
|
||||
"question": "对用户输入的 URL 进行黑名单过滤（如禁止 127.0.0.1）是防御 SSRF 的最可靠方法。",
|
||||
"answer": false,
|
||||
"explanation": "错误。黑名单过滤很容易被绕过。攻击者可以使用：①十进制/十六进制/八进制 IP 表示（如 2130706433、0x7f000001）；②DNS 重绑定技术；③IPv6 地址（::1）；④域名指向内网地址（如 nip.io）；⑤URL 编码和重定向等方式绕过。白名单 + 解析后 IP 校验才是更可靠的方案。",
|
||||
"source": null,
|
||||
"related": []
|
||||
},
|
||||
{
|
||||
"id": "tf-010",
|
||||
"type": "true_false",
|
||||
"difficulty": 1,
|
||||
"tags": [
|
||||
"web安全",
|
||||
"文件上传"
|
||||
],
|
||||
"question": "将上传的文件重命名为随机字符串（如 UUID）可以有效防止攻击者通过猜测文件名来访问上传的恶意文件。",
|
||||
"answer": true,
|
||||
"explanation": "正确。将上传文件重命名为随机且不可预测的名称（如 UUID），攻击者无法猜测文件路径来直接访问和执行上传的恶意脚本。这是文件上传安全防御的一个重要措施，但通常需要配合其他策略（如类型验证、存储位置隔离等）一起使用。",
|
||||
"source": null,
|
||||
"related": []
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user