Form Login, HTTP Basic và Cơ Chế Chống Session Fixation

TL;DR: UsernamePasswordAuthenticationFilter tiếp nhận POST /login, tạo UsernamePasswordAuthenticationToken chưa xác thực và chuyển giao cho DaoAuthenticationProvider. Sau khi kiểm tra mật khẩu qua UserDetailsService và BCryptPasswordEncoder, hệ thống ghi nhận SecurityContext vào HttpSession và phản hồi mã cookie JSESSIONID. HTTP Basic gửi thông tin đăng nhập được mã hóa Base64 trên mỗi request và bắt buộc phải đi qua HTTPS. Cơ chế bảo vệ Session Fixation mặc định của Spring (migrateSession) tự động tái tạo session ID mới ngay sau khi đăng nhập thành công.

Luồng Form Login từ POST /login tới session cookie diễn ra ra sao?

Khi người dùng submit biểu mẫu đăng nhập, chu trình xử lý diễn ra hoàn toàn ở tầng Servlet Filter trước khi chạm tới Controller:

1. Trình duyệt gửi POST /login với các trường username và password.
2. UsernamePasswordAuthenticationFilter đóng gói thành UsernamePasswordAuthenticationToken(authenticated = false).
3. AuthenticationManager kích hoạt DaoAuthenticationProvider.
4. Provider gọi UserDetailsService.loadUserByUsername() để nạp đối tượng UserDetails.
5. Thực hiện so khớp mật khẩu bằng passwordEncoder.matches(rawInput, storedHash).
6. Khi hợp lệ, hệ thống tạo session mới, cấp phát JSESSIONID và chuyển hướng người dùng (302 Redirect).

Cấu hình Form Login hiện đại trong Spring Security 6:

@Configuration
@EnableWebSecurity
public class FormLoginSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/login", "/register", "/css/**").permitAll()
                .anyRequest().authenticated()
            )
            .formLogin(form -> form
                .loginPage("/login")                    // Custom login view endpoint
                .loginProcessingUrl("/api/auth/login")  // POST endpoint processed by Spring
                .defaultSuccessUrl("/dashboard", true)
                .failureUrl("/login?error=true")
                .usernameParameter("email")             // Match HTML form input name
                .passwordParameter("password")
                .permitAll()
            )
            .logout(logout -> logout
                .logoutUrl("/api/auth/logout")
                .logoutSuccessUrl("/login?logout=true")
                .invalidateHttpSession(true)
                .deleteCookies("JSESSIONID")
            );

        return http.build();
    }
}

UsernamePasswordAuthenticationFilter xử lý bên dưới như thế nào?

Bộ lọc kế thừa AbstractAuthenticationProcessingFilter với hai nhánh xử lý rõ ràng:

AbstractAuthenticationProcessingFilter.doFilter()
  └─ requiresAuthentication(request)?        <- URL match check
       └─ attemptAuthentication(request)      <- Extract parameters
            └─ authenticationManager.authenticate(token)
                 └─ DaoAuthenticationProvider.authenticate(token)

Khi xác thực thành công, phương thức successfulAuthentication() kích hoạt ba bước:

1. Nạp danh tính vào SecurityContext.
2. HttpSessionSecurityContextRepository lưu ngữ cảnh vào HttpSession.
3. SavedRequestAwareAuthenticationSuccessHandler chuyển hướng người dùng về trang đích ban đầu.

Nếu thất bại, phương thức unsuccessfulAuthentication() sẽ xóa sạch ngữ cảnh và kích hoạt AuthenticationFailureHandler điều hướng tới trang báo lỗi.

HTTP Basic hoạt động ra sao và tại sao Base64 không phải là mã hóa?

Giao thức HTTP Basic (RFC 7617) gửi thông tin danh tính qua HTTP Header trên từng request:

Authorization: Basic YWRtaW46YWRtaW4xMjM=

Chuỗi YWRtaW46YWRtaW4xMjM= thực chất là kết quả của phép mã hóa Base64 từ văn bản admin:admin123.

Kích hoạt hoặc tắt HTTP Basic trong Spring Security:

// Enable HTTP Basic for internal management
http.httpBasic(Customizer.withDefaults());

// Disable HTTP Basic explicitly for stateless JWT APIs
http.httpBasic(AbstractHttpConfigurer::disable);

HTTP Basic rất phù hợp cho các kịch bản gọi API máy-tới-máy (server-to-server) trong mạng nội bộ riêng hoặc endpoint giám sát /actuator/health.

Làm thế nào để giới hạn số lần đăng nhập sai nhằm chống brute-force?

Spring Security cung cấp hệ thống sự kiện Application Event giúp theo dõi các lần đăng nhập thất bại mà không cần can thiệp vào logic filter:

@Component
@RequiredArgsConstructor
public class LoginAttemptListener {

    private final LoginAttemptService attemptService;

    @EventListener
    public void onFailure(AuthenticationFailureBadCredentialsEvent event) {
        String username = event.getAuthentication().getName();
        attemptService.recordFailure(username);
    }

    @EventListener
    public void onSuccess(AuthenticationSuccessEvent event) {
        String username = event.getAuthentication().getName();
        attemptService.clearFailures(username);
    }
}

Dịch vụ đếm số lần thất bại (sử dụng Redis trong môi trường phân tán):

@Service
public class LoginAttemptService {

    private final Map<String, Integer> failureCount = new ConcurrentHashMap<>();
    private static final int MAX_ATTEMPTS = 5;

    public void recordFailure(String username) {
        int attempts = failureCount.merge(username, 1, Integer::sum);
        if (attempts >= MAX_ATTEMPTS) {
            // Lock user account in database or Redis
        }
    }

    public void clearFailures(String username) {
        failureCount.remove(username);
    }
}

Tấn công Session Fixation là gì và Spring Security ngăn chặn bằng cách nào?

Kịch bản tấn công Session Fixation

Kẻ tấn công khởi tạo sẵn một phiên làm việc hợp lệ với máy chủ, thu thập mã JSESSIONID=ABC123. Sau đó, kẻ xấu lừa nạn nhân đăng nhập qua liên kết chứa mã phiên này. Khi nạn nhân đăng nhập thành công, máy chủ gán quyền hạn của nạn nhân vào chính mã phiên ABC123. Lúc này kẻ tấn công có thể ung dung chiếm đoạt tài khoản mà không cần biết mật khẩu.

Giải pháp đổi Session ID của Spring Security

Giải pháp cốt lõi: Vô hiệu hóa ngay lập tức mã phiên cũ khi đăng nhập thành công và cấp phát một mã phiên hoàn toàn mới.

http.sessionManagement(session -> session
    .sessionFixation().migrateSession() // Default policy: Keep data, issue new ID
);

Các chiến lược cấu hình Session Fixation:

• migrateSession(): Tạo phiên mới, cấp ID mới và sao chép toàn bộ thuộc tính cũ (giỏ hàng, ngôn ngữ). Đây là lựa chọn mặc định tối ưu.
• newSession(): Tạo phiên mới hoàn toàn mà không sao chép thuộc tính cũ.
• none(): Giữ nguyên ID (tuyệt đối không dùng cho các ứng dụng có đăng nhập form trong môi trường production).

Những cạm bẫy phổ biến khi cấu hình Form Login và HTTP Basic là gì?

• Sai lệch loginProcessingUrl: Giá trị action của thẻ <form> trong HTML phải khớp chính xác với đường dẫn cấu hình loginProcessingUrl("/api/auth/login").
• Để bật HTTP Basic trên REST API: Khiến trình duyệt tự động bật popup đăng nhập mặc định gây khó chịu cho người dùng khi token hết hạn.
• Dùng sessionFixation().none() trong ứng dụng Stateful: Mở toang cánh cửa cho các cuộc tấn công chiếm quyền điều khiển phiên.

So sánh Form Login, HTTP Basic và JWT: Khi nào nên chọn giải pháp nào?

Những điểm then chốt cần ghi nhớ là gì?

• Form Login quản lý danh tính thông qua HttpSession và phản hồi cookie JSESSIONID.
• HTTP Basic gửi credential Base64 trên mỗi request và bắt buộc phải đi kèm HTTPS.
• Spring Security chống Session Fixation bằng chiến lược mặc định migrateSession().
• Tách biệt rõ ràng use case giữa Form Login (stateful) và JWT (stateless) khi thiết kế kiến trúc hệ thống.

Bạn đã nắm vững Form Login, HTTP Basic và Session Fixation chưa?

Bài tiếp theo: JWT structure & validation