SBA301 - Chương 10: Bảo mật ứng dụng — Basic Auth, session và JWT

Mục đích chính của Spring Boot Security là cung cấp tính năng xác thực và ủy quyền cho ứng dụng. Nó cho phép bạn kiểm soát truy cập vào các tài nguyên của ứng dụng, đảm bảo rằng chỉ những người dùng được phép mới có thể truy cập vào chúng. Spring Boot Security cung cấp các tính năng như xác thực người dùng, ủy quyền, bảo vệ chống lại các cuộc tấn công như SQL injection và cross-site scripting (XSS). Nó cũng cho phép bạn cấu hình các chính sách bảo mật tùy chỉnh để đáp ứng nhu cầu của ứng dụng. Ngoài ra, Spring Boot Security cũng hỗ trợ các phương thức xác thực như xác thực dựa trên username và password, xác thực dựa trên token, và xác thực dựa trên OAuth.

JWT (JSON Web Token) là một loại token được sử dụng để xác thực và truyền thông tin giữa các ứng dụng. Header của JWT chứa thông tin về thuật toán ký và loại token. Nó được sử dụng để xác định cách thức ký token và loại token được sử dụng. Ví dụ, nếu header chứa thông tin về thuật toán HMAC SHA256 và loại token là JWT, thì ứng dụng nhận được token có thể xác định được cách thức ký token và loại token được sử dụng. Điều này giúp ứng dụng nhận được token có thể xác thực và giải mã token một cách chính xác. Ngoài ra, header còn chứa thông tin về phiên bản của JWT, giúp ứng dụng nhận được token có thể xác định được phiên bản của token và xử lý token một cách phù hợp.

Bước thứ hai trong việc triển khai JWT trong Spring REST là cấu hình bảo mật Spring. Để thực hiện bước này, bạn cần thêm các lớp bảo mật vào ứng dụng của mình. Điều này bao gồm việc tạo một lớp bảo mật dựa trên JWT và thêm nó vào ứng dụng. Lớp bảo mật này sẽ chịu trách nhiệm kiểm tra và xác thực các token JWT. Ngoài ra, bạn cũng cần cấu hình các tham số bảo mật như thời gian tồn tại của token, cách thức tạo token và cách thức xác thực token.

Hàm HttpSession.invalidate() trong bảo mật dựa trên phiên (session-based security) có mục đích xóa bỏ phiên hiện tại và tất cả các thuộc tính của nó. Khi gọi hàm này, phiên sẽ bị hủy bỏ và không thể tiếp tục sử dụng. Điều này giúp ngăn chặn việc truy cập trái phép vào dữ liệu của phiên đã bị xóa. Ngoài ra, hàm này cũng giúp giải phóng tài nguyên hệ thống đã được sử dụng bởi phiên bị xóa. Tùy chọn này thường được sử dụng trong trường hợp người dùng đăng xuất khỏi hệ thống hoặc khi phiên đã hết hạn.

Nếu một khách hàng gửi một yêu cầu mà không có tiêu đề Authorization và máy chủ yêu cầu Basic Auth, máy chủ sẽ phản hồi với mã trạng thái 401 Unauthorized và tiêu đề WWW-Authenticate. Điều này là bởi vì máy chủ yêu cầu khách hàng phải cung cấp thông tin xác thực trước khi truy cập vào tài nguyên được bảo vệ. Tiêu đề WWW-Authenticate sẽ chứa thông tin về phương thức xác thực được yêu cầu, trong trường hợp này là Basic Auth. Khách hàng sẽ phải gửi lại yêu cầu với tiêu đề Authorization chứa thông tin xác thực để máy chủ xác thực và cấp quyền truy cập vào tài nguyên.

Để một máy chủ yêu cầu trình duyệt hiển thị hộp thoại đăng nhập cho Basic Auth, máy chủ cần gửi một phản hồi 401 (Không được phép) với tiêu đề HTTP WWW-Authenticate. Tiêu đề này chứa thông tin về tên miền (realm) mà máy chủ đang yêu cầu. Ví dụ, máy chủ có thể gửi phản hồi 401 với tiêu đề WWW-Authenticate: Basic realm='RealmName'. Điều này sẽ yêu cầu trình duyệt hiển thị hộp thoại đăng nhập cho người dùng, nơi họ có thể nhập tên người dùng và mật khẩu. Sau khi người dùng nhập thông tin đăng nhập, trình duyệt sẽ gửi lại yêu cầu đến máy chủ với tiêu đề Authorization chứa thông tin đăng nhập. Máy chủ sẽ kiểm tra thông tin đăng nhập và trả lại phản hồi 200 nếu thông tin đúng, hoặc tiếp tục trả lại phản hồi 401 nếu thông tin sai.

Trong Basic Authentication, định dạng của tiêu đề Authorization sẽ trông như thế nào? Đây là một dạng xác thực cơ bản sử dụng tiêu đề Authorization để xác thực người dùng. Khi sử dụng Basic Authentication, người dùng sẽ gửi tiêu đề Authorization với nội dung là 'Basic' kèm theo mã hóa base64 của chuỗi 'username:password'. Ví dụ, nếu username là 'user' và password là 'pass', thì tiêu đề Authorization sẽ được gửi dưới dạng 'Authorization: Basic dXNlcjpwYXNzd29yZA=='. Mã hóa base64 được sử dụng để bảo mật thông tin người dùng.

HTTP header được sử dụng phổ biến để truyền tải ID phiên là Cookie. Cookie là một phần của HTTP header được sử dụng để lưu trữ thông tin về phiên làm việc của người dùng. Khi người dùng đăng nhập vào một trang web, trang web sẽ tạo một ID phiên và lưu trữ nó trong Cookie. Mỗi lần người dùng gửi yêu cầu đến trang web, Cookie sẽ được gửi kèm theo yêu cầu và trang web sẽ sử dụng ID phiên để xác thực người dùng. Điều này giúp trang web có thể lưu trữ thông tin về người dùng và cung cấp trải nghiệm cá nhân hóa. Ngoài ra, Cookie cũng được sử dụng để lưu trữ thông tin về các lựa chọn của người dùng, chẳng hạn như ngôn ngữ hoặc kích thước font.

Basic Authentication là một phương thức xác thực cơ bản trong đó người dùng gửi thông tin đăng nhập (tên người dùng và mật khẩu) qua mỗi yêu cầu HTTP. Phương thức này không yêu cầu lưu trữ phiên trên máy chủ, vì vậy nó được coi là một phương thức stateless. Điều này có nghĩa là máy chủ không cần lưu trữ thông tin về phiên hiện tại của người dùng, giúp giảm thiểu khả năng bị tấn công từ chối dịch vụ (DDoS). Ngoài ra, Basic Authentication có thể được sử dụng với các API REST, vì nó cung cấp một cách đơn giản để xác thực người dùng. Tuy nhiên, phương thức này không được coi là an toàn hơn OAuth2. Trên thực tế, Basic Authentication gửi thông tin đăng nhập qua mỗi yêu cầu HTTP, điều này có thể dễ bị bắt trộm và sử dụng bởi kẻ tấn công. Do đó, OAuth2 được coi là một phương thức an toàn hơn vì nó yêu cầu người dùng xác thực thông qua một ứng dụng trung gian và không gửi thông tin đăng nhập qua mỗi yêu cầu.

Trong HTTP Basic authentication, thông tin xác thực được truyền đi dưới dạng mã hóa Base64 và được gửi trong tiêu đề Authorization. Điều này có nghĩa là thông tin xác thực được mã hóa bằng một thuật toán mã hóa Base64, sau đó được gửi đến server trong tiêu đề Authorization. Server sẽ nhận được thông tin này và giải mã nó để xác thực người dùng. Việc truyền thông tin xác thực dưới dạng mã hóa Base64 giúp bảo vệ thông tin khỏi bị đọc hoặc truy cập trái phép trong quá trình truyền đi.

Trong bảo mật dựa trên phiên (Session-Based Security), ID phiên thường được lưu trữ ở đâu? ID phiên là một chuỗi ngẫu nhiên được tạo ra khi người dùng đăng nhập vào hệ thống. Nó được sử dụng để xác thực và theo dõi hoạt động của người dùng trong phiên hiện tại. ID phiên thường được lưu trữ trong một cookie hoặc URL. Cookie là một loại dữ liệu được lưu trữ trên trình duyệt của người dùng, trong khi URL là địa chỉ web được sử dụng để truy cập vào một trang web cụ thể. Khi người dùng đăng nhập vào hệ thống, ID phiên sẽ được lưu trữ trong cookie hoặc URL và được gửi lại cho server mỗi khi người dùng thực hiện một yêu cầu. Điều này cho phép server xác thực và theo dõi hoạt động của người dùng một cách hiệu quả.

Trong RESTful APIs, phương thức xác thực gửi thông tin xác thực với mỗi yêu cầu là Basic Authentication. Phương thức này gửi thông tin xác thực của người dùng, bao gồm tên người dùng và mật khẩu, trong mỗi yêu cầu HTTP. Điều này có thể không an toàn vì thông tin xác thực được gửi qua đường truyền không bảo mật. Token-based authentication (JWT) và OAuth 2.0 cũng là các phương thức xác thực phổ biến trong RESTful APIs, nhưng chúng không gửi thông tin xác thực với mỗi yêu cầu. Thay vào đó, chúng sử dụng token hoặc mã xác thực để xác thực người dùng.