Trang chủTác giảLiên hệ

11 SAI LẦM TRONG AUTHENTICATION VÀ CÁCH SỬA CHÚNG

By Anonymous
Published in General
September 21, 2022
9 min read

Bảo mật authentication là một khía cạnh thiết yếu của phát triển ứng dụng web thường bị bỏ qua trong khi tạo ra một sản phẩm. Trong bài viết này, tôi sẽ giải thích một số lỗi này và cách khắc phục chúng. Xin lưu ý rằng đây không phải là những vấn đề bảo mật chính mà OWASP khuyến nghị. Thay vào đó, chúng là những vấn đề dễ khắc phục mà tôi thường thấy.

Authentication là gì?

Authentication là quá trình xác nhận danh tính của người dùng hoặc là quá trình xác thực. Khi authentication bị vi phạm, những kẻ tấn công có thể giành được quyền truy cập vào dữ liệu hoặc thông tin của người dùng, gây thiệt hại cho ứng dụng của bạn. Xác thực là một trong những cách kẻ tấn công có thể truy cập vào dữ liệu của người dùng và ứng dụng của bạn.

Khi nói đến xác thực đây là 11 lỗi phổ biến cần tránh:

  1. Hiển thị lỗi thông báo cụ thể
  2. Tích hợp ID phiên bản vào URL
  3. Xác thực biểu mẫu không chính xác
  4. Low-form sanitization
  5. Set up mật khẩu yếu
  6. Không sử dụng xác thực 2 yếu tố (F2A)
  7. Reset password không đúng
  8. Đăng xuất không an toàn
  9. Brute Force Attack
  10. Sử dụng câu hỏi bảo mật yếu
  11. Không bảo vệ Route

1. Hiển thị lỗi thông báo cụ thể.

Hiển thị một thông báo lỗi cụ thể rất nguy hiểm vì nó có thể cho phép kẻ tấn công sử dụng automated trial-and-error method để xác định tên người dùng hoặc mật khẩu của người dùng.

Dưới đây là một ví dụ sơ đồ về việc hiển thị một thông báo lỗi cụ thể.

092201

Khi authentication một biểu mẫu trên ứng dụng web của bạn, bạn phải cẩn thận không chỉ hiển thị một thông báo lỗi khi người dùng gõ một chi tiết không chính xác - chẳng hạn như “mật khẩu của bạn không chính xác.” Nếu bạn hiển thị một thông báo lỗi cụ thể như vậy, kẻ tấn công sẽ nhận ra rằng địa chỉ email hoặc ID người dùng là có thật nhưng mật khẩu là sai. Điều này sẽ cho phép kẻ tấn công đề xuất một mật khẩu cho người dùng đó.

Không bao giờ hiển thị thông báo lỗi cụ thể trên trang xác thực. Điều này cho phép kẻ tấn công biết thông tin nào còn thiếu và cho phép chúng sử dụng một cuộc brute-force-attack để đoán thông tin nào còn thiếu.

2. Tích hợp ID phiên bản vào URL

Session ID là một số mà máy chủ của trang web cung cấp cho một người dùng trong thời gian truy cập của người dùng đó. Cơ hội của kẻ tấn công có được và lạm dụng mã thông báo phiên được tăng lên nếu được đặt trực tiếp vào URL. Mặc dù rủi ro thấp hơn khi sử dụng HTTPS để kết nối với máy chủ web, nhưng vẫn có một mối nguy hiểm. Mặc dù các URL HTTPS được mã hóa trong quá trình vận chuyển, nhưng chúng thường được giữ trong nhật ký máy chủ.

Dưới đây là một ví dụ sơ đồ về việc tích hợp ID phiên vào URL.

092202

Xác thực session ID ở phía máy chủ

Tạo token, đảm bảo bạn sử dụng một trình tạo ngẫu nhiên đủ an toàn.

Sử dụng bộ lọc để xóa session ID khỏi URL

3. Xác thực biểu mẫu không chính xác

Injection attacks, rò rỉ bộ nhớ và các hệ thống bị xâm phạm có thể xảy ra nếu dữ liệu được cung cấp trong một đầu vào biểu mẫu không được kiểm tra hoặc định dạng đúng cách. Người dùng thường gửi mà không điền tất cả các thông tin cần thiết, vì vậy cần xác thực biểu mẫu của bạn để đảm bảo tất cả các thông tin cần thiết đã được đáp ứng trước khi gửi nó đến máy chủ.

Đảm bảo email có định dạnh chuẩn email

Đảm bảo người dùng đã đáp ứng các tiêu chí cho biểu mẫu trước khi gửi

Xác thực biểu mẫu từ backend và frontend sử dụng library hoặc framework được cập nhật.

Một số thư viện được đề xuất mà tôi đề xuất để xác thực biểu mẫu là: Validator, Just-validate, Pristine.

4. Low-form Sanitization

Quá trình giữ cho hình thức đầu vào của bạn sạch sẽ, được lọc và vệ sinh từ một tác nhân độc hại được gọi là khử trùng hình thức. Vệ sinh đầu vào của bạn là điều bắt buộc vì nó ngăn chặn các lỗ hổng Injection. Một hình thức đầu vào được an toàn hóa có thể ngăn chặn các cuộc tấn công sau:

Sanitizing đầu vào biểu mẫu, bạn phải bảo vệ mã và dữ liệu của người dùng khỏi tác nhân độc hại này và tất cả các lỗ hổng được liệt kê. Cá nhân tôi sử dụng DOM Purify, một thư viện sanitizing cho HTML và strings, và nó có thể lọc bất cứ thứ gì có chứa HTML bẩn và ngăn chặn các cuộc tấn công XSS.

Thật dễ dàng và an toàn hơn khi sử dụng danh sách cho phép cho các đầu vào được xác định rõ như số, ngày hoặc mã bưu điện. Về vấn đề đó, bạn có thể nêu rõ những giá trị nào được cho phép và những giá trị nào không.

Sử dụng logic cho phép được xác định trước trong các định nghĩa kiểu dữ liệu tích hợp với xác thực biểu mẫu HTML5.

5. Set up mật khẩu yếu

Không có gì lạ khi bắt gặp một trang web không có gói mật khẩu mạnh mẽ theo thứ tự. Gần đây tôi đã thử một ứng dụng yêu cầu độ dài mật khẩu tối thiểu năm ký tự. Khi các nhà phát triển cố gắng tìm sự cân bằng phù hợp giữa bảo mật và khả năng sử dụng, lỗ hổng này đang trở nên phổ biến hơn. Khi làm việc với mật khẩu, hãy đảm bảo mật khẩu bạn đề xuất cho người dùng hoặc mật khẩu mà người dùng tạo là hỗn hợp các ký hiệu, số và chữ cái hỗn hợp. Tránh các kế hoạch mật khẩu yếu.

Yêu cầu người dùng nhập tối thiểu 12 hoặc 8 ký tự hoặc một cái gì đó dài hơn

Mật khẩu kết hợp tên người dùng hoặc tên công ty nên tránh để bảo mật và khả năng sử dụng.

Chữ hoa và chữ thường nên được trộn lẫn

Sử dụng thư viện để tính toán độ mạnh của mật khẩu, thận trọng trong khi chọn và kiểm tra các phụ thuộc và khả năng bảo trì tối thiểu.

Khi một người có hồ sơ công khai, hãy sử dụng tên hiển thị khác và tránh sử dụng địa chỉ email của người dùng làm tên hiển thị.

6. Không sử dụng xác thực 2 yếu tố (F2A)

Một sai lầm phổ biến khác mà tôi thấy với các cơ chế xác thực web là chúng không có bất kỳ biện pháp an toàn nào. Xác thực hai yếu tố hiếm khi được sử dụng bởi các nhà phát triển, đặc biệt là cho các tài khoản hàng đầu. Xác thực hai yếu tố giúp thêm lớp bảo vệ thứ hai cho ứng dụng của bạn. Xác thực hai yếu tố là rất quan trọng đối với bảo mật web vì nó ngay lập tức loại bỏ các mối nguy hiểm của thông tin bị xâm phạm. Khi mật khẩu bị bẻ khóa, đoán hoặc thậm chí bị nhiễm phần mềm độc hại, việc cấp quyền truy cập vào kẻ xâm nhập mà không có sự chấp thuận nào ở yếu tố xác thực thứ hai.

Xác thực hai yếu tố là một lớp bảo mật bổ sung được thêm vào một trang xác thực. Ví dụ về xác thực hai yếu tố này là SMS, email và OTP.

Đây là một ví dụ sơ đồ về xác thực hai yếu tố:

0922S3

Cách triển khải xác thực 2 yếu tố

Có nhiều cách khác nhau để sử dụng mã hóa 2FA. Mã thông báo RSA, trình tạo mã như Google Authenticator và Duo và gửi văn bản SMS mã một lần là tất cả các tùy chọn để triển khai công nghệ 2FA.

7. Reset password không đúng

Điều này không thường xuyên xảy ra, nhưng thỉnh thoảng, tôi thấy một ứng dụng web có khả năng này được triển khai không chính xác. Điều này thường là do mật khẩu của người dùng đã được gửi cho họ qua email hoặc mã thông báo được sử dụng để đặt lại mật khẩu không đủ mạnh. Việc gửi lại mật khẩu bản rõ cho người dùng cuối là một vấn đề khác ảnh hưởng đến việc đặt lại mật khẩu. Điều này thật tồi tệ vì nhiều lý do khác nhau, một trong số đó là mật khẩu được gửi qua email, được coi là không an toàn. Điều này có thể có nghĩa là mật khẩu được lưu trữ trong cơ sở dữ liệu mà không có đủ băm hoặc ở định dạng có thể bị đảo ngược, như base64.

Hashing: là một kỹ thuật được sử dụng để xác minh hoặc xác nhận chất lượng của nhiều loại đầu vào khác nhau. Trong các hệ thống xác thực, nó chủ yếu được sử dụng để ngăn chặn việc lưu trữ các mật khẩu văn bản rõ ràng, và Hashing khiến những kẻ tấn công vô cùng khó khăn trong việc giải mã các mật khẩu đã được lưu trữ.

Base64: là một phương pháp chuyển đổi dữ liệu nhị phân thành văn bản. Phương pháp này thường được sử dụng để gửi thông tin dựa trên nội dung qua Internet.

Luôn mã hóa mật khẩu người dùng trước khi lưu trữ, không lưu trữ ở dạng thô.

Chỉ gửi email giao dịch sau khi xác thực và xác minh địa chỉ email bằng cách kiểm tra các ký tự hợp lệ và gửi liên kết xác minh có mã thông báo.

8. Đăng xuất không an toàn

Đây là một lỗ hổng khác có thể gây ra sự tàn phá lớn cho một ứng dụng. Nó cũng cần thiết để cung cấp cho người dùng của bạn một cách an toàn để đăng xuất để các phiên của họ không thể bị chiếm đoạt. Nếu bạn đang lưu trữ số nhận dạng phiên ở phía máy chủ, phương pháp đăng xuất sẽ làm mất hiệu lực của nó và xóa cookie phiên trong trình duyệt. Điều này ngăn những kẻ tấn công có thể đánh cắp cookie phiên và sau đó sử dụng chúng để bắt đầu một phiên mới.

Khi người dùng đăng xuất, hãy xóa cookie phiên của trình duyệt và làm mất hiệu lực nhận dạng phiên nếu nó đang được lưu trữ trên máy chủ.

Trong quá trình đăng xuất, phiên người dùng và mã thông báo xác thực phải được vô hiệu hóa một cách chính xác.

9. Brute Force Attack

Brute force là một kỹ thuật hack được sử dụng để tìm ra thông tin đăng nhập của người dùng bằng cách thử nhiều thông tin đăng nhập có thể có. Trong cuộc tấn công này, tin tặc cố gắng đoán mật khẩu để vượt qua xác thực cho một tài khoản. Sử dụng các tập lệnh thử nhiều mật khẩu thường được sử dụng từ từ điển và hàng triệu mật khẩu bị rò rỉ từ các lần vi phạm dữ liệu trước đó, những nỗ lực này có cơ hội thành công cao hơn.

Hạn chế các nỗ lực đăng nhập vào một địa chỉ hoặc dải IP xác định bằng cách chặn quyền truy cập vào URL xác thực.

Không sử dụng thuật ngữ nào từ từ điển bằng bất kỳ ngôn ngữ nào. Thay vì sử dụng các từ, tốt hơn là sử dụng các chuỗi ký tự ngẫu nhiên.

Chặn các địa chỉ IP độc hại bằng CAPTCHAS.

Theo dõi các lần đăng nhập thất bại của người dùng và khóa tài khoản.

10. Sử dụng câu hỏi bảo mất yếu

Một câu hỏi bảo mật hoặc từ dễ nhớ cũng có thể hỗ trợ trong việc bảo vệ chống lại các cuộc tấn công tự động. Tôi đã gặp phải các câu hỏi bảo mật yếu có câu trả lời có thể đoán trước, cho phép kẻ tấn công đề xuất hoặc đoán câu trả lời và có được quyền truy cập vào dữ liệu của người dùng.

Dưới đây là một số câu hỏi bảo mật phổ biến mà tôi đã gặp:

Tránh tất cả những câu hỏi này vì tin tặc có thể đoán chúng do một số thông tin trên Google hoặc các hồ sơ trực tuyến khác.

Đề xuất những câu hỏi người dùng dễ nhớ nhưng kẻ tấn công khó đề xuất

Lưu trữ câu trả lời bằng thuật toán băm an toàn như Bcrypt. Bcrypt là một thuật toán được sử dụng để băm và xác minh mật khẩu. Nó giúp giảm nguy cơ tội phạm mạng tấn công ứng dụng của bạn thông qua mật khẩu.

11. Không bảo vệ Route

Một lỗi khác mà tôi đã thấy các nhà phát triển mắc phải khi nói đến xác thực là “không bảo vệ route”. Điều quan trọng là phải bảo mật các tuyến đường cụ thể trong ứng dụng của bạn khỏi những người dùng không được xác thực, vì điều này sẽ ngăn những người dùng không xác định truy cập vào một số dữ liệu riêng tư của ứng dụng của bạn.

Bảo vệ route bạn muốn người dùng chưa xác thực truy cập. Nếu người dùng đang cố gắng truy cập vào một route cụ thể, hãy chuyển hướng họ đến trang đăng nhập / đăng ký nếu chúng chưa được xác thực

Kết luận:

Khi triển khai xác thực trên trang web của mình, bạn phải hết sức thận trọng với tư cách là nhà phát triển vì một số phương pháp có thể gây hại cho chương trình của bạn và mở ra cánh cửa cho những kẻ tấn công chiếm quyền kiểm soát dữ liệu của người dùng và ứng dụng. Hy vọng rằng, bài viết này đã chỉ ra những lỗi như vậy và đưa ra lời khuyên về cách khắc phục chúng.


Anonymous

Anonymous

Related Posts

General
Xử lý Deadlocks
October 02, 2022
3 min
© 2022, All Rights Reserved.

Quick Links

Liên hệ quảng cáoThông tinLiên hệ

Social Media