Authentication
PreviousLab: SQL injection with filter bypass via XML encodingNextLỗ hổng trong đăng nhập bằng mật khẩu
Last updated
Last updated
Xác thực là quá trình xác minh danh tính của người dùng hoặc khách hàng.
Những nhân tố xác thực:
Cơ chế xác thực dựa vào nhiều công nghệ khác nhau để xác minh một hoặc nhiều yếu tố này.
Authentication là uá trình xác minh người dùng có phải là người mà họ tuyên bố hay không
Authorization liên quan đến việc xác minh xem người dùng có được phép làm điều gì đó hay không.
Hầu hết các lỗ hổng trong cơ chế xác thực xảy ra theo một trong hai cách sau:
Cơ chế xác thực yếu vì chúng không bảo vệ hiệu quả trước các cuộc tấn công bằng phương pháp brute force.
Các lỗ hổng trong xác thực có thể gây hậu quả nghiêm trọng. Nếu kẻ tấn công có thể vượt qua xác thực hoặc tấn công bằng brute-force để truy cập vào tài khoản của người dùng khác, họ có thể truy cập toàn bộ dữ liệu và chức năng của tài khoản bị xâm nhập. Nếu tài khoản bị xâm nhập là tài khoản có quyền cao như quản trị viên hệ thống, kẻ tấn công có thể kiểm soát hoàn toàn ứng dụng và thậm chí xâm nhập vào hạ tầng nội bộ.
Ngay cả khi chỉ xâm nhập vào tài khoản có quyền hạn thấp, kẻ tấn công vẫn có thể truy cập dữ liệu mà bình thường họ không có quyền, chẳng hạn như thông tin kinh doanh nhạy cảm. Ngay cả khi tài khoản không có quyền truy cập dữ liệu nhạy cảm, nó vẫn có thể cho phép kẻ tấn công truy cập vào các trang nội bộ khác, từ đó mở rộng bề mặt tấn công. Những cuộc tấn công có mức độ nghiêm trọng cao thường không thể thực hiện từ các trang công khai, nhưng có thể khả thi từ các trang nội bộ.
Một số loại lỗ hổng phổ biến nhất:
Lỗ hổng trong đăng nhập bằng mật khẩu
Lỗ hổng trong xác thực đa yếu tố
Lỗ hổng trong các cơ chế xác thực khác
Tính bảo mật của trang web bị xâm phạm nếu kẻ tấn công có thể lấy hoặc đoán được thông tin đăng nhập của người dùng khác.
Brute-force không phải lúc nào cũng chỉ là trường hợp đoán tên người dùng và mật khẩu một cách hoàn toàn ngẫu nhiên. Bằng cách sử dụng logic cơ bản hoặc kiến thức công khai, kẻ tấn công có thể tinh chỉnh các cuộc tấn công brute-force để đưa ra những phỏng đoán có căn cứ hơn nhiều
Brute-forcing usernames
Tên người dùng đặc biệt dễ đoán nếu chúng tuân theo một mẫu dễ nhận biết, chẳng hạn như địa chỉ email. Ngay cả khi không có mẫu rõ ràng, đôi khi các tài khoản có đặc quyền cao cũng được tạo bằng tên người dùng có thể dự đoán được, chẳng hạn như adminhoặc administrator.
Trong quá trình kiểm tra, kiểm tra xem trang web có tiết lộ tên người dùng công khai hay không. Ví dụ, nếu truy cập được hồ sơ người dùng mà không cần đăng nhập, có thể đoán tên đănh nhập dựa theo nội dung hạn chế đó. Cũng nên kiểm tra phản hồi HTTP có chưa bất kỳ email nào không
Brute-forcing passwords
Thay vì tạo mật khẩu mạnh với sự kết hợp ngẫu nhiên các ký tự, người dùng thường lấy một mật khẩu mà họ có thể nhớ và cố gắng chỉnh nó để phù hợp với chính sách mật khẩu. Ví dụ, nếu mypasswordkhông được phép, người dùng có thể thử một cái gì đó như Mypassword1!hoặc Myp4$$w0rdthay vào đó.
Trong trường hợp chính sách yêu cầu người dùng thay đổi mật khẩu thường xuyên, người dùng cũng thường chỉ thực hiện những thay đổi nhỏ, có thể dự đoán được đối với mật khẩu ưa thích của họ
Username enumeration
Mã trạng thái : Trong một cuộc tấn công brute-force, mã trạng thái HTTP trả về có khả năng giống nhau đối với phần lớn các phỏng đoán vì hầu hết chúng sẽ sai. Nếu một phỏng đoán trả về mã trạng thái khác, thì đây là dấu hiệu rõ ràng cho thấy tên người dùng là đúng.
Thông báo lỗi : Đôi khi thông báo lỗi trả về khác nhau tùy thuộc vào việc cả tên người dùng và mật khẩu đều không đúng hay chỉ có mật khẩu không đúng.
Thời gian phản hồi : Nếu hầu hết các yêu cầu được xử lý với thời gian phản hồi tương tự, bất kỳ yêu cầu nào khác với thời gian này đều cho thấy có điều gì đó khác đang diễn ra ở hậu trường. Đây là một dấu hiệu khác cho thấy tên người dùng được đoán có thể đúng.
Brute-force protection bị lỗi
Hai cách phổ biến nhất để ngăn chặn các cuộc tấn công brute-force là:
Khóa tài khoản mà người dùng từ xa đang cố gắng truy cập nếu họ thực hiện quá nhiều lần đăng nhập không thành công
Chặn địa chỉ IP của người dùng từ xa nếu họ thực hiện quá nhiều lần đăng nhập liên tiếp
Có một số triển khai bằng logic sai như: Bố đếm số lần không thành công sẽ reset nếu chủ sở hữu IP đăng nhập thành công. Trong trường hợp này, chỉ cần thêm thông tin đăng nhập của bạn vào wordlist theo các khoảng thời gian đều đặn.
Account locking
Một cách mà các trang web cố gắng ngăn chặn brute-forcing là khóa tài khoản nếu đáp ứng một số tiêu chí đáng ngờ, thường là một số lần đăng nhập không thành công. Cũng giống như lỗi đăng nhập thông thường, phản hồi từ máy chủ cho biết tài khoản đã bị khóa cũng có thể giúp kẻ tấn công liệt kê tên người dùng.
Cách tiếp cận này không ngăn chặn đầy đủ các cuộc tấn công brute-force trong đó kẻ tấn công chỉ cố gắng truy cập vào bất kỳ tài khoản ngẫu nhiên nào mà chúng có thể.
Ví dụ:
Kẻ tấn công có thể:
Liệt kê danh sách các username có khả năng hợp lệ.
Chọn một số mật khẩu ngắn mà có thể có người dùng sử dụng, đảm bảo số lần thử không vượt quá giới hạn đăng nhập (ví dụ, 3 lần).
Dùng công cụ như Burp Intruder để thử các mật khẩu với từng username mà không kích hoạt việc khóa tài khoản.
Tấn công credential stuffing: Credential stuffing là việc sử dụng các cặp username mật khẩu bị lộ trong các vụ rò rỉ dữ liệu trước đó để đăng nhập. Tấn công này dựa trên việc nhiều người dùng tái sử dụng thông tin đăng nhập trên nhiều trang web khác nhau. Việc khóa tài khoản không ngăn chặn được credential stuffing vì mỗi username chỉ bị thử một lần.
User rate limiting
Giới hạn tốc độ người dùng là một biện pháp nhằm ngăn chặn tấn công brute-force bằng cách chặn địa chỉ IP nếu có quá nhiều yêu cầu đăng nhập trong một khoảng thời gian ngắn. Cách unblock IP có thể bao gồm:
Tự động sau một khoảng thời gian nhất định.
Thủ công bởi quản trị viên.
Thủ công bởi người dùng sau khi hoàn thành CAPTCHA.
Giới hạn tốc độ người dùng thường được ưu tiên hơn việc khóa tài khoản do ít bị lạm dụng để liệt kê username hoặc gây từ chối dịch vụ (DoS). Tuy nhiên, nó vẫn không hoàn toàn an toàn. Kẻ tấn công có thể lách giới hạn bằng cách thay đổi IP hoặc sử dụng nhiều mật khẩu trong một yêu cầu duy nhất.
HTTP Basic Authentication là một phương thức xác thực đơn giản nhưng khá cũ. Nó hoạt động bằng cách tạo một token xác thực từ username và password, sau đó mã hóa bằng Base64. Token này được lưu và quản lý bởi trình duyệt, tự động thêm vào header Authorization trong mọi yêu cầu tiếp theo:
Những điểm yếu của HTTP Basic Authentication:
Thiếu bảo mật: Phương thức này gửi thông tin đăng nhập trong mỗi yêu cầu. Nếu trang web không dùng , thông tin đăng nhập có thể bị chặn bởi các cuộc tấn công man-in-the-middle.
Dễ bị brute-force: Do token chỉ chứa giá trị cố định, HTTP Basic Authentication thường không có biện pháp chống lại brute-force.
Dễ bị CSRF: Phương thức này không tự bảo vệ khỏi các tấn công CSRF (Cross-Site Request Forgery).
Dù đôi khi chỉ cấp quyền truy cập đến các trang không quan trọng, thông tin đăng nhập này có thể bị tái sử dụng cho những mục tiêu quan trọng hơn, tạo ra rủi ro lớn.
Xác thực đa yếu tố (MFA) thêm một lớp bảo mật bằng cách yêu cầu người dùng xác minh danh tính của mình bằng nhiều yếu tố, thường là mật khẩu (thứ bạn biết) và mã xác minh từ một thiết bị (thứ bạn có). Mặc dù MFA, đặc biệt là xác thực hai yếu tố (2FA), thường an toàn hơn so với xác thực một yếu tố, nó vẫn có thể dễ bị tấn công nếu không được triển khai đúng cách.
Mã xác minh thường được lấy từ một thiết bị chuyên dụng như mã token RSA hoặc ứng dụng Google Authenticator, giúp tăng cường bảo mật. Tuy nhiên, một số trang web lại gửi mã qua SMS, tạo ra rủi ro bị chặn hoặc tấn công bằng cách chuyển đổi SIM (SIM swapping). Điều này có thể dẫn đến việc kẻ tấn công chiếm đoạt mã xác minh và xâm nhập vào tài khoản người dùng.
Nếu người dùng được nhắc nhập mật khẩu trước, sau đó được nhắc nhập mã xác minh trên một trang riêng, thì người dùng thực sự ở trạng thái "đã đăng nhập" trước khi họ nhập mã xác minh. Trong trường hợp này, thử xem có thể trực tiếp bỏ qua các trang "logged-in only" sau khi hoàn tất bước xác thực đầu tiên hay không. Thỉnh thoảng, một số trang web không thực sự kiểm tra xem người dùng đã hoàn tất bước thứ hai hay chưa trước khi tải trang.
Logic sai lầm trong xác thực hai yếu tố có nghĩa là sau khi người dùng hoàn tất bước đăng nhập đầu tiên, trang web không xác minh đầy đủ rằng người dùng đó đang hoàn tất bước thứ hai.
Ví dụ, người dùng đăng nhập bằng thông tin đăng nhập thông thường của họ ở bước đầu tiên như sau:
POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty
Sau đó, họ được chỉ định một cookie liên quan đến tài khoản của họ trước khi chuyển sang bước thứ hai của quy trình đăng nhập:
HTTP/1.1 200 OK
Set-Cookie: account=carlos
GET /login-steps/second HTTP/1.1
Cookie: account=carlos
Khi gửi mã xác minh, yêu cầu sẽ sử dụng cookie này để xác định tài khoản nào người dùng đang cố truy cập:
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456
Trong trường hợp này, kẻ tấn công có thể đăng nhập bằng thông tin đăng nhập của riêng chúng nhưng sau đó thay đổi giá trị của accountcookie thành bất kỳ tên người dùng tùy ý nào khi gửi mã xác minh.
POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456
Điều này cực kỳ nguy hiểm nếu kẻ tấn công sau đó có thể dùng brute-force để lấy mã xác minh vì nó sẽ cho phép chúng đăng nhập vào tài khoản của người dùng tùy ý hoàn toàn dựa trên tên người dùng của họ. Chúng thậm chí không cần biết mật khẩu của người dùng.
Cũng như mật khẩu, các trang web cần thực hiện các bước để ngăn chặn việc tấn công bằng brute force mã xác minh 2FA vì mã thường là một số đơn giản gồm 4 hoặc 6 chữ số.
Một tính năng phổ biến là tùy chọn duy trì trạng thái đăng nhập ngay cả sau khi đóng phiên trình duyệt (thường là một check box có nhãn như "Remember me" hoặc "Remember me")
Tính năng này hoạt động bằng cách tạo ra một token "remember me" được lưu trong cookie. Tuy nhiên, nếu token này được tạo dựa trên các giá trị tĩnh dễ đoán, như tên người dùng và thời gian, hoặc thậm chí cả mật khẩu, thì sẽ rất nguy hiểm. Kẻ tấn công có thể tạo tài khoản để nghiên cứu cách token được tạo, từ đó suy ra công thức và brute-force các token của người dùng khác.
Việc mã hóa cookie không đúng cách, chẳng hạn sử dụng Base64, không mang lại sự bảo mật. Ngay cả khi sử dụng mã hóa đúng, nếu không thêm salt và sử dụng thuật toán băm dễ đoán, kẻ tấn công vẫn có thể brute-force cookie. Điều này có thể cho phép chúng vượt qua giới hạn đăng nhập mà không bị phát hiện.
Ngay cả khi kẻ tấn công không thể tự tạo tài khoản, chúng vẫn có thể khai thác lỗ hổng này bằng cách sử dụng các kỹ thuật như XSS để đánh cắp cookie "remember me" của người dùng khác và phân tích cách cookie được tạo ra. Nếu trang web sử dụng framework mã nguồn mở, chi tiết về cách tạo cookie có thể đã được công khai.
Trong một số trường hợp hiếm, kẻ tấn công thậm chí có thể lấy được mật khẩu của người dùng dưới dạng rõ ràng từ cookie, ngay cả khi nó đã được băm. Các danh sách mật khẩu phổ biến cùng với bản băm của chúng có sẵn trên mạng, nên việc giải mã đôi khi chỉ đơn giản là tìm kiếm bản băm đó trên công cụ tìm kiếm. Điều này cho thấy tầm quan trọng của việc sử dụng salt trong quá trình mã hóa.
Gửi mật khẩu qua email
Việc gửi mật khẩu hiện tại của người dùng qua email là không an toàn. Một số trang web thay vào đó tạo ra mật khẩu mới và gửi cho người dùng qua email.
Gửi mật khẩu qua các kênh không an toàn dễ bị tấn công MiTM Bên cạnh đó, hộp thư điện tử không phải là nơi lưu trữ thông tin bảo mật tốt và dễ bị truy cập từ nhiều thiết bị qua các kênh không an toàn.
Đặt lại mật khẩu bằng URL
Một phương pháp an toàn hơn là gửi URL đặc biệt để người dùng truy cập và đặt lại mật khẩu. Các triển khai kém bảo mật thường sử dụng tham số dễ đoán để xác định tài khoản, ví dụ:
Trong trường hợp này, kẻ tấn công có thể thay đổi tham số user để đặt lại mật khẩu của bất kỳ tài khoản nào.
Một cách tiếp cận an toàn hơn là tạo ra một token có độ ngẫu nhiên cao, khó đoán và tạo URL dựa trên token này:
Khi người dùng truy cập URL này, hệ thống sẽ kiểm tra token trên máy chủ để xác định tài khoản cần đặt lại mật khẩu. Token nên hết hạn sau một khoảng thời gian ngắn và bị hủy ngay sau khi mật khẩu được đặt lại.
Tuy nhiên, một số trang web không kiểm tra lại token khi gửi biểu mẫu đặt lại. Trong trường hợp này, kẻ tấn công có thể sử dụng trang đặt lại từ tài khoản của chính họ, xóa token và đặt lại mật khẩu cho tài khoản khác.
Nếu URL trong email đặt lại được tạo động, điều này cũng có thể dễ bị đầu độc đặt lại mật khẩu. Trong trường hợp này, kẻ tấn công có khả năng đánh cắp mã thông báo của người dùng khác và sử dụng nó để thay đổi mật khẩu của họ.
Thông thường, việc thay đổi mật khẩu yêu cầu người dùng nhập mật khẩu hiện tại và sau đó nhập mật khẩu mới hai lần. Các trang này chủ yếu dựa vào cùng một quy trình kiểm tra sự khớp nhau giữa tên người dùng và mật khẩu hiện tại giống như trang đăng nhập thông thường. Do đó, chúng có thể bị tấn công bởi các kỹ thuật tương tự.
Chức năng thay đổi mật khẩu có thể đặc biệt nguy hiểm nếu nó cho phép kẻ tấn công truy cập trực tiếp mà không cần đăng nhập vào tài khoản của người dùng nạn nhân. Ví dụ, nếu tên người dùng được cung cấp trong một trường ẩn, kẻ tấn công có thể chỉnh sửa giá trị này trong yêu cầu để nhắm mục tiêu đến người dùng tùy ý. Điều này có thể bị khai thác để liệt kê tên người dùng và thực hiện tấn công brute-force mật khẩu.
Bảo vệ thông tin đăng nhập của người dùng:
Luôn sử dụng HTTPS để truyền tải thông tin đăng nhập và bắt buộc chuyển hướng từ HTTP sang HTTPS.
Thường xuyên kiểm tra trang web để tránh việc vô tình tiết lộ tên người dùng hoặc email.
Không dựa vào người dùng để đảm bảo an ninh:
Thực thi chính sách mật khẩu an toàn bằng cách sử dụng công cụ kiểm tra độ mạnh của mật khẩu (ví dụ: zxcvbn) thay vì các quy tắc truyền thống mà người dùng có thể lách với các mật khẩu dễ đoán.
Ngăn chặn việc lộ thông tin tên người dùng:
Sử dụng thông báo lỗi giống nhau và phản hồi HTTP đồng nhất cho mọi lần đăng nhập thất bại để tránh tiết lộ tính hợp lệ của tên người dùng.
Giữ thời gian phản hồi đồng nhất để không tiết lộ gợi ý.
Triển khai bảo vệ mạnh mẽ chống tấn công brute-force:
Áp dụng giới hạn tốc độ dựa trên IP kết hợp với CAPTCHA sau một số lần đăng nhập nhất định.
Dù không thể hoàn toàn ngăn chặn, nhưng việc làm cho các cuộc tấn công trở nên khó khăn sẽ khiến kẻ tấn công từ bỏ.
Kiểm tra kỹ lưỡng logic xác minh:
Thường xuyên kiểm tra và thử nghiệm logic xác thực để phát hiện các lỗ hổng, vì ngay cả những lỗi nhỏ cũng có thể bị khai thác.
Bảo mật các chức năng bổ sung:
Bảo vệ các tính năng như đặt lại mật khẩu và trang đăng ký, vì chúng cũng có thể là mục tiêu tấn công.
Triển khai xác thực đa yếu tố (MFA) hiệu quả:
Sử dụng các thiết bị hoặc ứng dụng chuyên dụng (ví dụ: Google Authenticator) để tạo mã xác thực.
Tránh các phương pháp MFA dễ bị khai thác như xác thực qua email hoặc SMS, vốn có thể bị tấn công bằng cách hoán đổi SIM.
Đảm bảo logic của hệ thống MFA được triển khai vững chắc và không dễ bị lách qua.
Một cái gì đó bạn biết , chẳng hạn, , (pass phrase) hoặc (personal identification number - PIN). Đôi khi chúng được gọi là "yếu tố kiến thức".
Một thứ gì đó bạn có (chẳng hạn, chứng minh thư (ID card), (security token), (software token) hoặc (cell phone)). Đôi khi chúng được gọi là "yếu tố sở hữu".
Một cái gì đó bạn sở hữu hoặc tạo ra (chẳng hạn, hoặc , chuỗi (có đủ loại định nghĩa về cái nào là cái thích hợp và đầy đủ), mẫu hình về giọng nói (cũng có vài định nghĩa ở đây nữa), sự xác minh chữ ký, tín hiệu sinh điện đặc hữu do cơ thể sống tạo sinh (unique bio-electric signals), hoặc những biệt danh (biometric) identifier). Đôi khi chúng được gọi là "yếu tố vốn có"
hoặc mã hóa kém trong quá trình triển khai cho phép kẻ tấn công bỏ qua hoàn toàn cơ chế xác thực. Đôi khi điều này được gọi là "broken authentication".
Một số trang web cố gắng ngăn chặn điều này bằng cách tự động đăng xuất người dùng nếu họ nhập một số mã xác minh không chính xác nhất định. Điều này không hiệu quả trong thực tế vì kẻ tấn công nâng cao thậm chí có thể tự động hóa quy trình nhiều bước này bằng cách cho Burp Intruder. Tiện ích mở rộng cũng có thể được sử dụng cho mục đích này.
