SpringBoot短信登錄安全防護方案

更新時間：2026年01月14日 08:33:14 作者：一路向北?

本文提出了一套基于手機短信驗證碼的安全登錄方案,采用多層次防護機制確保系統(tǒng)安全,下面就來詳細的介紹一下,感興趣的可以了解一下

一、總體設(shè)計思路

目標：在支持手機號+短信驗證碼快捷登錄的前提下，最大限度防止短信接口被批量刷號、撞庫、薅羊毛和攻擊，兼顧安全性、可用性和擴展性。
核心手段：限流 + 驗證碼安全 + 圖形/滑塊校驗 + 黑名單 + 接口簽名與防重放 + 嚴格業(yè)務(wù)校驗 + 監(jiān)控告警 + 合理緩存 + 審計日志 + 分布式鎖。
關(guān)鍵技術(shù)棧：Spring Boot 3、Spring Web、Spring Validation、Spring Security（可選）、Spring Data Redis、MyBatis/JPA、HTTPs、Nginx 限流（可選）。

后端將短信登錄拆分為兩個接口：

發(fā)送短信驗證碼：POST /api/auth/sendSmsCode
使用短信驗證碼登錄：POST /api/auth/loginBySms

二、后端限流策略

2.1 限流維度與規(guī)則

建議對以下維度分別限流，并組合判定：

單手機號：
- 每分鐘最多 1 次
- 每小時最多 3 次
- 每天最多 5~10 次（視業(yè)務(wù)而定）
IP 地址：
- 每分鐘最多 10 次
- 每小時最多 100 次
- 異常區(qū)域或代理 IP 收緊閾值
設(shè)備 ID / 設(shè)備指紋：
- 每分鐘最多 3 次
- 每天最多 10 次
組合維度：
- phone + IP、phone + deviceId，用于識別代理刷號

2.2 Redis 限流實現(xiàn)示例

使用 Redis 的 INCR + EXPIRE 或 Lua 腳本實現(xiàn)原子限流。

Redis Key 設(shè)計示例：

sms:send:phone:{phone}:1m
sms:send:phone:{phone}:1h
sms:send:phone:{phone}:1d
sms:send:ip:{ip}:1m
sms:send:device:{deviceId}:1m

Java 攔截器/切面實現(xiàn)偽代碼：

@Component
public class SmsRateLimiter {

    private final StringRedisTemplate stringRedisTemplate;

    public SmsRateLimiter(StringRedisTemplate stringRedisTemplate) {
        this.stringRedisTemplate = stringRedisTemplate;
    }

    public void checkSendLimit(String phone, String ip, String deviceId) {
        // 單手機號 1 分鐘一次
        assertAllowed(incrWithTtl("sms:send:phone:" + phone + ":1m", 60, 1));
        // 單手機號 1 小時 3 次
        assertAllowed(incrWithTtl("sms:send:phone:" + phone + ":1h", 3600, 3));
        // 單手機號 1 天 10 次
        assertAllowed(incrWithTtl("sms:send:phone:" + phone + ":1d", 86400, 10));
        // IP 限流
        assertAllowed(incrWithTtl("sms:send:ip:" + ip + ":1m", 60, 10));
        // 設(shè)備限流
        if (StringUtils.hasText(deviceId)) {
            assertAllowed(incrWithTtl("sms:send:dev:" + deviceId + ":1m", 60, 3));
        }
    }

    private long incrWithTtl(String key, long ttlSeconds, long max) {
        Long val = stringRedisTemplate.opsForValue().increment(key);
        if (val != null && val == 1L) {
            stringRedisTemplate.expire(key, Duration.ofSeconds(ttlSeconds));
        }
        return val == null ? 0 : val;
    }

    private void assertAllowed(long current) {
        if (current > 0 && current > 10_0000) {
            // 安全兜底，可自定義
        }
    }
}

實際代碼中需要根據(jù) key 區(qū)分不同規(guī)則，并在超過 max 時拋業(yè)務(wù)異常：

if (current > max) {
    throw new BusinessException("短信發(fā)送太頻繁，請稍后再試");
}

在 Controller 入口使用 @ControllerAdvice 捕獲異常，返回統(tǒng)一錯誤碼。

三、驗證碼安全機制

3.1 驗證碼基本規(guī)則

長度與復雜度：
- 一般為 6 位數(shù)字（便于輸入），高安全場景可使用數(shù)字+字母 6~8 位。
有效期：
- 建議 5 分鐘內(nèi)有效，同時單個驗證碼僅允許 5 次以內(nèi)的錯誤嘗試。
發(fā)送間隔：
- 與限流結(jié)合，發(fā)送后 60 秒內(nèi)不允許再次發(fā)送。

3.2 驗證碼存儲方式

推薦使用 Redis + 單向散列存儲：

Key 示例：sms:code:login:{phone}
Value 內(nèi)容：
- hash(code + salt)
- 失敗次數(shù) failCount
- 發(fā)送時間 sendTime

可用 JSON 或 Hash 結(jié)構(gòu)存儲。例如 Hash：

field: code -> 哈希值
field: times -> 已校驗次數(shù)
field: ts -> 發(fā)送時間戳

生成和存儲偽代碼：

public class SmsCodeService {

    private final StringRedisTemplate redisTemplate;
    private final SecureRandom secureRandom = new SecureRandom();

    public String generateAndStoreCode(String phone) {
        String code = String.format("%06d", secureRandom.nextInt(1_000_000));
        String salt = "sms-login-salt"; // 也可每次隨機，附加存儲
        String hash = DigestUtils.sha256Hex(code + salt);

        String key = "sms:code:login:" + phone;
        Map<String, String> map = new HashMap<>();
        map.put("code", hash);
        map.put("times", "0");
        map.put("ts", String.valueOf(System.currentTimeMillis()));

        redisTemplate.opsForHash().putAll(key, map);
        redisTemplate.expire(key, Duration.ofMinutes(5));

        return code; // 返回給短信通道，不返回給前端
    }
}

3.3 驗證流程與防破解

驗證步驟：
1. 從 Redis 讀取驗證碼記錄，校驗是否存在及是否過期。
2. 校驗錯誤次數(shù) times 是否超過 5 次，如果超過則刪除記錄并提示重新獲取。
3. 對用戶輸入的驗證碼做同樣的 hash 比對。
4. 驗證成功后刪除 Redis 記錄（防止重復使用）。
防暴力破解：
- 錯誤次數(shù)過多后，鎖定該手機號一段時間（例如 30 分鐘），記錄黑名單風險分。
- 結(jié)合 IP/設(shè)備 ID 統(tǒng)計錯誤率。
- 返回錯誤提示要模糊化：不要區(qū)分“驗證碼錯誤”和“手機號未注冊”等細節(jié)。

驗證碼驗證偽代碼：

public boolean verifyCode(String phone, String inputCode) {
    String key = "sms:code:login:" + phone;
    Map<Object, Object> map = redisTemplate.opsForHash().entries(key);
    if (map == null || map.isEmpty()) {
        throw new BusinessException("驗證碼已失效，請重新獲取");
    }
    int times = Integer.parseInt((String) map.getOrDefault("times", "0"));
    if (times >= 5) {
        redisTemplate.delete(key);
        throw new BusinessException("驗證碼錯誤次數(shù)過多，請重新獲取");
    }

    String salt = "sms-login-salt";
    String expectHash = (String) map.get("code");
    String actualHash = DigestUtils.sha256Hex(inputCode + salt);

    if (!actualHash.equals(expectHash)) {
        redisTemplate.opsForHash().put(key, "times", String.valueOf(times + 1));
        throw new BusinessException("驗證碼錯誤");
    }

    // 驗證通過，刪除
    redisTemplate.delete(key);
    return true;
}

四、圖形驗證碼 / 滑塊驗證

4.1 觸發(fā)時機

可配置多級觸發(fā)策略：

低風險：首次請求、單 IP 請求頻率正常 → 不觸發(fā)圖形驗證碼。
中風險：同一手機號短時間內(nèi)多次請求（如 2 次以上）、同一 IP 請求過快 → 要求前端先完成人機校驗（圖形/滑塊）。
高風險：IP 命中高危段 / 代理 / 黑名單、過去 24 小時該手機號多次失敗 → 強制圖形驗證碼 + 降低限流閾值，必要時直接拒絕。

后端可以在響應(yīng)中返回一個字段表示需要前端先做人機校驗：

{
  "code": 429,
  "message": "需要人機校驗",
  "data": {
    "needCaptcha": true,
    "captchaType": "SLIDER"
  }
}

4.2 滑塊驗證集成方式

可集成第三方服務(wù)（如極驗、hCaptcha 等），前端完成交互后拿到 validate token。
后端接口 sendSmsCode 需要攜帶該 token，并向第三方服務(wù)進行二次驗證：
- 驗證成功后才繼續(xù)短信發(fā)送。
- 驗證失敗則拒絕并計入風險評分。

偽代碼示例：

public void checkCaptchaIfNeeded(String phone, String ip, String deviceId, String captchaToken) {
    boolean needCaptcha = riskService.needCaptcha(phone, ip, deviceId);
    if (!needCaptcha) {
        return;
    }
    if (!StringUtils.hasText(captchaToken)) {
        throw new BusinessException("請完成人機校驗");
    }
    boolean pass = captchaClient.verify(captchaToken, ip);
    if (!pass) {
        throw new BusinessException("人機校驗失敗");
    }
}

五、黑名單機制

5.1 黑名單對象

手機號：虛擬號段、垃圾號段、被頻繁攻擊的賬號。
IP / IP 段：來自數(shù)據(jù)中心、代理、已知攻擊源。
設(shè)備 ID / 設(shè)備指紋：頻繁撞庫、批量注冊設(shè)備。

5.2 識別規(guī)則

結(jié)合限流數(shù)據(jù)、驗證碼錯誤率、登錄失敗率、行為特征（夜間大量集中請求等），為每個主體計算風險分。
超過閾值后寫入黑名單，并設(shè)置過期時間（例如 7 天）。
對于命中黑名單的請求，直接拒絕或返回“系統(tǒng)繁忙”。

5.3 存儲與查詢

Redis 黑名單（快速判定）：
- black:phone:{phone}
- black:ip:{ip}
- black:dev:{deviceId}
數(shù)據(jù)庫黑名單（持久化及運營管理）：
- 表 security_blacklist，定期與 Redis 同步。

表結(jié)構(gòu)示例：

CREATE TABLE security_blacklist (
    id           BIGINT PRIMARY KEY AUTO_INCREMENT,
    type         TINYINT NOT NULL COMMENT '1:phone,2:ip,3:device',
    value        VARCHAR(64) NOT NULL,
    reason       VARCHAR(255),
    risk_score   INT NOT NULL DEFAULT 0,
    expire_time  DATETIME,
    created_at   DATETIME NOT NULL,
    updated_at   DATETIME NOT NULL,
    UNIQUE KEY uk_type_value (type, value),
    KEY idx_expire_time (expire_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

六、接口安全：身份驗證、請求簽名、防重放

6.1 全站 HTTPS

所有短信相關(guān)接口必須走 HTTPS，防止中間人竊聽驗證碼。

6.2 請求簽名機制（建議 App 場景）

為移動 App 分配 appId 和 appSecret。
請求頭攜帶：X-App-Id、X-Timestamp、X-Nonce、X-Signature。
簽名算法示例：
- signature = HMAC-SHA256(appSecret, appId + timestamp + nonce + requestBody)。

后端驗證邏輯：

根據(jù) appId 查 appSecret。
校驗時間戳是否在允許誤差范圍內(nèi)（如 5 分鐘）。
檢查 nonce 是否在短時間內(nèi)重復（在 Redis 中記錄 nonce）。
使用相同算法計算簽名并與 X-Signature 對比。

防重放實現(xiàn)示例（Redis 存儲 nonce）：

public void validateSignature(String appId, String timestamp, String nonce, String signature, String body) {
    // 1. 校驗時間戳
    long ts = Long.parseLong(timestamp);
    if (Math.abs(System.currentTimeMillis() - ts) > 5 * 60 * 1000) {
        throw new BusinessException("請求已過期");
    }

    // 2. 校驗 nonce
    String nonceKey = "req:nonce:" + appId + ":" + nonce;
    Boolean success = redisTemplate.opsForValue().setIfAbsent(nonceKey, "1", Duration.ofMinutes(10));
    if (Boolean.FALSE.equals(success)) {
        throw new BusinessException("重復請求");
    }

    // 3. 計算簽名
    String appSecret = appSecretService.getSecret(appId);
    String data = appId + timestamp + nonce + body;
    String expected = hmacSha256Hex(appSecret, data);
    if (!expected.equalsIgnoreCase(signature)) {
        throw new BusinessException("簽名錯誤");
    }
}

七、業(yè)務(wù)邏輯校驗

7.1 手機號格式驗證

使用正則在后端強校驗：

@Pattern(regexp = "^1[3-9]\\d{9}$", message = "手機號格式不正確")
private String phone;

結(jié)合 Spring Validation：在 Controller 入?yún)?DTO 上增加注解。

7.2 歸屬地、運營商驗證

使用本地號段庫或第三方服務(wù)按需校驗：
- 過濾不支持的國家/地區(qū)號段。
- 對高風險國家號段可直接拒絕或收緊限流。
可增加 phone_region 表存儲號段歸屬信息，定期更新。

7.3 賬號狀態(tài)校驗

登錄前檢查該手機號對應(yīng)賬號是否處于：
- 凍結(jié)、注銷、風險控制狀態(tài)。
風控狀態(tài)下可要求額外的圖形驗證碼或密碼驗證。

八、監(jiān)控告警與審計

8.1 監(jiān)控內(nèi)容

短信發(fā)送量：按分鐘/小時/天統(tǒng)計，按通道、按國家/地區(qū)拆分。
發(fā)送成功率和失敗原因：區(qū)分運營商失敗/限流/黑名單/第三方通道錯誤。
驗證碼驗證失敗率：按手機號、IP、設(shè)備聚合。
黑名單增長情況：黑名單新增數(shù)量、命中次數(shù)。

8.2 告警策略

單位時間內(nèi)短信發(fā)送量激增或成功率驟降 → 通知運維與安全。
單 IP / 單設(shè)備 / 單號段在短時間內(nèi)請求激增 → 風控告警。
驗證碼錯誤率異常偏高 → 可能存在撞庫攻擊。

落地方案：

使用日志（Logback）輸出關(guān)鍵行為到專用索引字段，接入 ELK / Loki + Grafana。
配合 Prometheus 指標（Counter, Gauge），設(shè)置告警規(guī)則對接釘釘/企業(yè)微信/飛書。

8.3 日志審計

記錄但脫敏：手機號只保留前 3 位 + 后 4 位，例如 138****1234。
日志中禁止記錄明文驗證碼和完整身份證號等敏感信息。

九、緩存策略（Redis 等）

9.1 使用場景

驗證碼存儲 (sms:code:login:{phone})。
限流計數(shù) (sms:send:phone:{phone}:1m 等)。
黑名單快速判定 (black:phone:{phone})。
請求簽名防重放 nonce (req:nonce:{appId}:{nonce})。

9.2 防止內(nèi)存溢出與雪崩

TTL 策略：所有短信相關(guān) key 必須設(shè)置 TTL，且 ttl 不宜過長。
Key 前綴規(guī)范：便于運維統(tǒng)計和清理（如 sms:*、black:*）。
限流計數(shù)使用短 TTL 的整數(shù)，不存儲大對象。
最大內(nèi)存策略：在 Redis 中配置 maxmemory 和適當?shù)奶蕴呗裕ㄈ?allkeys-lru），并監(jiān)控內(nèi)存使用率。
降級方案：
- Redis 不可用時，可以暫時禁止短信發(fā)送，防止在無法限流時被惡意刷號。

十、數(shù)據(jù)庫設(shè)計與索引

10.1 短信發(fā)送日志表

用于審計和風控分析，不建議直接作為限流依據(jù)（限流放在 Redis）。

CREATE TABLE sms_send_log (
    id            BIGINT PRIMARY KEY AUTO_INCREMENT,
    phone         VARCHAR(32) NOT NULL,
    ip            VARCHAR(64),
    device_id     VARCHAR(64),
    scene         VARCHAR(32) NOT NULL COMMENT 'login, register 等',
    template_code VARCHAR(64) NOT NULL,
    content       VARCHAR(512) NOT NULL,
    status        TINYINT NOT NULL COMMENT '0:待發(fā)送,1:成功,2:失敗',
    fail_reason   VARCHAR(255),
    channel       VARCHAR(32) COMMENT '短信通道商',
    created_at    DATETIME NOT NULL,
    sent_at       DATETIME,
    INDEX idx_phone_scene_time (phone, scene, created_at),
    INDEX idx_ip_time (ip, created_at),
    INDEX idx_created_at (created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

可按時間（如按月）進行分表（結(jié)合 MySQL 分區(qū)/分表功能）。

10.2 驗證碼校驗日志表（可選）

記錄驗證碼驗證失敗情況，用于風控建模。

CREATE TABLE sms_verify_log (
    id          BIGINT PRIMARY KEY AUTO_INCREMENT,
    phone       VARCHAR(32) NOT NULL,
    ip          VARCHAR(64),
    device_id   VARCHAR(64),
    scene       VARCHAR(32) NOT NULL,
    success     TINYINT NOT NULL,
    reason      VARCHAR(255),
    created_at  DATETIME NOT NULL,
    INDEX idx_phone_time (phone, created_at),
    INDEX idx_ip_time (ip, created_at)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

10.3 黑名單表

參考前文 security_blacklist 設(shè)計，增加索引 uk_type_value 用于快速查找。

十一、分布式鎖：防重復發(fā)送

在高并發(fā)場景下，需要避免同一手機號在同一時間窗口內(nèi)被多次發(fā)送驗證碼。

11.1 Redis 分布式鎖

鎖 Key：lock:sms:send:{phone}，鎖過期時間設(shè)置為 5~10 秒。
發(fā)送驗證碼前先搶鎖，成功后執(zhí)行發(fā)送邏輯，最后釋放鎖（或等待過期）。

偽代碼示例：

public void sendSmsCode(String phone, String ip, String deviceId, String captchaToken) {
    String lockKey = "lock:sms:send:" + phone;
    String lockVal = UUID.randomUUID().toString();
    Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, lockVal, Duration.ofSeconds(10));
    if (Boolean.FALSE.equals(locked)) {
        throw new BusinessException("短信發(fā)送中，請稍后再試");
    }
    try {
        // 1. 黑名單校驗
        blacklistService.check(phone, ip, deviceId);
        // 2. 限流校驗
        smsRateLimiter.checkSendLimit(phone, ip, deviceId);
        // 3. 圖形/滑塊驗證
        checkCaptchaIfNeeded(phone, ip, deviceId, captchaToken);
        // 4. 生成并存儲驗證碼
        String code = smsCodeService.generateAndStoreCode(phone);
        // 5. 調(diào)用第三方短信通道發(fā)送
        smsChannelClient.sendLoginCode(phone, code);
        // 6. 記錄日志
        smsLogService.recordSendLog(...);
    } finally {
        // 釋放鎖（注意只釋放自己持有的鎖）
        String val = redisTemplate.opsForValue().get(lockKey);
        if (lockVal.equals(val)) {
            redisTemplate.delete(lockKey);
        }
    }
}

生產(chǎn)環(huán)境可優(yōu)先考慮使用 Redisson 等成熟組件實現(xiàn)分布式鎖。

十二、登錄流程與 JWT 集成示例

短信登錄成功后，一般會簽發(fā)一個訪問令牌（如 JWT），后續(xù)接口基于令牌鑒權(quán)。

登錄接口偽代碼：

@PostMapping("/api/auth/loginBySms")
public Result<LoginResp> loginBySms(@Valid @RequestBody SmsLoginReq req, HttpServletRequest httpRequest) {
    String ip = IpUtils.getClientIp(httpRequest);
    String deviceId = req.getDeviceId();

    // 1. 黑名單 & 風控
    blacklistService.check(req.getPhone(), ip, deviceId);

    // 2. 驗證短信驗證碼
    smsCodeService.verifyCode(req.getPhone(), req.getCode());

    // 3. 獲取或創(chuàng)建用戶
    User user = userService.getOrCreateByPhone(req.getPhone());

    // 4. 生成 JWT
    String token = jwtUtil.generateToken(user.getId(), user.getRole());

    // 5. 記錄登錄日志
    loginLogService.recordLogin(user.getId(), ip, deviceId, "SMS");

    LoginResp resp = new LoginResp();
    resp.setToken(token);
    resp.setUserId(user.getId());
    return Result.success(resp);
}

JWT 本身也要注意：

使用足夠長度的對稱秘鑰或非對稱密鑰。
設(shè)置合理過期時間（如 2 小時），并結(jié)合刷新令牌機制。
優(yōu)先在服務(wù)端維護 Token 黑名單（踢下線時使用 Redis 存儲失效 token 的 jti）。

十三、前端配合的安全措施

13.1 請求頻率限制

點擊“獲取驗證碼”后，按鈕進入倒計時狀態(tài)（如 60 秒），期間禁止再次點擊。
對同一頁面或設(shè)備上的連續(xù)操作做防抖/節(jié)流處理（例如 1~2 秒內(nèi)禁止多次觸發(fā)）。

13.2 客戶端校驗

在前端進行手機號格式校驗（正則），避免無效請求直達服務(wù)端。
對登錄頁面進行基礎(chǔ)防刷：
- 使用圖形/滑塊驗證碼組件。
- 隨機化部分重要字段的名稱/順序增加腳本抓取難度（有限防護）。

13.3 安全傳輸與存儲

前端必須通過 HTTPS 發(fā)起請求。
不在瀏覽器本地持久化存儲驗證碼，不在控制臺或日志輸出驗證碼。
JWT 建議使用 Authorization: Bearer xxx 頭傳輸，避免放在 URL 參數(shù)。

13.4 用戶體驗與安全提示

對頻繁操作的用戶給出友好提示，不暴露系統(tǒng)內(nèi)部風控策略。
登錄成功后，對新設(shè)備/新地區(qū)登錄可提示用戶注意賬戶安全。

十四、小結(jié)

通過 Redis 限流 + 驗證碼安全存儲 + 圖形/滑塊驗證碼 + 黑名單 + 簽名與防重放 + 嚴格業(yè)務(wù)校驗 + 監(jiān)控告警 + 分布式鎖 等組合手段，可以大幅降低短信登錄接口被惡意盜刷和濫用的風險。

在 Spring Boot 項目中落地時，需要：

封裝統(tǒng)一的限流與風控組件，避免散落在各個 Controller 中。
統(tǒng)一錯誤碼與返回結(jié)構(gòu)，避免向攻擊者泄露過多信息。
定期復盤日志與監(jiān)控指標，持續(xù)優(yōu)化規(guī)則與閾值。

到此這篇關(guān)于SpringBoot短信登錄安全防護方案的文章就介紹到這了,更多相關(guān)SpringBoot短信登錄內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章:

SpringBoot基于Redis實現(xiàn)短信登錄的操作

最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线