- vừa được xem lúc

Authentication vulnerability - Lỗ hổng xác thực (phần 6)

0 0 11

Người đăng: Viblo Security

Theo Viblo Asia

VII. Làm thế nào để ngăn chặn Authentication vulnerability - Lỗ hổng xác thực?

1. Xác thực: lớp bảo vệ người dùng - hệ thống đầu tiên

Lỗ hổng xác thực thường là một trong những mục tiêu tấn công đầu tiên của các hacker, bởi có thể coi đây là lớp bảo về người dùng đầu tiên. Khi một hệ thống có cơ chế xác thực lỏng lẻo, điều này thường dễ dàng bị các hacker lợi dụng và chiếm đoạt tài khoản người dùng. Khi hacker có được danh tính xác thực của bạn (từ nhiều cách khác nhau sẽ được bàn luận thêm ở mục sau) thì hầu hết các thông tin bạn lưu trên trang web đó đều bị lộ, đồng thời họ có thể sử dụng các tính năng của trang web với danh tính của bạn, mang lại hậu quả khó lường cho người dùng nói riêng và hệ thống nói chung.

Ở các phần trước, chúng ta đã cùng nhau phân tích và khai thác các lỗ hổng xác thực thông qua các phòng thí nghiệm. Vấn đề xác thực với những tính năng đăng nhập, đăng ký, quên mật khẩu, đặt lại mật khẩu, ... đã có rất nhiều hướng khai thác. Tôi tin rằng vẫn còn nhiều cách tấn công khác ngoài những ví dụ tôi đã trình bày trong bài viết.

Ngoài sơ suất trong quá trình xây dựng ứng dụng từ nhà cung cấp dịch vụ, những hành động bất cẩn của người dùng cũng có thể là cơ hội xâm nhập của kẻ xấu. Vậy nên chúng ta cần có những biện pháp ngăn ngừa, phòng chống dạng lỗ hổng này.

2. Về phía nhà cung cấp dịch vụ

Kỹ thuật đơn giản và khá hiệu quả khi khai thác các lỗ hổng xác thực chính là kỹ thuật vét cạn (Brute force).

2.1. Người dùng không cần biết quá nhiều thông tin không cần thiết

Một trong những việc cần làm đầu tiên là không được phép tiết lộ quá nhiều thông tin cho người dùng. Ví dụ: Khi người dùng nhập sai tên đăng nhập hoặc mật khẩu, thông báo đưa ra tới người dùng chỉ nên có dạng "Tên đăng nhập hoặc mật khẩu không hợp lệ" - chỉ đủ cho người dùng biết họ đang nhập sai, không chỉ ra chính xác sai tên đăng nhập hoặc mật khẩu.

2.2. Yêu cầu mật khẩu mạnh

Yêu cầu người dùng đặt các mật khẩu mạnh. Ví dụ: mật khẩu cần có tối thiểu 8 ký tự, trong đó cần chứa cả ký tự viết thường, viết hoa, chữ số và ký tự đặc biệt.

2.2. Hạn chế các nỗ lực đăng nhập thất bại

Khi phát hiện một người dùng thực hiện đăng nhập sai vượt quá số lần quy định, đó rất có thể là một cuộc tấn công Brute force. Hệ thống có thể thực hiện vô hiệu hóa tài khoản đó trong một thời gian nhất định. Và cứ mỗi lần người dùng tiếp tục đăng nhập thất bại, thời gian vô hiệu hóa đó sẽ càng tăng lên. Điều này thực sự mang lại hiệu quả lớn trong việc phòng chống tấn công vét cạn.

2.3. Xác thực nhiều bước

Yêu cầu nghiêm ngặt hơn trong xác thực 2FA, tốt nhất là mỗi lần đăng nhập đều yêu cầu người dùng sử dụng xác thực hai bước.

2.4. Sử dụng mã Capcha

Mã Capcha có thể xuất hiện dưới dạng một hình ảnh, trên đó có văn bản gồm một chuỗi ký tự chữ cái hoặc số. Người dùng cần nhập đúng mã đó mới có thể thực hiện đăng nhập. Điều này có thể mang đến phiền toái cho người dùng. Nên sử dụng mã Capcha sau khi người dùng đăng nhập sai vượt quá số lần quy định.

2.5. Các biện pháp khác

Ngoài ra còn có một số biện pháp phòng ngừa khác như: Giới hạn đăng nhập vào một địa chỉ hoặc một miền địa chỉ nhất định, sử dụng URL đăng nhập duy nhất, theo dõi log đăng nhập của người dùng, ...

3. Về phía người dùng

Người dùng hiện nay chưa ý thức tốt về việc bảo mật thông tin của họ. Người dùng có trách nhiệm trong việc bảo vệ tài khoản và thông tin cá nhân của họ, điều này cũng giúp bảo vệ sự an toàn của nhà cung cấp khỏi các kẻ tấn công.

  • Không nên sử dụng thông tin cá nhân đặt làm mật khẩu.
  • Không click vào các đường link lạ do người khác gửi.
  • Không điền thông tin vào các trang có dấu hiệu lừa đảo.

Các tài liệu tham khảo

Bình luận

Bài viết tương tự

- vừa được xem lúc

Có thực sự an toàn với Authentication và Authorization , mật khẩu có nên lưu ở dạng text ?

Có thực sự an toàn với Authentication và Authorization , mật khẩu có nên lưu ở dạng text . Hơn nữa, vì chúng ta đang lưu trữ thông tin đăng nhập và hỗ trợ quy trình đăng nhập, chúng ta biết rằng sẽ có thông tin xác thực được gửi qua hạ tầng mạng.

0 0 46

- vừa được xem lúc

Login LINE với Firebase Authentication

Ngày nay, khi sử dụng một dịch vụ online online, chúng ta có xu hướng sử dụng một tài khoản liên kết (Google, Facebook, Twitter... tạm gọi là bên thứ 3) để đăng nhập vào dịch vụ đó thay vì cứ mỗi một dịch vụ, ta lại tạo một account/passord riêng. Lúc này Firebase Authentication (từ đây sẽ gọi tắt là

0 0 35

- vừa được xem lúc

Bài 17: Phân quyền trong Laravel

Chào mừng các bạn quay trở lại với series học Laravel với VueJS của mình, ở bài này mình sẽ hướng dẫn các bạn các phân quyền bằng Laravel và VueJS mà không cần cài đặt thêm bất kì package hay library

0 0 86

- vừa được xem lúc

Phân biệt sự khác nhau giữa Authentication và Authorization

Có lẽ trong quá trình lập trình bạn đã được nghe rất nhiều về 2 khái niệm authentication và authorization nhưng liệu bạn đã phân biệt được sự khác nhau giữa 2 khái niệm này? hay đôi khi bạn vẫn mập mờ

0 0 34

- vừa được xem lúc

[Node JS + React JS] - Phần 2 - Authentication server

Hôm nay chúng ta sẽ tiếp tục serie Node JS + React JS với chủ đề là authentication + authorization. Hôm nay chúng ta cùng đi tìm hiểu hai khái niệm cơ bản là Authentication và Authorization, cũng như

0 0 385

- vừa được xem lúc

API với Postman (Phần 3)

Sau 2 bài viết, chúng ta đã hiểu thế nào là client và server, cách chúng sử dụng HTTP để nói chuyện với nhau và việc xác định định dạng dữ liệu để hiểu nhau. Có lẽ trong đầu chúng ta sẽ có câu hỏi: Là

0 0 71