Welcome, admin
", "B": "Welcome,
", "C": "Welcome,
", "D": "Welcome,
" }, "answer": "C", "explanation": "选项 C 直接将用户输入的 `name` 参数未经任何转义或过滤就输出到 HTML 页面中，攻击者可以构造 `` 等恶意参数值实现注入。选项 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": [] } ] }