网站安全漏洞检查方法

本文是一篇通用技术文章，介绍个人网站（Spring Boot + Nginx + PostgreSQL 技术栈）的安全自查方法。

文中所有命令中的域名 example.com 为占位符，请替换为你的实际站点域名。

一套可复用的网站安全自查流程：从原理到命令，逐项说明每个检查点「是什么、有什么危害、怎么查、具体步骤、怎么修」。

一、概述与检查流程

网站安全自查的目标，是在攻击者之前发现可被利用的弱点。整个流程拆分为「信息收集 → 黑盒探测 → 功能接口测试 → 依赖与配置审查 → 汇总评估」五个阶段，覆盖传输层、应用层、数据层和运维层四个维度。

全部使用 curl、openssl 和 代码审查 完成，不需要专业渗透工具，适合个人站长或小团队定期自查。每个检查点遵循同一套思考框架：先理解攻击原理，再评估危害，最后用具体命令验证。

flowchart TD
    A[确定检查范围<br/>域名 / 技术栈 / 功能清单] --> B[信息收集<br/>响应头 / TLS 证书 / 版本号]
    B --> C[黑盒探测<br/>敏感文件 / 目录列表 / 错误页]
    C --> D[功能接口测试<br/>SQL 注入 / XSS / 上传 / 鉴权]
    D --> E[依赖与配置审查<br/>CVE 漏洞 / 暴露服务]
    E --> F[汇总评估<br/>按严重程度分级]
    F --> G[输出报告<br/>修复建议与优先级]

检查原则：只做无害探测（请求不存在的路径、读取响应头、审查代码），不注入破坏性 payload、不暴力尝试登录，避免对线上服务造成影响。涉及登录爆破、注入攻击等主动测试，应在授权范围内、对测试环境进行。

二、检查点详解

检查点 01：安全响应头检查 —— 高危

原理

HTTP 响应头是服务器随网页一起返回给浏览器的一组元信息。其中有一类「安全响应头」，专门指示浏览器对页面执行特定的安全策略——例如「只允许 HTTPS」「不允许被嵌入 iframe」「只加载白名单来源的资源」。这些策略由浏览器自动执行，不需要用户参与。若服务器未下发这些响应头，浏览器就按最宽松的默认行为处理页面，等于放弃了免费的防线。

flowchart LR
    subgraph 无安全头[无安全响应头 · 危险]
        A1[服务器] -->|普通响应| B1[浏览器]
        B1 --> C1[可被嵌入 iframe<br/>可被降级为 HTTP<br/>恶意脚本无拦截]
    end
    subgraph 有安全头[有安全响应头 · 安全]
        A2[服务器] -->|响应 + 安全策略| B2[浏览器]
        B2 --> C2[禁止 iframe 嵌入<br/>强制 HTTPS<br/>脚本白名单拦截]
    end

危害

缺少 HSTS：攻击者可发起 SSL 剥离攻击，把 HTTPS 请求降级为 HTTP 截获流量。
缺少 X-Frame-Options / CSP：页面可被嵌入恶意网站的透明 iframe，诱导用户点击（点击劫持）。
缺少 X-Content-Type-Options：浏览器可能对文件类型做 MIME 嗅探，把伪装成图片的脚本当脚本执行。
缺少 CSP：XSS 攻击缺少最后一道「即使注入也不执行」的防线。

检查方法

用 curl 抓取响应头，逐项核对是否存在上述安全头。响应头是公开信息，属于无害探测。

检查步骤

# 抓取首页全部响应头
curl -sI https://example.com/

# 只过滤安全相关响应头（无输出即缺失）
curl -sI https://example.com/ | grep -iE \
  "strict-transport|x-frame|x-content-type|content-security|referrer-policy|permissions-policy"

解决办法

在 Nginx 的 443 server 块内添加安全响应头，并隐藏版本号：

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' data: https:; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src https://fonts.gstatic.com; script-src 'self' 'unsafe-inline'; connect-src 'self'" always;
server_tokens off;

注意：server_tokens off; 建议放在 http {} 全局层级（而非某个 server 块内），这样所有站点（含 80 跳转块）都不再泄露版本号。改完后执行 nginx -t 检查语法，再 systemctl reload nginx 生效。CSP 中的 style-src 'unsafe-inline' 是内联样式必需项，若站点不使用内联脚本可去掉 script-src 'unsafe-inline' 以收紧策略。

检查点 02：TLS/SSL 配置检查 —— 安全

原理

TLS 负责 HTTPS 的加密传输。安全性取决于三件事：证书是否有效（是否过期、是否被信任的 CA 签发）、协议版本（是否还支持已被攻破的 SSLv3 / TLS 1.0 / 1.1）、密码套件（是否使用强加密算法）。

危害

证书过期或不受信任：浏览器报警，用户可能被中间人攻击。
支持弱协议（TLS 1.0 等）：可被 BEAST、POODLE 等降级攻击破解。
使用弱密码套件（如 RC4、3DES）：加密可被暴力破解。

检查方法

用 openssl 的 s_client 与服务器建立 TLS 连接，读取证书信息并指定协议版本测试。

检查步骤

# 查看证书有效期、签发者
echo | openssl s_client -connect example.com:443 \
  -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer

# 测试 TLS 1.2 是否可用及协商的密码套件
echo | openssl s_client -connect example.com:443 \
  -servername example.com -tls1_2 2>&1 | grep -E "Protocol|Cipher"

解决办法

证书到期前续期：设置日历提醒（DV 证书通常一年期），或使用 Let's Encrypt 自动续期。
仅启用 TLS 1.2 / 1.3，禁用 SSLv3 / TLS 1.0 / 1.1：

ssl_protocols TLSv1.2 TLSv1.3;

使用强密码套件（ECDHE + AES-GCM，支持前向保密），在 Nginx 中显式配置 ssl_ciphers，并关闭不安全的旧套件。

检查点 03：敏感文件暴露检查 —— 安全

原理

网站目录里常残留一些不应公开访问的文件：.git 仓库（泄露全部源码历史）、.env / application.yml（泄露数据库密码、密钥）、备份压缩包（泄露整站源码和数据）。如果 Web 服务器允许直接访问这些路径，等于把钥匙挂在门口。

危害

下载源码：攻击者可分析出所有漏洞，精准攻击。
获取数据库凭据：直接连库拖数据。
下载备份：一次性获得整站源码 + 数据库。

检查方法

用 curl 探测常见敏感路径，观察 HTTP 状态码。返回 200 且内容非空即存在风险。

检查步骤

# 逐个探测常见敏感路径
for p in .git/config .git/HEAD .env application.yml \
         application.properties backup.zip web.xml .DS_Store; do
  echo "=== /$p ==="
  curl -s -o /dev/null -w "HTTP %{http_code} size=%{size_download}\n" \
    "https://example.com/$p"
done

解决办法

用 .gitignore 排除 .env、application.yml、备份文件等敏感文件，避免进入版本库。
在 Nginx 中显式拒绝 .git 等目录的访问：

location ~ /\.git {
    deny all;
    return 404;
}

数据库密码、密钥等通过环境变量注入（如 DB_PASSWORD=${DB_PASSWORD}），不要写死在配置文件。
备份文件存放在服务器目录之外（如对象存储私有桶），不要放在 Web 根目录。

检查点 04：目录列表检查 —— 安全

原理

Web 服务器（Nginx、Apache）默认对没有首页文件的目录返回「Index of /xxx」文件列表。开启后，访问 /uploads/ 就能看到该目录下所有文件名，等于把目录结构直接暴露给攻击者。

危害

暴露全部文件路径，便于攻击者定位敏感文件。
配合其他漏洞（如文件上传），放大攻击面。

检查方法

直接请求目录路径（不带文件名），看返回内容。403 表示已禁用；200 且包含「Index of」字样表示开启。

检查步骤

# 请求上传目录，看是否返回文件列表
curl -s -o /dev/null -w "HTTP %{http_code}\n" "https://example.com/uploads/"
curl -s "https://example.com/uploads/" | head -5

解决办法

确保 Nginx 未开启 autoindex on（默认关闭，无需额外配置）。
若需显式加固，可在目录 location 中声明 autoindex off;。
对不应列出的目录，可返回 403 拒绝访问。

检查点 05：错误页信息泄露检查 —— 低危

原理

未自定义的错误页可能泄露堆栈跟踪、框架版本、数据库结构、内部文件路径。这些信息帮助攻击者确认技术栈、定位漏洞点。

危害

泄露技术栈和版本，攻击者可直接检索对应漏洞。
泄露内部路径和 SQL 结构，辅助构造注入攻击。

检查方法

访问不存在的路径触发 404，或访问能触发异常的路径，检查错误页内容是否包含堆栈、版本号。

检查步骤

# 触发 404，查看错误页内容
curl -s "https://example.com/nonexistent-page-xyz"

# 触发 500（访问 Spring 错误端点）
curl -s "https://example.com/error"

解决办法

Spring Boot 生产环境关闭堆栈跟踪输出：

server:
  error:
    include-stacktrace: never
    include-message: never

自定义统一错误页（404 / 500），只显示友好提示，不返回任何内部细节。
生产环境关闭 debug 日志和开发模式。

检查点 06：后台鉴权检查 —— 安全

原理

后台管理接口（/admin/**）必须校验登录态。正确做法是：未登录访问后台 URL 时，被拦截器重定向到登录页。若鉴权缺失，任何人都能直接操作后台。

危害

未授权访问：任意人可发布/删除文章、上传文件、修改站点配置。
配合上传漏洞可进一步获取服务器控制权。

检查方法

不携带任何 Cookie，直接请求后台 URL，观察是否被重定向到登录页。

检查步骤

# 未登录访问后台首页，应 302 跳转登录页
curl -s -o /dev/null -w "HTTP %{http_code} redirect=%{redirect_url}\n" \
  "https://example.com/admin/dashboard"

解决办法

用拦截器（HandlerInterceptor）或过滤器对 /admin/** 做会话校验，未登录统一重定向到登录页。
后台登录使用强密码，并配合登录限流（见检查点 10）。
可考虑对后台路径做访问来源限制（如仅允许特定 IP）。

检查点 07：SQL 注入检查 —— 安全

原理

SQL 注入发生在用户输入被直接拼接进 SQL 语句时。攻击者通过输入特殊字符（如单引号、注释符）改变查询逻辑，甚至执行任意 SQL。正确做法是使用参数化查询（PreparedStatement / JPA 的 @Param），让数据库把输入当数据而非代码。

flowchart TD
    subgraph 拼接[字符串拼接 · 危险]
        A1[输入: ' OR 1=1 --] --> B1["SELECT * FROM user<br/>WHERE name='' OR 1=1 --'"]
        B1 --> C1[条件恒真 → 绕过认证]
    end
    subgraph 参数化[参数化查询 · 安全]
        A2[输入: ' OR 1=1 --] --> B2["SELECT * FROM user<br/>WHERE name=?"]
        B2 --> C2[输入被当数据 → 查无此人]
    end

危害

拖库：读取全部用户数据、文章、后台凭据。
绕过认证、篡改数据、删除数据。
部分数据库可写文件，进一步获取服务器权限。

检查方法

双管齐下：代码审查（搜索 Repository 中是否有字符串拼接查询）+ 黑盒探测（向搜索、筛选等参数输入特殊字符，观察是否报 SQL 错误）。

检查步骤

# 1. 代码审查：搜索是否有拼接 SQL（应全部为参数化查询）
grep -rn "STRPOS\|@Query\|nativeQuery" src/main/java/com/pipizhou/repository/

# 2. 黑盒探测：向搜索参数输入单引号，观察是否报错
curl -s -o /dev/null -w "HTTP %{http_code}\n" "https://example.com/archive?kw=%27"

解决办法

所有数据库查询一律使用参数化查询（JPA 的 @Param、Spring Data 的派生查询、JDBC 的 PreparedStatement），禁止字符串拼接 SQL。
若必须使用 @Query，用命名参数 :name 而非 ? 位置占位符，且不要拼接用户输入。
建立代码审查制度：每次提交前检查 Repository 层是否有拼接痕迹。

检查点 08：XSS 跨站脚本检查 —— 低危

原理

XSS 发生在用户可控内容未经转义直接输出到页面时。攻击者注入的 <script> 会在其他用户浏览器中执行。在模板引擎中，th:text 会自动转义（安全），而 th:utext 输出原始 HTML（不安全）。

flowchart LR
    A[攻击者提交评论<br/>含 &lt;script&gt; 窃取 Cookie] --> B[网站存储]
    B --> C[其他用户浏览页面]
    C --> D[脚本在受害者浏览器执行]
    D --> E[Cookie 被窃取<br/>会话被劫持]

危害

窃取 Cookie、会话劫持、冒充用户操作。
钓鱼、篡改页面内容、传播恶意代码。

检查方法

审查模板中所有输出点：用户可控输入（评论、搜索、表单）是否用转义方式输出；th:utext 输出的内容来源是否可信。

检查步骤

# 搜索模板中所有不转义输出（th:utext），逐一核对内容来源
grep -rn "th:utext" src/main/resources/templates/

# 搜索用户输入输出点（评论等），确认使用 th:text 转义
grep -rn "th:text" src/main/resources/templates/article/detail.html

解决办法

用户可控内容一律用 th:text 输出（自动 HTML 转义），禁止对用户输入使用 th:utext。
th:utext 仅用于可信内容（如管理员撰写、经过白名单过滤的富文本）。
对需要渲染富文本/公式的场景，先做 HTML 标签白名单过滤，再输出。
配置 CSP（见检查点 01）作为最后防线：即使注入成功，脚本也被浏览器拦截。

检查点 09：文件上传安全检查 —— 中危

原理

文件上传接口是攻击面最大的功能之一。需要检查三点：文件名是否由服务端生成（防止路径穿越）、路径参数是否校验（防止写入任意目录）、文件类型是否有白名单（防止上传可执行/可渲染文件）。

flowchart TD
    A[上传文件] --> B{文件名是否<br/>服务端生成}
    B -->|否| C[路径穿越<br/>写入任意目录]
    B -->|是| D{类型是否<br/>白名单校验}
    D -->|否| E[上传 HTML/SVG<br/>存储型 XSS]
    D -->|是| F[安全]

危害

路径穿越：把文件写到任意目录，覆盖配置文件。
上传 WebShell：直接控制服务器。
上传 HTML/SVG：造成存储型 XSS，访问图片的访客中招。

检查方法

审查上传控制器代码，重点看文件名生成、路径拼接、类型校验三处。

检查步骤

# 1. 文件名是否 UUID 生成（防路径穿越）
grep -n "UUID\|transferTo\|resolve" src/main/java/com/pipizhou/controller/admin/AdminUploadController.java

# 2. 路径参数（如 year）是否有正则校验
grep -n "matches\|Pattern" src/main/java/com/pipizhou/controller/admin/AdminUploadController.java

# 3. 是否有扩展名 / MIME 白名单
grep -n "getContentType\|getOriginalFilename\|extension" src/main/java/com/pipizhou/controller/admin/AdminUploadController.java

解决办法

文件名由服务端生成 UUID，仅保留原扩展名，禁止使用用户提供的文件名。
路径参数（如年份目录）用正则白名单校验（如 \d{4}）。
扩展名白名单 + 文件头（magic bytes）双重校验，仅允许图片类型：

// 扩展名白名单 + 文件头校验
private boolean isAllowedImage(MultipartFile file) {
    String ext = getExtension(file.getOriginalFilename()).toLowerCase();
    if (!Set.of("jpg", "jpeg", "png", "webp", "gif").contains(ext)) return false;
    // 读取文件头 magic bytes 校验：JPEG(FF D8 FF)、PNG(89 50 4E 47)、GIF(GIF8)、WEBP(RIFF....WEBP)
    return magicBytesMatch(file);
}

限制上传文件大小（如 10MB），防止磁盘耗尽。

检查点 10：认证与 CSRF 检查 —— 高危

原理

这里包含两类问题。其一，暴力破解：登录接口若无速率限制、账号锁定或验证码，攻击者可无限穷举密码。其二，CSRF（跨站请求伪造）：表单若无一次性 token 校验，攻击者可构造恶意页面，诱导已登录的管理员浏览器自动提交后台操作请求（删文章、改配置）。

暴力破解 vs 登录限流：登录限流就是给登录接口装一个「失败计数器」——每次密码错误计数 +1，连续错满 N 次就临时锁定一段时间，锁定期过后清零。没有限流时攻击者可以无限试密码，弱口令几分钟就被穷举出来。

flowchart TD
    subgraph 无限制[无登录限流 · 危险]
        A1[攻击者] --> A2[无限次尝试] --> A3[穷举破解] --> A4[破解成功<br/>后台沦陷]
    end
    subgraph 有限制[有登录限流 · 安全]
        B1[攻击者] --> B2[尝试密码] --> B3[失败计数 ≥ N] --> B4[锁定一段时间<br/>破解失败]
    end

CSRF 攻击流程：浏览器会自动携带已登录站点的 Cookie 发送请求，攻击者利用这一点，让受害者在不知情时向后台提交操作。

flowchart LR
    A[恶意网站] -->|诱导访问| B[受害者浏览器]
    B -->|自动携带 Cookie<br/>发送后台请求| C[后台接口]
    C --> D[执行删除/修改操作]

危害

弱口令被暴力破解，后台沦陷。
CSRF：管理员在不知情时被伪造请求执行后台操作。

检查方法

审查登录控制器是否有限流/锁定逻辑；检查所有 POST 表单（登录、评论、友链、后台）是否包含 CSRF token。

检查步骤

# 1. 登录控制器：是否有速率限制 / 失败锁定
grep -n "LoginAttemptService\|isLocked\|recordFailure\|lock" src/main/java/com/pipizhou/controller/admin/AdminAuthController.java

# 2. 登录表单：是否有 CSRF token 字段
grep -n "csrf\|_token" src/main/resources/templates/admin/login.html

# 3. 评论 / 友链表单：是否有 CSRF token
grep -rn "csrf\|_token" src/main/resources/templates/article/detail.html src/main/resources/templates/friend-links.html

解决办法

登录限流：实现失败计数 + 临时锁定。按「用户名 + IP」为键，失败满 N 次（如 5 次）锁定 15 分钟，锁定期间拒绝登录并提示剩余时间，成功登录后清零。可用内存 Map 实现（单实例），或用 Redis（多实例）。
CSRF 防护：为所有 POST/PUT/DELETE 请求校验一次性 Token。两种实现：
- 引入 Spring Security 的 CSRF 模块（开箱即用）；
- 自实现 Token 中间件：按会话生成 UUID Token，通过拦截器校验请求参数与会话 Token 一致，失败返回 403；用 @ControllerAdvice 把 Token 注入所有模板。
所有 POST 表单加隐藏字段 <input type="hidden" name="_csrf" th:value="${_csrf}">，JS 发起的 POST（如图片上传）在请求体中携带 Token。

检查点 11：依赖 CVE 检查 —— 高危

原理

开源框架和依赖会定期公开安全漏洞（CVE）。使用过旧版本意味着已知漏洞可被公开利用。例如 Spring Boot 3.2.5 发布于 2024 年 4 月，其内置的 Spring Framework 6.1.6 已被多个 CVE 覆盖。

flowchart LR
    A[Spring Boot 3.2.5] --> B[内置 Framework 6.1.6]
    B --> C[已知 CVE 公开]
    C --> D[攻击者按版本<br/>检索利用方式]
    D --> E[精准攻击]

危害

路径遍历（CVE-2024-38816 / 38819）：攻击者可读取服务器任意文件。
拒绝服务（CVE-2024-38820 / 38821 / 50349）：构造请求拖垮服务。
logback 日志组件 DoS（CVE-2024-12798）。

检查方法

查看 pom.xml 中的依赖版本，对照官方安全公告确认受影响范围。

检查步骤

# 1. 查看 Spring Boot 及关键依赖版本
grep -E "spring-boot|version|logback" pom.xml | head -20

# 2. 到官方安全公告核对 CVE 影响版本
# https://spring.io/security  → 按 Spring Framework 版本检索

解决办法

定期升级依赖到官方修复版本。Spring Boot 3.2.x 系列升级到最新补丁版本（如 3.2.12，内置 Spring Framework 6.1.15），一次性覆盖相关 CVE。
同 minor 版本内补丁升级 API 兼容，升级成本低；升级后回归测试核心功能（文章渲染、后台、上传）。
使用依赖扫描工具（如 OWASP Dependency-Check、Maven 的 versions 插件）定期检查已知漏洞。

检查点 12：暴露服务与信息泄露检查 —— 安全

原理

Spring Boot 的 actuator（监控端点）、H2 控制台、Swagger 等调试接口若暴露到公网，会泄露配置、环境变量、Bean 信息。此外，服务器响应头中的版本号（如 nginx/1.27.2）也是信息泄露。

危害

actuator/env 泄露数据库密码、密钥等环境变量。
版本号泄露：攻击者检索该版本已知漏洞精准攻击。

检查方法

探测常见调试路径；检查响应头是否泄露版本号。

检查步骤

# 1. 探测常见调试/监控路径（应全部 404）
for p in actuator actuator/health actuator/env h2-console \
         swagger-ui.html api-docs; do
  curl -s -o /dev/null -w "HTTP %{http_code}\n" "https://example.com/$p"
done

# 2. 检查响应头版本泄露
curl -sI https://example.com/ | grep -i "^server"

解决办法

生产环境不引入或禁用 actuator、H2 控制台、Swagger 等调试组件；若必须使用 actuator，仅暴露 health 端点并限制访问来源。
Nginx 配置 server_tokens off; 隐藏版本号（放在 http {} 全局层级，见检查点 01）。
关闭框架默认的调试/开发模式，生产环境使用生产配置 profile。

补充检查点（常见遗漏项）

以下问题不单列检查点，但自查时应一并覆盖：

1. 外部链接协议校验（中危） 用户提交的 URL（如友情链接）若未校验协议，可提交 javascript: 链接造成点击型 XSS。解决办法：仅允许 http:// / https:// 协议，拒绝其他协议。

2. X-Forwarded-For 信任（中危） 后端若直接信任客户端传来的 X-Forwarded-For 头，攻击者可伪造 IP 污染访问统计、绕过基于 IP 的登录限流。解决办法：由 Nginx 在连接层用覆盖模式设置真实 IP，后端只信 Nginx 写入的头：

proxy_set_header X-Real-IP $remote_addr;        # 连接层真实 IP，客户端无法伪造
proxy_set_header X-Forwarded-For $remote_addr;  # 覆盖模式，丢弃客户端传入值

后端优先读取 X-Real-IP，而不是直接信任 X-Forwarded-For。

3. 输出转义（低危） 动态生成 XML（如 sitemap）、JSON 时，对特殊字符（< > & " '）做转义，防止注入。

4. HTTP 方法限制（低危） 服务器默认允许 OPTIONS 等非必要方法。可在 Nginx 层限制只允许 GET/POST/PUT/DELETE，或按需关闭。

三、修复优先级

按「先堵最容易被利用的口子，再升级加固」的原则排序。前两项投入小、见效快，建议优先处理。

Nginx 添加安全响应头（高危 · 投入最小）：在 443 server 块内加 add_header（HSTS / X-Frame-Options / X-Content-Type-Options / CSP / Referrer-Policy），server_tokens off 放 http {} 全局隐藏版本号。改完 nginx -t 测试后 systemctl reload nginx。
升级 Spring Boot 依赖（高危）：升级到当前 minor 系列的最新补丁版本，一次性修复 Spring Framework 与 logback 的已知 CVE。升级后回归测试文章渲染、后台功能。
登录接口加暴力破解防护（高危）：实现登录失败次数限制 + 临时锁定（如 5 次失败锁定 15 分钟），或接入验证码。
引入 CSRF 防护（高危）：为所有 POST 表单生成并校验一次性 token。可引入 Spring Security 的 CSRF 模块，或自实现简单的 token 中间件。
上传文件类型白名单（中危）：校验扩展名 + MIME 类型，仅允许图片（jpg/png/webp/gif），禁止 html/svg 等可渲染文件。
友链 URL 协议校验（中危）：仅允许 http/https 协议，拒绝 javascript: 等危险协议。
其余加固（低危）：富文本/公式内容做 HTML 白名单过滤；sitemap 输出转义 XML 特殊字符；自定义统一错误页；Nginx 层正确设置 X-Forwarded-For。

四、附录：命令速查

以下命令覆盖全部检查点，可复制保存为自查脚本，定期对站点执行。将 example.com 替换为你的实际域名。

# ===== 1. 安全响应头 =====
curl -sI https://example.com/ | grep -iE \
  "strict-transport|x-frame|x-content-type|content-security|referrer-policy"

# ===== 2. TLS 证书与协议 =====
echo | openssl s_client -connect example.com:443 -servername example.com \
  2>/dev/null | openssl x509 -noout -dates -subject -issuer

# ===== 3. 敏感文件 =====
for p in .git/config .env application.yml backup.zip; do
  curl -s -o /dev/null -w "/$p → %{http_code}\n" "https://example.com/$p"
done

# ===== 4. 目录列表 =====
curl -s -o /dev/null -w "uploads/ → %{http_code}\n" "https://example.com/uploads/"

# ===== 5. 错误页信息泄露 =====
curl -s "https://example.com/nonexistent-page-xyz"

# ===== 6. 后台鉴权 =====
curl -s -o /dev/null -w "admin → %{http_code} %{redirect_url}\n" \
  "https://example.com/admin/dashboard"

# ===== 7. SQL 注入探测（无害） =====
curl -s -o /dev/null -w "kw=' → %{http_code}\n" "https://example.com/archive?kw=%27"

# ===== 8. 暴露服务 =====
for p in actuator actuator/env h2-console swagger-ui.html api-docs; do
  curl -s -o /dev/null -w "/$p → %{http_code}\n" "https://example.com/$p"
done

# ===== 9. 版本泄露 =====
curl -sI https://example.com/ | grep -i "^server"

代码审查要点清单

Repository 查询是否全部参数化（防 SQL 注入）
模板输出：用户输入用 th:text 转义，th:utext 内容来源是否可信（防 XSS）
上传：文件名服务端生成、路径参数校验、类型白名单（防路径穿越/WebShell）
登录：限流、锁定、验证码（防暴力破解）
所有 POST 表单：CSRF token（防跨站请求伪造）
依赖版本：对照官方安全公告（防已知 CVE）

参考来源

Spring Framework Security Advisories — CVE-2024-38816 / 38819 / 38820 / 38821 / 50349 影响版本与修复版本
CVE-2024-12798 — logback-core 拒绝服务漏洞 — 影响 1.5.13 之前版本

皮皮舟印岁月

一、概述与检查流程

二、检查点详解

检查点 01：安全响应头检查 —— 高危

检查点 02：TLS/SSL 配置检查 —— 安全

检查点 03：敏感文件暴露检查 —— 安全

检查点 04：目录列表检查 —— 安全

检查点 05：错误页信息泄露检查 —— 低危

检查点 06：后台鉴权检查 —— 安全

检查点 07：SQL 注入检查 —— 安全

检查点 08：XSS 跨站脚本检查 —— 低危

检查点 09：文件上传安全检查 —— 中危

检查点 10：认证与 CSRF 检查 —— 高危

检查点 11：依赖 CVE 检查 —— 高危

检查点 12：暴露服务与信息泄露检查 —— 安全

补充检查点（常见遗漏项）

三、修复优先级

四、附录：命令速查

代码审查要点清单

参考来源

评论 (0)

发表评论

网站安全漏洞检查方法

一、概述与检查流程

二、检查点详解

检查点 01：安全响应头检查 —— 高危

检查点 02：TLS/SSL 配置检查 —— 安全

检查点 03：敏感文件暴露检查 —— 安全

检查点 04：目录列表检查 —— 安全

检查点 05：错误页信息泄露检查 —— 低危

检查点 06：后台鉴权检查 —— 安全

检查点 07：SQL 注入检查 —— 安全

检查点 08：XSS 跨站脚本检查 —— 低危

检查点 09：文件上传安全检查 —— 中危

检查点 10：认证与 CSRF 检查 —— 高危

检查点 11：依赖 CVE 检查 —— 高危

检查点 12：暴露服务与信息泄露检查 —— 安全

补充检查点（常见遗漏项）

三、修复优先级

四、附录：命令速查

代码审查要点清单

参考来源

相关阅读

AI Agent 智能体 Skill（技能）详解：从概念到实战

美国8月PPI深度分析：能源通胀再点燃，美联储加息前夜的全球资产定价重估

近封装光学（NPO）深度：AI 数据中心光互联的新主线

华为 GaussDB 与 PostgreSQL 全面对比

防爬实战·爬虫识别与防爬配置（访问日志分析全记录）

评论 (0)

发表评论