Spring Security 6.3 OAuth2 设备码授权轮询端点 DDoS 防护:防抖与 PollingInterval 动态调整
大家好,今天我们来探讨 Spring Security 6.3 OAuth2 设备码授权流程中,轮询端点面临的 DDoS 攻击风险,以及如何通过防抖机制和动态调整 PollingInterval 来有效缓解这个问题。
1. 设备码授权流程简介
设备码授权(Device Authorization Grant)是 OAuth 2.0 的一种授权模式,专门为没有浏览器或输入设备(headless devices)的设备设计,比如智能电视、物联网设备等。流程大致如下:
- 设备请求授权: 设备向授权服务器请求设备码和用户码。
- 授权服务器响应: 授权服务器生成唯一的设备码(device_code)、用户码(user_code)、验证 URI(verification_uri)和过期时间。 设备码用于设备后续轮询,用户码和验证 URI 用于用户在其他设备(如手机或电脑)上完成授权。
- 用户授权: 用户在浏览器中访问验证 URI,输入用户码,并完成授权。
- 设备轮询: 设备使用设备码定期轮询授权服务器的 token 端点,检查用户是否已授权。
- 授权服务器响应: 如果用户已授权,授权服务器返回访问令牌和刷新令牌;否则,返回授权 pending 状态。
2. 轮询端点 DDoS 风险分析
设备码授权流程中的轮询端点是 DDoS 攻击的潜在目标。攻击者可以模拟大量设备,使用无效的设备码频繁轮询 token 端点,消耗服务器资源,导致正常设备无法获取令牌。
主要风险点:
- 资源消耗: 每次轮询请求都需要服务器进行设备码验证、授权状态检查等操作,大量无效请求会显著增加服务器 CPU、内存和网络带宽的消耗。
- 服务中断: 如果轮询请求数量过多,服务器可能不堪重负,导致服务中断,影响所有设备的用户体验。
- 安全风险: 持续的轮询请求可能暴露系统漏洞,增加安全风险。
3. 防抖 (Debounce) 机制
防抖是一种控制函数执行频率的技术。 在设备码授权轮询端点,我们可以利用防抖机制,限制单个设备在短时间内发送的轮询请求数量。
实现思路:
- 记录设备最后一次轮询时间: 每次收到轮询请求时,记录设备的设备码和当前时间戳。
- 检查时间间隔: 在处理新的轮询请求之前,检查当前时间和设备最后一次轮询时间的时间间隔。
- 延迟处理: 如果时间间隔小于预设的阈值(防抖时间),则延迟处理该请求或直接拒绝该请求。
代码示例 (Spring Boot 拦截器实现):
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.stereotype.Component;
import org.springframework.web.servlet.HandlerInterceptor;
import java.time.Instant;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
@Component
public class DeviceCodeDebounceInterceptor implements HandlerInterceptor {
private final Map<String, Instant> lastRequestTime = new ConcurrentHashMap<>();
private final long debounceTimeMillis = 1000; // 防抖时间:1 秒
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
String deviceCode = request.getParameter("device_code");
if (deviceCode == null || deviceCode.isEmpty()) {
return true; // 不是设备码授权请求,放行
}
Instant now = Instant.now();
Instant lastTime = lastRequestTime.get(deviceCode);
if (lastTime != null && now.toEpochMilli() - lastTime.toEpochMilli() < debounceTimeMillis) {
response.setStatus(429); // Too Many Requests
response.getWriter().write("Too many requests from this device. Please try again later.");
return false; // 拦截请求
}
lastRequestTime.put(deviceCode, now);
return true; // 放行请求
}
}
配置拦截器:
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
@Configuration
public class WebMvcConfig implements WebMvcConfigurer {
@Autowired
private DeviceCodeDebounceInterceptor deviceCodeDebounceInterceptor;
@Override
public void addInterceptors(InterceptorRegistry registry) {
registry.addInterceptor(deviceCodeDebounceInterceptor)
.addPathPatterns("/oauth2/token"); // 拦截 token 端点
}
}
说明:
DeviceCodeDebounceInterceptor是一个 Spring MVC 拦截器,用于拦截设备码授权的 token 端点。lastRequestTime是一个 ConcurrentHashMap,用于存储每个设备码最后一次请求的时间戳。debounceTimeMillis定义了防抖时间,单位是毫秒。preHandle方法在请求处理之前被调用。它检查当前请求是否在防抖时间内,如果是,则返回 false,拦截请求,并返回 429 状态码(Too Many Requests)。
优点:
- 简单易实现,对现有代码改动较小。
- 能够有效限制单个设备发送的请求数量。
缺点:
- 防抖时间需要根据实际情况进行调整,过短可能影响正常设备,过长可能无法有效防御 DDoS 攻击。
- 无法区分正常设备和恶意设备,可能会误伤正常设备。
4. 动态调整 PollingInterval
设备码授权流程中,授权服务器通常会建议设备设置一个合适的轮询间隔 (PollingInterval)。 如果设备严格遵守这个间隔,可以有效降低服务器压力。 但是,恶意设备可能会忽略这个建议,以最短的时间间隔进行轮询。 因此,我们需要一种机制来动态调整 PollingInterval,以应对不同的情况。
实现思路:
- 初始 PollingInterval: 设置一个合理的初始 PollingInterval,例如 5 秒。
- 监控轮询请求: 监控每个设备的轮询请求频率。
- 动态调整: 如果某个设备的轮询频率超过预设的阈值,则动态增加该设备的 PollingInterval。
- 持久化存储: 将动态调整后的 PollingInterval 存储起来,以便下次使用。
代码示例 (使用 Redis 存储 PollingInterval):
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import java.time.Instant;
import java.util.Optional;
import java.util.concurrent.TimeUnit;
@Service
public class DynamicPollingIntervalService {
@Autowired
private StringRedisTemplate redisTemplate;
private final long initialPollingIntervalSeconds = 5;
private final long maxPollingIntervalSeconds = 60;
private final double rateLimitThreshold = 2; // 每秒请求次数超过这个值,就增加 PollingInterval
private final String POLLING_INTERVAL_PREFIX = "polling_interval:";
private final String LAST_REQUEST_TIME_PREFIX = "last_request_time:";
public long getPollingInterval(String deviceCode) {
String key = POLLING_INTERVAL_PREFIX + deviceCode;
String pollingIntervalStr = redisTemplate.opsForValue().get(key);
if (pollingIntervalStr == null) {
return initialPollingIntervalSeconds;
}
return Long.parseLong(pollingIntervalStr);
}
public void updatePollingInterval(String deviceCode) {
String lastRequestTimeKey = LAST_REQUEST_TIME_PREFIX + deviceCode;
String pollingIntervalKey = POLLING_INTERVAL_PREFIX + deviceCode;
Instant now = Instant.now();
Instant lastRequestTime = Optional.ofNullable(redisTemplate.opsForValue().get(lastRequestTimeKey))
.map(Instant::parse)
.orElse(null);
redisTemplate.opsForValue().set(lastRequestTimeKey, now.toString(), 7, TimeUnit.DAYS); // 设置过期时间
if (lastRequestTime == null) {
return; // 第一次请求,无需调整
}
long timeDiffMillis = now.toEpochMilli() - lastRequestTime.toEpochMilli();
double requestsPerSecond = 1000.0 / timeDiffMillis;
if (requestsPerSecond > rateLimitThreshold) {
// 超过阈值,增加 PollingInterval
long currentPollingInterval = getPollingInterval(deviceCode);
long newPollingInterval = Math.min(currentPollingInterval * 2, maxPollingIntervalSeconds);
redisTemplate.opsForValue().set(pollingIntervalKey, String.valueOf(newPollingInterval), 7, TimeUnit.DAYS); // 设置过期时间
System.out.println("Device " + deviceCode + " polling interval increased to " + newPollingInterval + " seconds.");
}
}
}
代码示例 (在 Controller 中使用):
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class TokenController {
@Autowired
private DynamicPollingIntervalService pollingIntervalService;
@PostMapping("/oauth2/token")
public ResponseEntity<?> getToken(@RequestParam("grant_type") String grantType,
@RequestParam("device_code") String deviceCode) {
if (!"urn:ietf:params:oauth:grant-type:device_code".equals(grantType)) {
return ResponseEntity.badRequest().body("Invalid grant_type");
}
// 1. 获取动态 PollingInterval
long pollingInterval = pollingIntervalService.getPollingInterval(deviceCode);
// 2. 更新 PollingInterval (如果请求频率过高)
pollingIntervalService.updatePollingInterval(deviceCode);
// 3. 模拟授权状态检查
boolean isAuthorized = checkAuthorizationStatus(deviceCode); // 替换为实际的授权状态检查逻辑
if (isAuthorized) {
// 模拟返回 access token
return ResponseEntity.ok("{"access_token": "mock_access_token"}");
} else {
// 返回授权 pending 状态,并告知客户端最小轮询间隔
return ResponseEntity.status(HttpStatus.BAD_REQUEST)
.body("{"error": "authorization_pending", "interval": " + pollingInterval + "}");
}
}
private boolean checkAuthorizationStatus(String deviceCode) {
// 模拟授权状态检查,实际情况需要根据业务逻辑实现
// 这里简单模拟,每隔一段时间返回 true
return System.currentTimeMillis() % 20000 > 10000; // 模拟10秒授权pending, 10秒授权成功
}
}
说明:
DynamicPollingIntervalService负责动态调整 PollingInterval。getPollingInterval方法从 Redis 中获取指定设备码的 PollingInterval,如果不存在,则返回初始值。updatePollingInterval方法更新设备的 PollingInterval。 如果设备的轮询频率超过阈值,则将 PollingInterval 翻倍,但不能超过最大值。- 使用 Redis 存储 PollingInterval,可以支持分布式部署。
- 在 token 端点,首先获取设备的 PollingInterval,然后更新 PollingInterval。 最后,返回授权 pending 状态,并告知客户端最小轮询间隔。
- Controller中,
checkAuthorizationStatus方法仅仅是模拟,实际环境中需要连接数据库或者调用其他服务来验证该设备码是否已经被授权。
优点:
- 能够根据设备的轮询频率动态调整 PollingInterval,有效缓解 DDoS 攻击。
- 可以区分正常设备和恶意设备,只对恶意设备增加 PollingInterval。
缺点:
- 实现相对复杂,需要引入 Redis 等外部存储。
- 需要根据实际情况调整参数,例如初始 PollingInterval、最大 PollingInterval、速率限制阈值等。
- 需要考虑 Redis 的可用性和性能。
5. DeviceCodeStore 防抖
Spring Security 6.3 引入了 DeviceCodeStore 接口,用于存储设备码、用户码等信息。 我们可以自定义 DeviceCodeStore,并在其中实现防抖机制。
实现思路:
- 自定义 DeviceCodeStore: 创建一个自定义的
DeviceCodeStore,例如DebounceDeviceCodeStore。 - 记录请求时间: 在
DebounceDeviceCodeStore中,记录每个设备码最后一次请求的时间戳。 - 检查时间间隔: 在存储设备码之前,检查当前时间和设备最后一次请求时间的时间间隔。
- 延迟存储: 如果时间间隔小于预设的阈值(防抖时间),则抛出异常,拒绝存储设备码。
代码示例:
import org.springframework.security.oauth2.server.authorization.OAuth2AuthorizationCode;
import org.springframework.security.oauth2.server.authorization.OAuth2AuthorizationConsent;
import org.springframework.security.oauth2.server.authorization.client.RegisteredClient;
import org.springframework.security.oauth2.server.authorization.device.DeviceCode;
import org.springframework.security.oauth2.server.authorization.device.DeviceCodeStore;
import org.springframework.security.oauth2.server.authorization.device.OAuth2DeviceAuthorization;
import java.time.Instant;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
public class DebounceDeviceCodeStore implements DeviceCodeStore {
private final DeviceCodeStore delegate; // 委托给实际的 DeviceCodeStore,例如 InMemoryDeviceCodeStore
private final Map<String, Instant> lastRequestTime = new ConcurrentHashMap<>();
private final long debounceTimeMillis = 1000; // 防抖时间:1 秒
public DebounceDeviceCodeStore(DeviceCodeStore delegate) {
this.delegate = delegate;
}
@Override
public void save(OAuth2DeviceAuthorization deviceAuthorization) {
String deviceCodeValue = deviceAuthorization.getDeviceCode().getTokenValue();
Instant now = Instant.now();
Instant lastTime = lastRequestTime.get(deviceCodeValue);
if (lastTime != null && now.toEpochMilli() - lastTime.toEpochMilli() < debounceTimeMillis) {
throw new IllegalStateException("Too many requests from this device. Please try again later.");
}
lastRequestTime.put(deviceCodeValue, now);
delegate.save(deviceAuthorization);
}
@Override
public OAuth2DeviceAuthorization findByDeviceCodeValue(String deviceCodeValue) {
return delegate.findByDeviceCodeValue(deviceCodeValue);
}
@Override
public OAuth2DeviceAuthorization findByUserCodeValue(String userCodeValue) {
return delegate.findByUserCodeValue(userCodeValue);
}
@Override
public void remove(OAuth2DeviceAuthorization deviceAuthorization) {
delegate.remove(deviceAuthorization);
}
}
配置 DeviceCodeStore:
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.oauth2.server.authorization.device.DeviceCodeStore;
import org.springframework.security.oauth2.server.authorization.device.InMemoryDeviceCodeStore;
@Configuration
public class DeviceCodeConfig {
@Bean
public DeviceCodeStore deviceCodeStore() {
return new DebounceDeviceCodeStore(new InMemoryDeviceCodeStore()); // 使用 InMemoryDeviceCodeStore 作为委托
}
}
说明:
DebounceDeviceCodeStore实现了DeviceCodeStore接口,并委托给另一个DeviceCodeStore(例如InMemoryDeviceCodeStore)。- 在
save方法中,首先检查设备码的请求频率,如果超过阈值,则抛出异常。 - 通过配置,将
DebounceDeviceCodeStore注入到 Spring Security 中。
优点:
- 可以将防抖机制集成到
DeviceCodeStore中,与 Spring Security 集成更加紧密。 - 代码结构清晰,易于维护。
缺点:
- 需要自定义
DeviceCodeStore,对现有代码有一定的改动。 - 只能在设备码存储之前进行防抖,无法限制已经存储的设备码的轮询频率。
6. 其他防御手段
除了防抖和动态调整 PollingInterval 之外,还可以采用以下措施来增强 DDoS 防护:
- 限制 IP 地址: 使用防火墙或 Web 应用防火墙 (WAF) 限制来自恶意 IP 地址的请求。
- 验证码: 在用户授权页面添加验证码,防止机器人恶意授权。
- 请求速率限制: 使用 Spring Cloud Gateway 或其他 API 网关,对所有请求进行速率限制。
- 监控和告警: 监控服务器资源使用情况,并设置告警规则,及时发现和处理 DDoS 攻击。
- CDN 加速: 使用 CDN (Content Delivery Network) 缓存静态资源,减轻服务器压力。
7. 不同策略的比较
| 特性 | 防抖 (Interceptor) | 动态调整 PollingInterval | DeviceCodeStore 防抖 |
|---|---|---|---|
| 实现复杂度 | 低 | 中 | 中 |
| 资源消耗 | 低 | 中 | 低 |
| 精确度 | 低 | 中 | 低 |
| 适用场景 | 简单场景,快速部署 | 需要精细化控制的场景 | 集成到 Spring Security 的场景 |
| 与 Spring Security 集成度 | 低 | 低 | 高 |
8. 如何选择合适的策略
选择哪种策略取决于具体的应用场景和需求。
- 如果需要快速部署,且对精度要求不高,可以使用防抖 (Interceptor)。
- 如果需要精细化控制,并能够区分正常设备和恶意设备,可以使用动态调整 PollingInterval。
- 如果希望将防抖机制集成到 Spring Security 中,可以使用 DeviceCodeStore 防抖。
在实际应用中,可以将多种策略结合使用,以达到最佳的防护效果。 例如,可以同时使用防抖 (Interceptor) 和动态调整 PollingInterval。
9. 总结一下
设备码授权的轮询端点容易受到DDoS攻击,针对这个问题,我们讨论了防抖和动态调整PollingInterval这两种有效的防御手段,以及如何使用DeviceCodeStore进行防抖。我们还比较了这些策略的优缺点,希望能帮助你根据实际场景选择合适的策略。