건축적 우선순위로서의 안전
다음과 같은 이벤트 관리 플랫폼에서 이벤트를 플레이하세요, 안전은 부차적인 측면이 아니라 근본적인 요구 사항입니다. 사용자 개인 데이터, 결제 정보, 문서 및 개인 통신을 공유합니다. 이 데이터를 보호하려면 인증, 인증, 승인, 전송 중인 데이터와 저장 중인 데이터의 보호, 주요 데이터에 대한 방어 웹 공격의 범주.
이 기사에서 찾을 수 있는 내용
- HttpOnly 쿠키를 사용한 JWT 인증 아키텍처
- 무상태 세션 관리
- 순환을 통한 토큰 새로 고침 메커니즘
- 이메일 확인 워크플로
- RBAC(역할 기반 액세스 제어) 시스템
- OWASP 보안 헤더 및 보호
- 속도 제한 및 입력 검증
HttpOnly 쿠키를 사용한 JWT
인증 설계에서 가장 중요한 선택은 localStorage에 JWT 토큰을 저장하지 마세요. 그게 연습인데도 SPA(단일 페이지 애플리케이션)에서 더 널리 퍼져 있으며 localStorage는 취약합니다. XSS 공격: 페이지 컨텍스트에서 실행되는 모든 JavaScript 스크립트 토큰을 읽고 악의적인 서버로 보낼 수 있습니다.
이벤트를 플레이하세요 대신 사용 HttpOnly 쿠키, JavaScript e에서는 액세스할 수 없습니다. 이는 각 HTTP 요청과 함께 브라우저에 의해 올바른 도메인으로 자동 전송됩니다.
// Creazione del cookie HttpOnly con il token JWT
ResponseCookie accessCookie = ResponseCookie.from("access_token", accessToken)
.httpOnly(true) // Non accessibile da JavaScript
.secure(true) // Solo HTTPS
.sameSite("Strict") // Protezione CSRF
.path("/") // Valido per tutto il dominio
.maxAge(Duration.ofMinutes(15)) // Scadenza breve
.build();
ResponseCookie refreshCookie = ResponseCookie.from("refresh_token", refreshToken)
.httpOnly(true)
.secure(true)
.sameSite("Strict")
.path("/api/v1/auth/refresh") // Solo per il refresh endpoint
.maxAge(Duration.ofDays(7)) // Scadenza lunga
.build();보안: localStorage 대 HttpOnly 쿠키
JWT 토큰을 다음 위치에 저장합니다. localStorage 모든 취약점에 노출됩니다.
애플리케이션 또는 타사 라이브러리에 XSS가 있습니다. 단일 악성 스크립트
토큰을 훔쳐서 사용자를 사칭할 수 있습니다. HttpOnly 쿠키가 완전히 제거됩니다.
이 공격 벡터는 브라우저가 토큰을 외부에 노출하지 않고 처리하기 때문입니다.
자바스크립트 코드.
무상태 세션 관리
인증 아키텍처는 완전히 무국적: 서버 메모리에 세션을 유지하지 않습니다. 각 HTTP 요청에는 모든 정보가 포함되어 있습니다. JWT 토큰으로 인코딩되어 사용자를 인증하고 권한을 부여하는 데 필요합니다.
이 접근 방식은 확장성에 상당한 이점이 있습니다. 세션 복제 없이 여러 서버 인스턴스에 로드를 분산합니다. 또는 끈적한 세션. 각 인스턴스는 다음을 확인하여 JWT 토큰을 독립적으로 검증할 수 있습니다. 디지털 서명.
// Esempio di payload JWT (i dati sensibili NON sono inclusi)
{
"sub": "user-uuid-here",
"email": "utente@example.com",
"roles": ["USER", "ORGANIZER"],
"iat": 1709294400,
"exp": 1709295300,
"jti": "unique-token-id"
}순환을 통한 토큰 새로 고침
시스템은 다음과 같은 메커니즘을 구현합니다. 새로 고침 토큰 교체 방지하는 토큰 재사용 공격. 새로고침 토큰을 사용하여 가져오는 경우 새 액세스 토큰을 생성하면 이전 새로 고침 토큰이 무효화되고 새 토큰이 발급됩니다.
FLUSSO REFRESH TOKEN
1. Client invia richiesta con access_token scaduto
→ Server risponde 401 Unauthorized
2. Client chiama POST /api/v1/auth/refresh
→ Il refresh_token viene inviato automaticamente via cookie
3. Server verifica il refresh_token:
a. Token valido e non nella blacklist?
b. Token non ancora utilizzato per un refresh?
c. Utente ancora attivo nel sistema?
4. Se tutto è valido:
→ Genera nuovo access_token (15 min)
→ Genera nuovo refresh_token (7 giorni)
→ Invalida il vecchio refresh_token (blacklist)
→ Imposta nuovi cookie HttpOnly
5. Se il refresh_token è già stato utilizzato:
→ ALERT: possibile furto token
→ Invalida TUTTI i refresh token dell'utente
→ L'utente deve riautenticarsi순환을 사용하면 각 새로 고침 토큰을 한 번만 사용할 수 있습니다. 만약 공격자가 새로 고침 토큰을 훔쳐 이를 사용하면 정당한 소유자는 다음을 받게 됩니다. 다음 새로 고침 시 오류가 발생하여 손상 가능성이 있음을 알립니다.
이메일 확인
등록하려면 일회성 토큰을 통한 이메일 주소 확인이 필요합니다. 사용자의 받은편지함으로 전송됩니다. 토큰은 24시간 동안 만료되며 다음을 수행할 수 있습니다. 한 번만 사용하십시오. 확인될 때까지 귀하의 계정은 기능이 제한됩니다.
역할 기반 액세스 제어(RBAC)
RBAC 시스템은 이벤트를 플레이하세요 두 가지 수준에서 작동합니다. 시스템 역할 그리고 나 이벤트별 역할.
시스템 역할
- 관리자: 모든 플랫폼 기능, 사용자 관리, 콘텐츠 조정 및 관리 패널에 대한 액세스에 대한 완전한 액세스
- 사용자: 이벤트 생성 및 참여, 프로필 관리, 모든 기본 기능을 사용할 수 있는 일반 사용자
- 조직자: 고급 분석, 외부 통합 및 대규모 이벤트 관리와 같은 프리미엄 기능에 대한 액세스로 역할 확장
- 중재자: 공개 콘텐츠를 조정하고, 보고서를 관리하고, 플랫폼 정책을 시행할 수 있습니다.
메소드 수준 보안
HTTP 필터 외에도 시스템은 다음을 사용합니다. @PreAuthorize 스프링 시큐리티의
개별 컨트롤러 방법을 보호하여 권한에 대한 세부적인 제어를 제공합니다.
@RestController
@RequestMapping("/api/v1/eventi")
public class EventoController {
@PostMapping
@PreAuthorize("hasAnyRole('USER', 'ORGANIZER')")
public ResponseEntity<EventoResponse> createEvento(
@Valid @RequestBody CreateEventoRequest request) {
// Solo utenti con ruolo USER o ORGANIZER
}
@DeleteMapping("/{id}")
@PreAuthorize("@eventoSecurityService.isOrganizer(#id, authentication)")
public ResponseEntity<Void> deleteEvento(@PathVariable Long id) {
// Solo l'organizzatore dell'evento specifico
}
@GetMapping("/admin/all")
@PreAuthorize("hasRole('ADMIN')")
public ResponseEntity<Page<EventoResponse>> getAllEventi(Pageable pageable) {
// Solo amministratori
}
}보안 헤더
플랫폼은 보호를 위해 포괄적인 보안 HTTP 헤더 세트를 구현합니다. 웹 공격의 주요 범주에 대해 설명합니다.
HEADER DI SICUREZZA
Content-Security-Policy:
default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.stripe.com;
X-Frame-Options: DENY
→ Previene clickjacking (embedding in iframe)
X-Content-Type-Options: nosniff
→ Previene MIME type sniffing
Strict-Transport-Security: max-age=31536000; includeSubDomains
→ Forza HTTPS per un anno
Referrer-Policy: strict-origin-when-cross-origin
→ Limita le informazioni nel referrer header
Set-Cookie: SameSite=Strict
→ Protezione CSRF nativa del browserBucket4j를 사용한 속도 제한
남용, 무차별 대입 공격 및 DDoS를 방지하기 위해 시스템은 다음을 구현합니다. 속도 제한 도서관을 이용하다 Bucket4j, 토큰 버킷 알고리즘을 기반으로 합니다.
- 일반 API: 인증된 사용자당 분당 요청 100개
- 로그인 엔드포인트: IP당 분당 5회 시도(무차별 공격 방지)
- 녹음 끝점: IP당 분당 요청 3개
- 끝점 새로 고침: 사용자당 분당 요청 10개
모범 사례: 차별화된 속도 제한
모든 엔드포인트에 동일한 보안 요구 사항이 있는 것은 아닙니다. 인증 엔드포인트 데이터 읽기 API보다 훨씬 더 제한적인 제한이 필요합니다. 할부 제한은 위험에 비례해야 합니다. 엔드포인트가 더 민감할수록 한도는 낮아야합니다. Bucket4j를 사용하면 다양한 제한을 구성할 수 있습니다. 엔드포인트 그룹당.
BCrypt로 비밀번호 해싱
사용자 비밀번호는 다음과 같이 해시됩니다. B암호화 비용 요소를 사용하여 이는 해싱 작업당 약 250ms를 보장하는 12개입니다. 이는 계산적으로 산출됩니다. 무차별 대입 공격은 데이터베이스가 손상되더라도 비용이 많이 듭니다.
입력 검증
시스템에 입력된 각 데이터는 다음을 사용하여 검증됩니다. 자카르타 콩 검증
(주석 @NotNull, @Size, @Email,
@Pattern) 비즈니스 로직에 도달하기 전에. DTO는 다음과 같은 역할을 합니다.
첫 번째 수준의 방어이며, 도메인의 가치 개체는 두 번째 수준을 제공합니다.
의미론적 검증.
OWASP 상위 10개 규정 준수
시스템은 다음 사항을 고려하여 설계되었습니다. OWASP 상위 10위 웹 애플리케이션에 대한 가장 심각한 취약점입니다.
- A01 - 손상된 액세스 제어: 다중 레벨 RBAC, 리소스 소유자 검증, 최소 권한 원칙
- A02 - 암호화 오류: 강제 HTTPS, 비밀번호용 BCrypt, 저장 중인 민감한 데이터 암호화
- A03 - 주입: JPA/Hibernate를 통한 쿼리 매개변수화, 자동 입력 이스케이프
- A04 - 안전하지 않은 디자인: 위협 모델 아키텍처, 프로젝트 시작부터 보안 설계
- A05 - 잘못된 보안 구성: 완전한 보안 헤더, 환경별 다양한 구성(개발, 스테이징, 프로덕션)
- A07 - 인증 실패: JWT HttpOnly, 새로 고침 회전, 실패한 시도 후 잠금
로그아웃을 위한 토큰 블랙리스트
로그아웃하면 사용자의 토큰이 즉시 무효화됩니다. 블랙리스트. 인증된 각 요청은 진행하기 전에 토큰이 블랙리스트에 등록되지 않았는지 확인합니다. 블랙리스트는 TTL이 최대 수명과 동일한 메모리 내 캐시로 구현됩니다. 토큰의 무제한 성장을 방지합니다.
보호 요약
- SameSite=Strict인 HttpOnly 쿠키의 JWT
- 도난 감지로 토큰 교체 새로 고침
- 2단계 RBAC(시스템 및 이벤트별)
- 완전한 보안 헤더(CSP, HSTS, X-Frame-Options)
- Bucket4j를 사용한 차별화된 속도 제한
- 비용 요소가 12인 BCrypt
- 2단계 입력 유효성 검사(DTO + 값 개체)
- 즉시 로그아웃을 위한 토큰 블랙리스트
보안 관련 소스 코드는 다음에서 확인할 수 있습니다. GitHub. 다음 기사에서는 이벤트 및 참가자 관리에 대해 더 자세히 알아보고 탐색해 보겠습니다. REST API, 상태 머신 및 초대 시스템 이벤트를 플레이하세요.