Security安全認(rèn)證 - Spring Boot

Security安全認(rèn)證 - Spring Boot如何集成Security實現(xiàn)安全認(rèn)證

面介紹了Spring Boot 使用JWT實現(xiàn)Token驗證，其實Spring Boot 有完整的安全認(rèn)證框架：Spring Security。接下來我們介紹如何集成Security 實現(xiàn)安全驗證。

一、Security簡介

安全對于企業(yè)來說至關(guān)重要，必要的安全認(rèn)證為企業(yè)阻擋了外部非正常的訪問，保證了企業(yè)內(nèi)部數(shù)據(jù)的安全。

當(dāng)前，數(shù)據(jù)安全問題越來越受到行業(yè)內(nèi)公司的重視。數(shù)據(jù)泄漏很大一部分原因是非正常權(quán)限訪問導(dǎo)致的，于是使用合適的安全框架保護企業(yè)服務(wù)的安全變得非常緊迫。在Java領(lǐng)域，Spring Security無疑是最佳選擇之一。

Spring Security 是 Spring 家族中的一個安全管理框架，能夠基于 Spring 的企業(yè)應(yīng)用系統(tǒng)提供聲明式的安全訪問控制解決方案。它提供了一組可以在Spring應(yīng)用系統(tǒng)中靈活配置的組件，充分利用了 Spring的IoC、DI和AOP等特性，為應(yīng)用系統(tǒng)提供聲明式的安全訪問控制功能，減少了為企業(yè)系統(tǒng)安全控制編寫大量重復(fù)代碼的工作。

二、Spring Boot對Security的支持

雖然，在Spring Boot出現(xiàn)之前，Spring Security已經(jīng)發(fā)展多年，但是使用并不廣泛。安全管理這個領(lǐng)域一直是Shiro的天下，因為相對于Shiro，在項目中集成Spring Security還是一件麻煩的事情，所以Spring Security雖然比Shiro強大，但是卻沒有Shiro受歡迎。

隨著Spring Boot的出現(xiàn)，Spring Boot 對Spring Security 提供了自動化配置方案，可以零配置使用 Spring Security。這使得Spring Security重新煥發(fā)新的活力。

Spring Boot 提供了集成 Spring Security 的組件包 spring-boot-starter-security，方便我們在 Spring Boot 項目中使用 Spring Security進行權(quán)限控制。

三、集成Security

在Spring Boot 項目中集成Spring Boot Security 非常簡單，只需在項目中增加Spring Boot Security的依賴即可。下面通過示例演示Spring Boot中基礎(chǔ)Security的登錄驗證。

1. 添加依賴

Spring Boot 提供了集成 Spring Security 的組件包 spring-boot-starter-security，方便我們在 Spring Boot 項目中使用 Spring Security。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-thymeleaf</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

上面除了引入Security組件外，因為我們要做Web系統(tǒng)的權(quán)限驗證，所以還添加了Web和Thymeleaf組件。

2. 配置登錄用戶名和密碼

用戶名和密碼在application.properties中進行配置。

# security
spring.security.user.name=admin
spring.security.user.password=admin

在application.properties配置文件中增加了管理員的用戶名和密碼。

3. 添加Controller

創(chuàng)建SecurityController 類，在類中添加訪問頁面的入口。

@Controller
public class SecurityController {
    @RequestMapping("/")
    public String index() {
        return "index";
    }
}

4. 創(chuàng)建前端頁面

在resources/templates 目錄下創(chuàng)建頁面 index.html，這個頁面就是具體的需要增加權(quán)限控制的頁面，只有登錄了才能進入此頁。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:th="http://www.thymeleaf.org">
<body>
<h1>Hello</h1>
<p>我是登錄后才可以看的頁面</p>
</body>
</html>

5. 測試驗證

配置完成后，重啟項目，訪問地址：http://localhost:8080/，頁面會自動彈出一個登錄框，如下圖所示。

系統(tǒng)自動跳轉(zhuǎn)到Spring Security默認(rèn)的登錄頁面，輸入之前配置的用戶名和密碼就可以登錄系統(tǒng)，登錄后的頁面如下圖所示。

通過上面的示例，我們看到Spring Security自動給所有訪問請求做了登錄保護，實現(xiàn)了頁面權(quán)限控制。

四、登錄驗證

前面演示了在Spring Boot項目中集成Spring Security 實現(xiàn)簡單的登錄驗證功能，在實際項目使用過程中，可能有的功能頁面不需要進行登錄驗證，而有的功能頁面只有進行登錄驗證才能訪問。下面通過完整的示例程序演示如何實現(xiàn)Security的登錄認(rèn)證。

1. 創(chuàng)建頁面content.html

先創(chuàng)建頁面content.html，此頁面只有登錄用戶才可查看，否則會跳轉(zhuǎn)到登錄頁面，登錄成功后才能訪問。示例代碼如下：

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:th="http://www.thymeleaf.org">
<body>
<h1>content</h1>
<p>我是登錄后才可以看的頁面</p>
<form method="post" action="/logout">
    <button type="submit">退出</button>
</form>
</body>
</html>

在上面的示例中，我們看到退出使用post請求，因為Security退出請求默認(rèn)只支持post 。

2. 修改index.html 頁面

修改之前的index.html頁面，增加登錄按鈕。

<p>點擊 <a th:href="@{/content}">這里</a>進入管理頁面</p>

在上面的示例中，index頁面屬于公共頁面，無權(quán)限驗證，從index頁面進入content頁面時需要登錄驗證。

3. 修改Controller控制器

修改之前的SecurityController控制器，增加content頁面路由地址，示例代碼如下：

@RequestMapping("/")
public String index() {
    return "index";
}
 
@RequestMapping("/content")
public String content() {
    return "content";
}

4. 創(chuàng)建 SecurityConfig 類

創(chuàng)建 Security的配置文件SecurityConfig類，它繼承于 WebSecurityConfigurerAdapter，現(xiàn)自定義權(quán)限驗證配置。示例代碼如下：

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/", "/home").permitAll()
            .anyRequest().authenticated()
            .and()
            .formLogin()
            .permitAll()
            .and()
            .logout()
            .permitAll()
            .and()
            .csrf()
            .ignoringAntMatchers("/logout");
    }
}

在上面的示例程序中，SecurityConfig類中配置 index.html 可以直接訪問，但 content.html 需要登錄后才可以查看，沒有登錄的自動跳轉(zhuǎn)到登錄頁面。

@EnableWebSecurity：開啟 Spring Security 權(quán)限控制和認(rèn)證功能。
antMatchers("/", "/home").permitAll()：配置不用登錄可以訪問的請求。
anyRequest().authenticated()：表示其他的請求都必須有權(quán)限認(rèn)證。
formLogin()：定制登錄信息。
loginPage("/login")：自定義登錄地址，若注釋掉，則使用默認(rèn)登錄頁面。
logout()：退出功能，Spring Security自動監(jiān)控了/logout。
ignoringAntMatchers("/logout")：Spring Security 默認(rèn)啟用了同源請求控制，在這里選擇忽略退出請求的同源限制。

5. 測試驗證

修改完成之后重啟項目，訪問地址http://localhost:8080/可以看到 index 頁面的內(nèi)容，單擊鏈接跳轉(zhuǎn)到content頁面時會自動跳轉(zhuǎn)到登錄頁面，登錄成功后才會自動跳轉(zhuǎn)到http://localhost:8080/content，在 content 頁面單擊“退出”按鈕，會退出登錄狀態(tài)，跳轉(zhuǎn)到登錄頁面并提示已經(jīng)退出。

登錄、退出、請求受限頁面退出后跳轉(zhuǎn)到登錄頁面是常用的安全控制案例，也是賬戶系統(tǒng)基本的安全保障。

最后

以上，我們就把Spring Boot如何集成Security實現(xiàn)安全認(rèn)證介紹完了。

電商行業(yè)，線上的營銷活動特別多。在移動互聯(lián)網(wǎng)時代，一般為了活動的快速上線和內(nèi)容的即時更新，大部分的業(yè)務(wù)場景仍然通過 Web 頁面來承載。但由于 Web 頁面天生“環(huán)境透明”，相較于移動客戶端頁面在安全性上存在更大的挑戰(zhàn)。本文主要以移動端 Web 頁面為基礎(chǔ)來講述如何提升頁面安全性。

活動 Web 頁面的安全挑戰(zhàn)

對于營銷活動類的 Web 頁面，領(lǐng)券、領(lǐng)紅包、抽獎等活動方式很常見。此類活動對于普通用戶來說大多數(shù)時候就是“拼手氣”，而對于非正常用戶來說，可以通過直接刷活動 API 接口的“作弊”方式來提升“手氣”。這樣的話，對普通用戶來說，就變得很不公平。

對于活動運營的主辦方來說，如果風(fēng)控措施做的不好，這類刷接口的“拼手氣”方式可能會對企業(yè)造成較大的損失。如本來計劃按 7 天發(fā)放的紅包，在上線 1 天就被刷光了，活動的營銷成本就會被意外提升。主辦方想發(fā)放給用戶的滿減券、紅包，卻大部分被黃牛使用自動腳本刷走，而真正想?yún)⑴c活動的用戶，卻無法享受活動優(yōu)惠。

終端用戶到底是人還是機器，網(wǎng)絡(luò)請求是否為真實用戶發(fā)起，是否存在安全漏洞并且已被“羊毛黨”惡意利用等等，這些都是運營主辦方要擔(dān)心的問題。

安全防范的基本流程

為了提升活動 Web 頁面的安全性，通常會引入專業(yè)的風(fēng)控服務(wù)。引入風(fēng)控服務(wù)后，安全防護的流程大致如圖所示。

Web 前端：用戶通過 Web 頁面來參與活動，同時 Web 前端也會收集用于人機識別驗證的用戶交互行為數(shù)據(jù)。由于不同終端（移動端 H5 頁面和 PC 端頁面）交互形式不同，收集用戶交互行為數(shù)據(jù)的側(cè)重點也會有所不同。
風(fēng)控服務(wù)：一般大公司都會有專業(yè)的風(fēng)控團隊來提供風(fēng)控服務(wù)，在美團內(nèi)部有智能反爬系統(tǒng)來基于地理位置、IP地址等大數(shù)據(jù)來提供頻次限制、黑白名單限制等常規(guī)的基礎(chǔ)風(fēng)控攔截服務(wù)。甚至還有依托于海量的全業(yè)務(wù)場景的大數(shù)據(jù)，使用貝葉斯模型、神經(jīng)網(wǎng)絡(luò)等來構(gòu)建專業(yè)度較深的服務(wù)。風(fēng)控服務(wù)可以為 Web 前端提供通用的獨立驗證 SDK：驗證碼、滑塊驗證等區(qū)分人機的“圖靈驗證”，也可以為服務(wù)端提供 Web API 接口的驗證等。
后端業(yè)務(wù)服務(wù)：負責(zé)處理活動業(yè)務(wù)邏輯，如給用戶發(fā)券、發(fā)紅包，處理用戶抽獎等。請求需要經(jīng)過風(fēng)控服務(wù)的驗證，確保其安全性，然后再來處理實際業(yè)務(wù)邏輯，通常，在處理完實際業(yè)務(wù)邏輯時，還會有針對業(yè)務(wù)本身的風(fēng)控防范。

對于活動 Web 頁面來說，加入的風(fēng)控服務(wù)主要為了做人機識別驗證。在人機識別驗證的專業(yè)領(lǐng)域上，我們可以先看看業(yè)界實踐，比如Google 是怎么做的。

業(yè)界人機驗證實踐

Google 使用的人機驗證服務(wù)是著名的 reCAPTCHA（Completely Automated Public Turing Test To Tell Computers and Humans Apart，區(qū)分人機的全自動圖靈測試系統(tǒng)），也是應(yīng)用最廣的驗證碼系統(tǒng)。早年的 reCAPTCHA 驗證碼是這樣的：

如今的 reCAPTCHA 已經(jīng)不再需要人工輸入難以識別的字符，它會檢測用戶的終端環(huán)境，追蹤用戶的鼠標(biāo)軌跡，只需用戶點擊“我不是機器人”就能進行人機驗證（reCAPTCHA騙用戶進行數(shù)據(jù)標(biāo)注而進行AI訓(xùn)練的驗證另說）。

reCAPTCHA 的驗證方式從早先的輸入字符到現(xiàn)在的輕點按鈕，在用戶體驗上，有了較大的提升。

而在活動場景中引入人機識別驗證，如果只是簡單粗暴地增加驗證碼，或者只是像 reCAPTCHA 那樣增加點擊“我不是機器人”的驗證，都會犧牲用戶體驗，降低用戶參加活動的積極性。

Google 的普通 Web 頁面的瀏覽和有強交互的活動 Web 頁面雖是不同的業(yè)務(wù)場景，但對于活動 Web 頁面來說，強交互恰好為人機識別驗證提供了用戶交互行為數(shù)據(jù)收集的契機。

人機識別驗證的技術(shù)挑戰(zhàn)

理想的方案是在用戶無感知的情況下做人機識別驗證，這樣既確保了安全又對用戶體驗無損傷。

從實際的業(yè)務(wù)場景出發(fā)再結(jié)合 Web 本身的環(huán)境，如果想實現(xiàn)理想的方案，可能會面臨如下的技術(shù)挑戰(zhàn)：

（1）需要根據(jù)用戶的使用場景來定制人機識別驗證的算法：Web 前端負責(zé)收集、上報用戶交互行為數(shù)據(jù)，風(fēng)控服務(wù)端校驗上報的數(shù)據(jù)是否符合正常的用戶行為邏輯。

（2）確保 Web 前端和風(fēng)控服務(wù)端之間通信和數(shù)據(jù)傳輸?shù)陌踩浴?/p>

（3）確保上述兩大挑戰(zhàn)中提到的邏輯和算法不會被代碼反編譯來破解。

在上述的三個挑戰(zhàn)中，（1）已經(jīng)實現(xiàn)了人機識別驗證的功能，而（2）和（3）都是為了確保人機識別驗證不被破解而做的安全防范。接下來，本文會分別針對這三個技術(shù)挑戰(zhàn)來說明如何設(shè)計技術(shù)方案。

挑戰(zhàn)一：根據(jù)用戶使用場景來定制人機識別驗證算法

先來分析一下用戶的使用場景，正常用戶參與活動的步驟是用戶進入活動頁面后，會有短暫的停留，然后點擊按鈕參與活動。這里所說的“參與活動”，最終都會在活動頁面發(fā)起一個接口的請求。如果是非正常用戶，可以直接跳過以上的實際動作而去直接請求參與活動的接口。

那么區(qū)別于正常用戶和非正常用戶就是那些被跳過的動作，對實際動作進一步歸納如下：

（1）進入頁面。

（2）短暫的停留。

（3）滾動頁面。

（4）點擊按鈕。

以上的動作又可以分為必需的操作和可選的操作。對這一連串動作產(chǎn)生的日志數(shù)據(jù)進行收集，在請求參與活動的接口時，將這些數(shù)據(jù)提交至后端，驗證其合法性。這就是一個簡單的人機識別驗證。

在驗證動作的合法性時，需要考慮到這些動作數(shù)據(jù)是不是能被輕易模擬。另外，動作的發(fā)生應(yīng)該有一條時間線，可以給每個動作都增加一個時間戳，比如點擊按鈕肯定是在進入頁面之后發(fā)生的。

一些特定的動作的日志數(shù)據(jù)也會有合理的區(qū)間，進入頁面的動作如果以 JS 資源加載的時間為基準(zhǔn)，那么加載時間可能大于 100 毫秒，小于 5 秒。而對于移動端的按鈕點擊，點擊時記錄的坐標(biāo)值也會有對應(yīng)的合理區(qū)間，這些合理的區(qū)間會根據(jù)實際的環(huán)境和情況來進行設(shè)置。

除此之外，設(shè)備環(huán)境的數(shù)據(jù)也可以進行收集，包括用戶參與活動時使用的終端類型、瀏覽器的類型、瀏覽器是否為客戶端的容器等，如果使用了客戶端，客戶端是否會攜帶特殊的標(biāo)識等。

最后，還可以收集一些“無效”的數(shù)據(jù)，這些數(shù)據(jù)用于障人耳目，驗證算法會將其忽略。盡管收集數(shù)據(jù)的動作是透明的，但是驗證數(shù)據(jù)合法性不是透明的，攻擊者無法知道，驗證的算法中怎么區(qū)分哪些是有效、哪些是無效。這已經(jīng)有點“蜜罐數(shù)據(jù)”的意思了。

挑戰(zhàn)二：確保通信的安全性

收集的敏感數(shù)據(jù)要發(fā)送給風(fēng)控服務(wù)端，進而確保通信過程的安全。

Web API 接口不能被中途攔截和篡改，通信協(xié)議使用 HTTPS 是最基本的要求；同時還要讓服務(wù)端生成唯一的 Token，在通信過程中都要攜帶該 Token。
接口攜帶的敏感數(shù)據(jù)不能是明文的，敏感數(shù)據(jù)要進行加密，這樣攻擊者無法通過網(wǎng)絡(luò)抓包來詳細了解敏感數(shù)據(jù)的內(nèi)容。

Token 的設(shè)計

Token 是一個簡短的字符串，主要為了確保通信的安全。用戶進入活動 Web 頁面后，請求參與活動的接口之前，會從服務(wù)端獲取 Token。該 Token 的生成算法要確保 Token 的唯一性，通過接口或 Cookie 傳遞給前端，然后，前端在真正請求參與活動的接口時需要帶上該 Token，風(fēng)控服務(wù)端需要驗證 Token 的合法性。也就是說，Token 由服務(wù)端生成，傳給前端，前端再原封不動的回傳給服務(wù)端。一旦加入了 Token 的步驟，攻擊者就不能直接去請求參與活動的接口了。

Token 由風(fēng)控服務(wù)端基于用戶的身份，根據(jù)一定的算法來生成，無法偽造，為了提升安全等級，Token 需要具有時效性，比如 10 分鐘?？梢允褂?Redis 這類緩存服務(wù)來存儲 Token，使用用戶身份標(biāo)識和 Token 建立 KV 映射表，并設(shè)置過期時間為 10 分鐘。

雖然前端在 Cookie 中可以獲取到 Token，但是前端不能對 Token 做持久化的緩存。一旦在 Cookie 中獲取到了 Token，那么前端可以立即從 Cookie 中刪除該 Token，這樣能盡量確保 Token 的安全性和時效性。Token 存儲在 Redis 中，也不會因為用戶在參與活動時頻繁的切換頁面請求，而對服務(wù)造成太大的壓力。

另外，Token 還可以有更多的用處：

標(biāo)識參與活動用戶的有效性。
敏感數(shù)據(jù)對稱加密時生成動態(tài)密鑰。
API 接口的數(shù)字簽名。

敏感數(shù)據(jù)加密

通信時，傳遞的敏感數(shù)據(jù)可以使用常見的對稱加密算法進行加密。

為了提升加密的安全等級，加密時的密鑰可以動態(tài)生成，前端和風(fēng)控服務(wù)端約定好動態(tài)密鑰的生成規(guī)則即可。加密的算法和密鑰也要確保不被暴露。

通過對敏感數(shù)據(jù)加密，攻擊者在不了解敏感數(shù)據(jù)內(nèi)容的前提下就更別提模擬構(gòu)造請求內(nèi)容了。

挑戰(zhàn)三：化解紙老虎的尷尬

有經(jīng)驗的 Web 開發(fā)者看到這里，可能已經(jīng)開始質(zhì)疑了：在透明的前端環(huán)境中折騰安全不是白折騰嗎？這就好比費了很大的勁卻只是造了一個“紙老虎”，質(zhì)疑是有道理的，但是且慢，通過一些安全機制的加強是可以讓“紙老虎”盡可能的逼真。

本文一再提及的 Web 環(huán)境的透明性，是因為在實際的生產(chǎn)環(huán)境中的問題：前端的代碼在壓縮后，通過使用瀏覽器自帶的格式化工具和斷點工具，仍然具備一定的可讀性，花點時間仍然可以理解代碼的邏輯，這就給攻擊者提供了大好的代碼反編譯機會。

如果要化解“紙老虎”的尷尬，就要對前端的代碼進行混淆。

前端代碼混淆

前端的 JS 代碼壓縮工具基本都是對變量、函數(shù)名稱等進行縮短，壓縮對于混淆的作用是比較弱。除了對代碼進行壓縮，還需要進行專門的混淆。

對代碼進行混淆可以降低可讀性，混淆工具有條件的話最好自研，開源的工具要慎用。或者基于 Uglify.js 來自定義混淆的規(guī)則，混淆程度越高可讀性就越低。

代碼混淆也需要把握一個度，太復(fù)雜的混淆可能會讓代碼無法運行，也有可能會影響本身的執(zhí)行效率。同時還需要兼顧混淆后的代碼體積，混淆前后的體積不能有太大的差距，合理的混淆程度很重要。

斷點工具的防范會更麻煩些。在使用斷點工具時通常都會導(dǎo)致代碼延遲執(zhí)行，而正常的業(yè)務(wù)邏輯都會立即執(zhí)行，這是一個可以利用的點，可以考慮在代碼執(zhí)行間隔上來防范斷點工具。

通過代碼混淆和對代碼進行特殊的處理，可以讓格式化工具和斷點工具變得沒有用武之地。唯一有些小遺憾，就是處理后的代碼也不能正常使用 Source Map 的功能了。

有了代碼混淆，反編譯的成本會非常高，這樣“紙老虎”已經(jīng)變得很逼真了。

技術(shù)方案設(shè)計

在講解完如何解決關(guān)鍵的技術(shù)挑戰(zhàn)后，就可以把相應(yīng)的方案串起來，然后設(shè)計成一套可以實施的技術(shù)方案了。相對理想的技術(shù)方案架構(gòu)圖如下：

下面會按步驟來講解技術(shù)方案的處理流程：

Step 0 基礎(chǔ)風(fēng)控攔截

基礎(chǔ)風(fēng)控攔截是上面提到的頻次、名單等的攔截限制，在 Nginx 層就能直接實施攔截。如果發(fā)現(xiàn)是惡意請求，直接將請求過濾返回 403，這是初步的攔截，用戶在請求 Web 頁面的時候就開始起作用了。

Step 1 風(fēng)控服務(wù)端生成 Token 后傳給前端

Step 0 可能還沒進入到活動 Web 頁面，進入活動 Web 頁面后才真正開始人機識別驗證的流程，前端會先開始獲取 Token。

Step 2 前端生成敏感數(shù)據(jù)

敏感數(shù)據(jù)應(yīng)包含用戶交互行為數(shù)據(jù)、設(shè)備環(huán)境數(shù)據(jù)、活動業(yè)務(wù)邏輯數(shù)據(jù)以及無效數(shù)據(jù)。

Step 3 使用 HTTPS 的簽名接口發(fā)送數(shù)據(jù)

Token 可以作為 Authorization 的值添加到 Header 中，數(shù)據(jù)接口的簽名可以有效防止 CSRF 的攻擊。

Step 4 數(shù)據(jù)接口的校驗

風(fēng)控服務(wù)端收到請求后，會先驗證數(shù)據(jù)接口簽名中的 Token 是否有效。驗證完 Token，才會對敏感數(shù)據(jù)進行解密。數(shù)據(jù)解密成功，再進一步對人機識別的數(shù)據(jù)合法性進行校驗。

Step 5 業(yè)務(wù)邏輯的處理

前面的步驟為了做人機識別驗證，這些驗證不涉及到業(yè)務(wù)邏輯。在所有這些驗證都通過后，后端業(yè)務(wù)服務(wù)才會開始處理實際的活動業(yè)務(wù)邏輯。處理完活動業(yè)務(wù)邏輯，最終才會返回用戶參與活動的結(jié)果。

總結(jié)

為了提升活動 Web 頁面的安全性，使用了各種各樣的技術(shù)方案，我們將這些技術(shù)方案組合起來才能發(fā)揮安全防范的作用，如果其中某個環(huán)節(jié)處理不當(dāng)，都可能會被當(dāng)作漏洞來利用，從而導(dǎo)致整個驗證方案被攻破。

為了驗證技術(shù)方案的有效性，可以持續(xù)觀察活動 API 接口的請求成功率。從請求成功率的數(shù)據(jù)中進一步分析“誤傷”和“攔截”的數(shù)據(jù)，以進一步確定是否要對方案進行調(diào)優(yōu)。

通過上述的人機識別驗證的組合方案，可以大幅提升活動 Web 頁面的安全性。在活動 Web 頁面應(yīng)作為一個標(biāo)準(zhǔn)化的安全防范流程，除了美團，像淘寶和天貓也有類似的流程。由于活動運營的環(huán)節(jié)和方法多且復(fù)雜，僅僅提升了 Web 頁面也不敢保證就是鐵板一塊，安全需要關(guān)注的環(huán)節(jié)還很多，安全攻防是一項長期的“拉鋸升級戰(zhàn)”，安全防范措施也需要持續(xù)地優(yōu)化升級。

參考資料

https://www.google.com/recaptcha/intro/v3.html
https://segmentfault.com/a/1190000006226236
https://www.freebuf.com/articles/web/102269.html

作者簡介

益國，美團點評 Web 前端開發(fā)工程師。2015年加入美團，曾先后負責(zé)過風(fēng)控前端SDK和活動運營平臺的研發(fā)，現(xiàn)負責(zé)大數(shù)據(jù)平臺的研發(fā)工作。

閱讀更多技術(shù)干貨，歡迎關(guān)注美團技術(shù)團隊微信公眾號

歡迎加入美團Web前端技術(shù)交流群，跟作者零距離交流。進群方式：請加美美同學(xué)微信（微信號：MTDPtech02），回復(fù)：人機識別，美美會自動拉你進群。

個和 JWT 沒有什么關(guān)系，「JWT（Json Web Token）」是 token 的其中一種實現(xiàn)方式，是用來雙方信任的情況下作為身份令牌的。它只能保證信息沒有被篡改，無法保證信息是否被偽造、盜用。

【jwt 被盜用冒充】和【別人知道你的賬戶名和密碼】是沒有什么區(qū)別的，服務(wù)端又無法確定用這個賬號的是不是你。

如果是在網(wǎng)頁傳輸中，現(xiàn)在有 HTTPS 情況下，像是中間人攻擊這種通過抓包獲取信息比較困難。就竊取 jwt 來說，如果是在系統(tǒng)儲存中，那就是操作系統(tǒng)和應(yīng)用程序的權(quán)限和安全防護問題；如果是對服務(wù)器的攻擊，那就是屬于服務(wù)器的漏洞了，算是另一個層面了。

所以，如果要安全，可以參考一下大家主流的登錄系統(tǒng)方案，添加雙重認(rèn)證，比如手機驗證碼、手機令牌、郵箱驗證碼等等。

例如使用 Authing 提升登錄過程中的安全性和便捷性。

關(guān)于安全問題，Authing 通過 可視化安全審計、多因素登錄、密碼管理、加密傳輸與存儲 等方式進行保障。它可以實現(xiàn) 賬號密碼/手機驗證碼/APP 掃碼/小程序掃碼/企業(yè)身份源/社會化登錄、內(nèi)置了忘記密碼的交互 UI、多因素認(rèn)證（MFA）功能。

而在前端的 Guard 組件能幫助你快速構(gòu)建登錄界面，還支持遠程控制具體配置，覆蓋前端主流框架。用戶無需編寫任何額外代碼，即可使用該組件完成任務(wù)。不僅完美兼容移動端和 PC 端，還可以用 CSS 輕松自定義登錄框樣式。

也就是說，僅需幾步就能快速接入 SDK，在前端自定義用戶登錄操作，在后端管理用戶、組織、權(quán)限，一網(wǎng)打盡。

點擊「鏈接」，立刻了解 Authing！

在線咨詢

上一篇：一個簡單的 HTML 網(wǎng)頁設(shè)計代碼
下一篇：FFmpeg功能命令匯總

您的項目需求

*請認(rèn)真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。

整合營銷服務(wù)商