Đây là bài học và bài tập tổng quát dành cho các bạn tham gia khóa học Hacker Mũ Xám Owasp Web Hacking. Để tham khảo và thực hành các bạn cần đăng kí 1 tài khoản TryHackMe, nên nâng cấp lên premium 1 tháng nếu có thể (dùng email edu.vn sẽ được giảm giá tứ 14 $ còn 11.2$ mỗi tháng). Đăng kí nguyên năm thì họ sẽ giảm còn 8.5 $ mỗi tháng, các bạn nên xem thêm trên trang chủ tryhackme.com ! Tuy nhiên, khóa học có cung cấp đầy đủ môi trường thực hành trên lab ảo gồm Kali Linux 2023.2 , Metasploitable 2, OWASPbwa và BeeBug kèm giáo trình.

Hiện nay, đã có phiên bản Kali Linux mới 2023 và Kali Purple nên BQT có yêu cầu cài đặt Kali Tím và OpenVas trên máy này (sau đó triển thêm cái Nessus)

Để làm lab trên TryHackMe room OWASP Top 10 Web Hacking tại đây !

Giới thiệu : OWASP Top 10 là gì ?

OWASP Top 10 là một danh sách được công bố bởi OWASP (Open Web Application Security Project) – một tổ chức phi lợi nhuận hàng đầu trong lĩnh vực bảo mật ứng dụng web. Danh sách này liệt kê mười lỗ hổng bảo mật phổ biến và nguy hiểm nhất mà các ứng dụng web thường mắc phải. OWASP Top 10 nhằm cung cấp hướng dẫn và chú trọng vào việc giảm thiểu các rủi ro bảo mật trong quá trình phát triển và triển khai ứng dụng web.

Các phiên bản OWASP Top 10 được cập nhật và công bố theo từng chu kỳ, phản ánh xu hướng và thực tế của các cuộc tấn công trong ngành công nghệ thông tin. Phiên bản OWASP Top 10 phổ biến nhất hiện nay là OWASP Top 10 2021, hãy xem tại đây

Nhiệm vụ 1 : Cũng là phần kiến thức đầu tiên về OWASP Top 10 các bạn nên tha khảo. Danh sách dưới đây la 2017, các bạn hãy đối chiếu với OWASP Top 10 / 2021 để nhận biết được sự thay đổi.

Phần này chia nhỏ từng chủ đề OWASP và bao gồm thông tin chi tiết về lỗ hổng là gì, cách chúng xảy ra và cách bạn có thể khai thác. Bạn sẽ áp dụng lý thuyết vào thực tế bằng cách hoàn thành các thử thách kèm theo.

Các bạn hãy tham khảo 10 khái niệm quan trọng sau đây :

• 1- Injection : Đứng top 1 trong danh sách 2017 và thứ 3 trong danh sách 2021.

Injection attack (tấn công Injection) là một kỹ thuật tấn công phổ biến trong lĩnh vực bảo mật ứng dụng web. Khi một ứng dụng web không xử lý đầu vào người dùng một cách an toàn, kẻ tấn công có thể chèn (inject) mã độc vào các trường dữ liệu đầu vào như form nhập liệu, truy vấn cơ sở dữ liệu, hoặc các thông số URL.

Injection attack có thể xảy ra trong nhiều dạng như SQL injection, XSS (Cross-Site Scripting) injection, LDAP (Lightweight Directory Access Protocol) injection, hoặc OS (Operating System) command injection. Mục đích của các cuộc tấn công này thường là để lợi dụng lỗ hổng để truy cập hoặc thay đổi dữ liệu trong hệ thống, thực thi mã độc, hoặc thậm chí kiểm soát hoàn toàn ứng dụng web.

SQL injection là một dạng phổ biến của injection attack, trong đó kẻ tấn công chèn các câu lệnh SQL độc hại vào các truy vấn SQL để thực thi các hành động không được cho phép như đọc, sửa, hoặc xóa dữ liệu từ cơ sở dữ liệu.

XSS injection (hay còn gọi là Cross-Site Scripting injection) là một dạng khác của injection attack, trong đó kẻ tấn công chèn mã JavaScript độc hại vào các trang web và đưa nó tới người dùng cuối thông qua trình duyệt. Mã độc này có thể được sử dụng để đánh cắp thông tin người dùng, thực hiện hành động đại diện người dùng, hoặc tấn công khác nhau.

Để ngăn chặn injection attack, ứng dụng web cần thực hiện kiểm tra và xử lý đầu vào của người dùng một cách an toàn, sử dụng các biện pháp bảo vệ như sử dụng thủ tục prepared statements hoặc sử dụng bộ lọc đầu vào để loại bỏ hoặc mã hóa các ký tự đặc biệt

Dưới đây là một ví dụ về lỗ hổng Injection trong danh sách OWASP Top 10:

Giả sử bạn đang làm việc trên một ứng dụng web chấm công, nơi nhân viên có thể đăng nhập và gửi thông tin về thời gian làm việc hàng ngày. Ứng dụng này cho phép nhân viên nhập thông tin về giờ vào và giờ ra của họ.

Tuy nhiên, ứng dụng web của bạn không xử lý và kiểm tra đầu vào người dùng một cách đúng đắn. Kẻ tấn công có thể tận dụng điều này để thực hiện cuộc tấn công Injection.

Ví dụ, một kẻ tấn công có thể nhập vào trường thông tin “giờ vào” một đoạn mã SQL độc hại. Nếu ứng dụng không kiểm tra và chặn đúng đắn, mã độc sẽ được thực thi trên cơ sở dữ liệu và kẻ tấn công có thể truy cập, sửa đổi hoặc xóa dữ liệu của người dùng khác hoặc thậm chí kiểm soát toàn bộ hệ thống cơ sở dữ liệu.

Ví dụ khác là tấn công command injection, trong đó kẻ tấn công có thể chèn các lệnh hệ thống nguy hiểm vào trường đầu vào. Nếu ứng dụng không kiểm tra và chặn đúng đắn, các lệnh nguy hiểm này sẽ được thực thi trên máy chủ, cho phép kẻ tấn công thực hiện các hoạt động không đúng đắn hoặc đánh cắp thông tin nhạy cảm.

Trong cả hai trường hợp, lỗ hổng Injection đã cho phép kẻ tấn công chèn và thực thi mã độc, lệnh hệ thống hoặc các truy vấn không mong muốn vào ứng dụng web. Điều này có thể gây ra thiệt hại về an ninh, lợi ích kinh tế hoặc danh tiếng của hệ thống và người dùng.

Để ngăn chặn lỗ hổng Injection, các biện pháp bảo mật sau có thể được áp dụng:

• Sử dụng các phương pháp truy vấn an toàn: Sử dụng các phương pháp truy vấn an toàn như tham số hóa truy vấn, truy vấn chuẩn hóa và sử dụng cơ chế bảo mật bên trong như prepared statements hoặc các ORM (Object-Relational Mapping).
• Kiểm tra và chặn đầu vào người dùng: Kiểm tra và chặn đầu vào người dùng bằng cách xóa hoặc mã hóa các ký tự đặc biệt, biểu thức nguy hiểm và truy vấn không mong muốn. Chặn và hạn chế việc nhập các dữ liệu không đáng tin cậy vào ứng dụng.
• Thiết lập quyền hạn hợp lý: Thiết lập quyền hạn hợp lý trên cơ sở dữ liệu và hệ thống, đảm bảo rằng ứng dụng web chỉ có quyền truy cập và thực thi những hoạt động cần thiết.
• Kiểm tra thâm nhập và kiểm tra bảo mật định kỳ: Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật định kỳ để phát hiện và khắc phục các lỗ hổng Injection trong ứng dụng web. Điều này giúp đảm bảo rằng các biện pháp bảo mật đang hoạt động đúng và không có sự thay đổi không mong muốn trong mã nguồn.

• 2-Broken Authentication

Broken Authentication (Lỗ hổng xác thực không an toàn) là một trong các lỗ hổng trong danh sách OWASP Top 10. Nó thường xảy ra khi các biện pháp xác thực và quản lý phiên không được triển khai chính xác trong một ứng dụng web. Lỗ hổng này có thể cho phép kẻ tấn công chiếm quyền truy cập trái phép vào tài khoản người dùng khác, thực hiện hành động đại diện người dùng, hoặc thậm chí ảnh hưởng đến toàn bộ hệ thống.

Các nguyên nhân và hậu quả của Broken Authentication có thể bao gồm:

1. Quản lý phiên không an toàn: Quá trình quản lý phiên (session) không đủ mạnh mẽ hoặc không được thực hiện đúng cách, dẫn đến việc kẻ tấn công có thể lấy được thông tin phiên xác thực của người dùng và giả mạo hoặc đánh cắp tài khoản của họ.
2. Xác thực yếu: Sử dụng các phương thức xác thực yếu như mật khẩu dễ đoán, mật khẩu quá ngắn hoặc không đủ mạnh, việc không sử dụng các biện pháp bổ sung như hai yếu tố (2FA), hay sử dụng các phương thức xác thực không an toàn khác.
3. Lỗi quản lý tài khoản: Thiếu các biện pháp bảo vệ như khóa tài khoản sau nhiều lần đăng nhập sai, không yêu cầu xác nhận email khi đăng ký tài khoản mới, hoặc cho phép các tài khoản bị vô hiệu hóa truy cập vào hệ thống.

Hậu quả của Broken Authentication có thể rất nghiêm trọng, bao gồm việc truy cập trái phép vào thông tin người dùng, lợi dụng quyền hạn không đúng, đánh cắp thông tin nhạy cảm, hoặc tiến hành các hành động độc hại.

Để ngăn chặn Broken Authentication, các biện pháp bảo mật sau có thể được áp dụng:

• Sử dụng các phương thức xác thực mạnh như mật khẩu dài và mạnh, 2FA, và các phương pháp xác thực bổ sung.
• Đảm bảo rằng quá trình quản lý phiên được thực hiện chính xác và an toàn, bao gồm việc sử dụng mã hóa phiên, sử dụng cookies an toàn, và khóa phiên sau khi đăng xuất.
• Kiểm tra và giám sát các tài khoản, bao gồm việc khóa tài khoản sau nhiều lần đăng nhập sai và cung cấp cơ chế báo cáo hoạt động đáng ngờ.
• Thực hiện kiểm tra thâm nhập và xác minh bảo mật thường xuyên để phát hiện và khắc phục các lỗ hổng trong quá trình xác thực và quản lý phiên.

Dưới đây là một ví dụ về lỗ hổng Broken Authentication trong danh sách OWASP Top 10:

Giả sử bạn là người quản trị một ứng dụng web ngân hàng trực tuyến. Ứng dụng này yêu cầu người dùng đăng nhập bằng tên người dùng và mật khẩu để truy cập vào tài khoản cá nhân và thực hiện các giao dịch tài chính.

Tuy nhiên, trong quá trình phát triển ứng dụng, bạn đã bỏ qua hoặc không thực hiện các biện pháp bảo mật đúng đắn liên quan đến xác thực và quản lý phiên làm việc.

Kẻ tấn công có thể tận dụng lỗ hổng Broken Authentication bằng cách thực hiện các cuộc tấn công như sau:

1. Tấn công Brute Force: Kẻ tấn công sử dụng phương pháp Brute Force để thử tất cả các khả năng tên người dùng và mật khẩu có thể để đăng nhập vào hệ thống. Nếu ứng dụng không thực hiện các biện pháp bảo vệ như chặn sau n lần đăng nhập thất bại hoặc yêu cầu CAPTCHA, kẻ tấn công có thể tìm ra thông tin đăng nhập chính xác và tiếp tục truy cập vào tài khoản người dùng.
2. Tấn công Session Hijacking: Kẻ tấn công có thể ăn cắp thông tin phiên làm việc (session) của người dùng bằng cách đánh cắp hoặc đoán được giá trị session ID. Sau đó, họ có thể sử dụng session ID này để giả mạo và truy cập vào tài khoản của người dùng mà không cần đăng nhập lại.
3. Tấn công Credential Theft: Kẻ tấn công có thể thực hiện các cuộc tấn công phishing hoặc keylogging để lấy cắp thông tin đăng nhập của người dùng. Nếu người dùng sử dụng cùng một tên người dùng và mật khẩu cho nhiều dịch vụ, kẻ tấn công có thể sử dụng thông tin này để đăng nhập vào tài khoản người dùng trên ứng dụng web của bạn.

Trong trường hợp này, lỗ hổng Broken Authentication đã cho phép kẻ tấn công xâm nhập và truy cập vào tài khoản người dùng mà không có các biện pháp bảo mật đúng đắn. Điều này gây nguy hiểm về bảo mật thông tin cá nhân, tiền tệ và dữ liệu quan trọng của người dùng.

Để ngăn chặn lỗ hổng Broken Authentication, các biện pháp bảo mật sau có thể được áp dụng:

• Xác thực và quản lý phiên làm việc: Thực hiện việc xác thực đúng đắn bằng cách sử dụng mã hóa mật khẩu, cấp phát và quản lý phiên làm việc (session) duy nhất cho từng người dùng. Đảm bảo rằng các thông tin xác thực được bảo vệ an toàn và không dễ bị đoán hoặc lấy cắp.
• Chặn tấn công Brute Force: Sử dụng các biện pháp bảo vệ như chặn sau n lần đăng nhập thất bại, yêu cầu CAPTCHA, hoặc tăng thời gian chờ giữa các lần đăng nhập thất bại để ngăn chặn tấn công Brute Force.
• Bảo vệ phiên làm việc (session): Sử dụng các biện pháp bảo vệ như mã hóa phiên làm việc, sử dụng HTTPS cho việc truyền tải phiên làm việc và thiết lập thời gian hết hạn cho phiên làm việc để giới hạn thời gian hiệu lực của phiên.
• Giáo dục người dùng: Tăng cường giáo dục người dùng về các phương pháp tấn công như phishing và giúp họ nhận ra các dấu hiệu của các trang web giả mạo.
• Kiểm tra thâm nhập và kiểm tra bảo mật định kỳ: Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật định kỳ để phát hiện và khắc phục các lỗ hổng liên quan đến xác thực và quản lý phiên làm việc trong ứng dụng web. Điều này giúp đảm bảo rằng hệ thống có các biện pháp bảo mật đúng đắn và không có lỗ hổng Broken Authentication.
• 3 – Sensitive Data Exposure

Sensitive Data Exposure (Lỗi tiếp xúc thông tin nhạy cảm) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi dữ liệu nhạy cảm (như thông tin đăng nhập, thông tin thẻ tín dụng, thông tin cá nhân) không được bảo vệ đúng cách và có thể bị lộ ra bên ngoài. Điều này có thể xảy ra thông qua các phương thức tấn công như tấn công man-in-the-middle, tấn công tìm kiếm dữ liệu và lỗ hổng trong quá trình lưu trữ, truyền tải và xử lý dữ liệu.

Các nguyên nhân và hậu quả của Sensitive Data Exposure có thể bao gồm:

1. Quản lý dữ liệu không an toàn: Dữ liệu nhạy cảm không được mã hóa hoặc mã hóa không đủ mạnh, không sử dụng các giao thức an toàn trong quá trình truyền tải dữ liệu như HTTPS, hoặc lưu trữ dữ liệu nhạy cảm mà không được bảo vệ đủ mạnh.
2. Lỗi phân quyền: Quản lý phân quyền không chính xác hoặc thiếu sót dẫn đến việc người dùng không có quyền truy cập vào dữ liệu nhạy cảm, hoặc người dùng có quyền cao hơn có thể truy cập vào dữ liệu nhạy cảm của người dùng khác.
3. Lỗ hổng phần mềm: Các lỗ hổng trong phần mềm, framework hoặc thư viện mà ứng dụng sử dụng có thể cho phép kẻ tấn công truy cập và lộ dữ liệu nhạy cảm.

Hậu quả của Sensitive Data Exposure có thể làm suy giảm sự tin cậy và uy tín của ứng dụng, gây thiệt hại về danh tiếng và tiềm tàng để bị tấn công giả mạo, lừa đảo hoặc vi phạm quyền riêng tư của người dùng.

Để ngăn chặn Sensitive Data Exposure, các biện pháp bảo mật sau có thể được áp dụng:

• Mã hóa dữ liệu nhạy cảm trong quá trình truyền và lưu trữ, sử dụng các thuật toán mã hóa mạnh và triển khai giao thức bảo mật như HTTPS.
• Áp dụng các biện pháp kiểm soát quyền truy cập đúng đắn và cập nhật phân quyền để đảm bảo chỉ có những người dùng có quyền truy cập mới có thể truy cập vào dữ liệu nhạy cảm.
• Kiểm tra và giám sát các lỗ hổng bảo mật trong phần mềm và các thành phần bên thứ ba được sử dụng trong ứng dụng.
• Tuân thủ các quy tắc và tiêu chuẩn bảo mật, bao gồm việc áp dụng các nguyên tắc an toàn trong quá trình phát triển và triển khai ứng dụng.

Dưới đây là một ví dụ về lỗ hổng Sensitive Data Exposure trong danh sách OWASP Top 10:

Giả sử bạn là quản trị viên một trang web thương mại điện tử nơi người dùng có thể thực hiện giao dịch mua hàng và lưu trữ thông tin cá nhân như tên, địa chỉ, số điện thoại và thông tin thanh toán.

Trang web của bạn lưu trữ thông tin người dùng trong cơ sở dữ liệu, và khi người dùng đăng nhập và thực hiện giao dịch, thông tin thanh toán của họ được truyền qua mạng để xử lý.

Tuy nhiên, bạn đã không triển khai các biện pháp bảo mật đúng đắn để bảo vệ dữ liệu nhạy cảm này. Một kẻ tấn công có thể tận dụng lỗ hổng Sensitive Data Exposure bằng cách thực hiện các hoạt động sau:

1. Tấn công tấn công giữa kết nối (Man-in-the-Middle): Kẻ tấn công có thể giả mạo hoặc nghe trộm giao tiếp giữa trang web của bạn và người dùng. Khi thông tin thanh toán được truyền qua mạng, kẻ tấn công có thể thu thập thông tin nhạy cảm như số thẻ tín dụng và thông tin cá nhân khác.
2. Tấn công SQL Injection: Nếu ứng dụng web của bạn không kiểm tra và chặn đúng đắn đầu vào người dùng, kẻ tấn công có thể chèn các truy vấn SQL độc hại vào các trường đầu vào. Khi thực thi truy vấn này, kẻ tấn công có thể truy cập và lấy cắp dữ liệu nhạy cảm từ cơ sở dữ liệu, bao gồm thông tin người dùng và thông tin thanh toán.
3. Tấn công Cross-Site Scripting (XSS): Kẻ tấn công có thể chèn mã độc JavaScript hoặc HTML vào trang web của bạn. Khi người dùng truy cập vào trang web bị tấn công, mã độc này sẽ được thực thi trong trình duyệt của họ. Kẻ tấn công có thể lợi dụng điều này để đánh cắp thông tin nhạy cảm của người dùng hoặc chuyển hướng họ đến các trang web giả mạo để lừa đảo.

Trong trường hợp này, lỗ hổng Sensitive Data Exposure đã cho phép kẻ tấn công truy cập và đánh cắp thông tin nhạy cảm của người dùng. Điều này có thể dẫn đến việc lộ thông tin cá nhân, lừa đảo tài chính và ảnh hưởng xấu đến danh tiếng và niềm tin của người dùng.

• 4 – XML External Entity

XML External Entity (XXE) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng XXE xảy ra khi ứng dụng web không xác thực và không hạn chế đầu vào XML một cách đúng đắn, cho phép kẻ tấn công chèn và xử lý các thực thể bên ngoài (external entities) trong tài liệu XML. Điều này có thể dẫn đến các cuộc tấn công như đọc file hệ thống, tấn công denial-of-service (DoS), hoặc tiết lộ thông tin nhạy cảm.

Các nguyên nhân và hậu quả của XXE có thể bao gồm:

1. Thiếu kiểm tra đầu vào XML: Thiếu các biện pháp xác thực và hạn chế đầu vào XML nhưng vẫn cho phép xử lý các thực thể bên ngoài, dẫn đến khai thác XXE.
2. Xử lý không an toàn các thực thể bên ngoài: Khi ứng dụng web chấp nhận và xử lý các thực thể bên ngoài mà không áp dụng các biện pháp hạn chế, điều này cho phép kẻ tấn công chèn và thực thi các thực thể gây nguy hiểm.
3. Tấn công DoS: Kẻ tấn công có thể sử dụng XXE để tạo ra các yêu cầu xử lý XML phức tạp hoặc vô hạn, gây ra tình trạng quá tải và làm tê liệt hệ thống (DoS).

Hậu quả của XXE có thể làm rò rỉ thông tin nhạy cảm, gây thiệt hại đến hệ thống, hoặc làm gián đoạn hoạt động của ứng dụng.

Để ngăn chặn XXE, các biện pháp bảo mật sau có thể được áp dụng:

• Tắt hoặc hạn chế việc xử lý thực thể bên ngoài trong quá trình xử lý XML, bằng cách sử dụng cấu hình hoặc thư viện hỗ trợ.
• Áp dụng kiểm tra và xác thực đầu vào XML đúng đắn, bao gồm việc loại bỏ các thực thể bên ngoài không cần thiết và kiểm tra cấu trúc XML hợp lệ.
• Sử dụng các API hoặc thư viện có tích hợp các biện pháp bảo mật XXE, như sử dụng bộ lọc XML an toàn để loại bỏ hoặc thay thế các thực thể bên ngoài.
• Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên để phát hiện và khắc phục các lỗ hổng XXE trong ứng dụng web.

Dưới đây là một ví dụ về lỗ hổng XML External Entity (XXE) trong danh sách OWASP Top 10:

Giả sử bạn là quản trị viên một ứng dụng web cho phép người dùng tải lên và xử lý tập tin XML. Ứng dụng của bạn sử dụng XML để truyền và lưu trữ dữ liệu.

Tuy nhiên, ứng dụng web của bạn không kiểm tra và chặn đầu vào XML từ người dùng một cách đúng đắn. Điều này tạo cơ hội cho kẻ tấn công tận dụng lỗ hổng XML External Entity.

Ví dụ, một kẻ tấn công có thể tải lên một tệp XML độc hại chứa các thực thể bên ngoài. Thực thể bên ngoài có thể là một tệp tin, URL, hoặc dữ liệu từ một nguồn bên ngoài. Khi ứng dụng web xử lý tệp XML này, nó sẽ thực hiện các yêu cầu truy cập tới các thực thể bên ngoài này, mà có thể làm lộ dữ liệu nhạy cảm hoặc tấn công vào hệ thống.

Ví dụ khác là tấn công denial-of-service (DoS), trong đó kẻ tấn công tải lên một tệp XML chứa một thực thể bên ngoài khổng lồ. Khi ứng dụng web xử lý tệp XML này, nó sẽ cố gắng mở và xử lý thực thể này, gây ra tình trạng quá tải và làm ngưng trệ hoặc chậm hệ thống.

Trong cả hai trường hợp, lỗ hổng XML External Entity đã cho phép kẻ tấn công thực hiện các hoạt động không mong muốn như lợi dụng lỗ hổng xác thực bên ngoài, đánh cắp thông tin nhạy cảm, hoặc tấn công từ chối dịch vụ.

• 5-Broken Access Control

Broken Access Control (Lỗi kiểm soát quyền truy cập không an toàn) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi các quy tắc và biện pháp kiểm soát quyền truy cập trong ứng dụng web không được triển khai hoặc xây dựng chính xác. Điều này có thể cho phép kẻ tấn công truy cập, sửa đổi hoặc xóa thông tin hoặc thực hiện các hành động không được phép trong hệ thống.

Các nguyên nhân và hậu quả của Broken Access Control có thể bao gồm:

1. Quản lý phiên không an toàn: Thiếu hoặc không triển khai đúng các biện pháp kiểm soát phiên như session ID không an toàn, quá trình xác thực không đúng, hoặc việc không khóa phiên sau khi đăng xuất dẫn đến việc kẻ tấn công có thể giả mạo phiên của người dùng khác.
2. Thiếu kiểm soát quyền truy cập: Các quy tắc kiểm soát quyền truy cập không chính xác hoặc không được thiết lập đúng cách, cho phép người dùng không có quyền truy cập vào các tài nguyên hoặc chức năng nhất định.
3. Lỗ hổng phân quyền: Việc thiếu sót trong quản lý quyền hạn, bao gồm việc không kiểm tra quyền truy cập đúng đắn trong quá trình xử lý yêu cầu hoặc cho phép người dùng có quyền truy cập cao hơn nên có.

Hậu quả của Broken Access Control có thể làm suy giảm tính bảo mật của ứng dụng, cho phép truy cập trái phép vào thông tin nhạy cảm, thực hiện hành động không được phép và gây ảnh hưởng xấu đến quyền riêng tư và an toàn của người dùng và hệ thống.

Để ngăn chặn Broken Access Control, các biện pháp bảo mật sau có thể được áp dụng:

• Thực hiện kiểm soát quyền truy cập chính xác và hạn chế, đảm bảo rằng chỉ có người dùng được phép mới có thể truy cập vào các tài nguyên và chức năng cần thiết.
• Kiểm tra và xác thực quyền truy cập đúng đắn trong quá trình xử lý yêu cầu, bao gồm việc kiểm tra quyền truy cập và quyền hạn của người dùng trước khi cho phép thực hiện các hành động.
• Sử dụng các cơ chế quản lý phiên an toàn, bao gồm việc sử dụng session ID ngẫu nhiên, bảo vệ phiên truy cập bằng cách mã hóa và khóa phiên sau khi đăng xuất.
• Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên để phát hiện và khắc phục các lỗ hổng trong kiểm soát quyền truy cập của ứng dụng web.

Dưới đây là một ví dụ về lỗ hổng Broken Access Control trong thực tế:

Giả sử bạn là quản trị viên của một ứng dụng web thương mại điện tử. Trong ứng dụng này, người dùng có vai trò khách hàng và nhân viên có vai trò quản lý sản phẩm.

Tuy nhiên, bạn đã không triển khai kiểm soát truy cập đúng đắn giữa hai vai trò này. Như một kết quả, một người dùng khách hàng có thể truy cập vào các chức năng và thông tin chỉ dành cho nhân viên quản lý sản phẩm.

Ví dụ, người dùng khách hàng có thể thay đổi giá sản phẩm, thêm hoặc xóa sản phẩm khỏi cơ sở dữ liệu. Điều này gây ra mất quyền kiểm soát và khả năng xác thực, và người dùng khách hàng có thể gây thiệt hại về tài nguyên và dữ liệu.

Một ví dụ khác là khi người dùng có thể truy cập vào trang quản trị của ứng dụng thông qua một URL cụ thể mà không cần xác thực. Điều này cho phép người dùng không được ủy quyền truy cập và thực hiện các thao tác quản trị, như thay đổi cấu hình hệ thống, tạo tài khoản mới hoặc xóa dữ liệu.

Trong cả hai trường hợp, lỗ hổng Broken Access Control đã cho phép người dùng có quyền truy cập và thực hiện các hoạt động không được ủy quyền trong ứng dụng. Điều này có thể gây ra việc lộ thông tin nhạy cảm, mất quyền kiểm soát và ảnh hưởng xấu đến tính bảo mật và hoạt động của hệ thống.

Để ngăn chặn lỗ hổng Broken Access Control, các biện pháp bảo mật sau có thể được áp dụng:

• Thiết lập kiểm soát truy cập chính xác: Xác định các quyền và vai trò của người dùng trong ứng dụng và thiết lập kiểm soát truy cập dựa trên nguyên tắc của nguyên lý tối thiểu quyền (Principle of Least Privilege). Đảm bảo rằng chỉ những người dùng được ủy quyền mới có thể truy cập và thực hiện các hoạt động nhất định.
• Xác thực và ủy quyền đúng đắn: Thực hiện quy trình xác thực và ủy quyền đúng đắn để đảm bảo rằng người dùng chỉ có quyền truy cập và thực hiện các hoạt động phù hợp với vai trò của họ. Sử dụng các biện pháp bảo mật như mã hóa mật khẩu, xác thực hai yếu tố (2FA), và sử dụng mã thông báo (token) để xác thực và ủy quyền.
• Kiểm tra và chặn đầu vào người dùng: Kiểm tra và chặn đầu vào người dùng để đảm bảo rằng các yêu cầu truy cập và hoạt động của người dùng không vi phạm quyền truy cập và kiểm soát. Kiểm tra xác thực, tham số URL, phân đoạn URL, và các yêu cầu tương tác khác từ người dùng.
• Kiểm tra thâm nhập và kiểm tra bảo mật định kỳ: Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật định kỳ để phát hiện và khắc phục các lỗ hổng Broken Access Control trong ứng dụng web. Điều này giúp đảm bảo rằng hệ thống có các biện pháp bảo mật đúng đắn và không có lỗ hổng Broken Access Control.

• 6-Security Misconfiguration

Security Misconfiguration (Lỗi cấu hình bảo mật) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi cấu hình hệ thống, máy chủ, ứng dụng web hoặc các thành phần khác không được thiết lập hoặc tuân thủ đúng các quy tắc bảo mật. Điều này có thể làm lộ thông tin nhạy cảm, cho phép truy cập trái phép, hoặc gây thiệt hại đến hệ thống.

Các nguyên nhân và hậu quả của Security Misconfiguration có thể bao gồm:

1. Cấu hình mặc định không an toàn: Sử dụng cấu hình mặc định hoặc cấu hình không an toàn cho các hệ thống, máy chủ hoặc ứng dụng web, điều này có thể tạo điểm tấn công dễ bị khai thác cho kẻ tấn công.
2. Thiếu cập nhật và bản vá: Không thực hiện việc cập nhật và bản vá đầy đủ cho hệ điều hành, các phần mềm và thành phần bên thứ ba, dẫn đến việc tồn tại các lỗ hổng bảo mật đã biết.
3. Thiếu việc kiểm tra và giám sát: Thiếu sự kiểm tra, giám sát và kiểm tra bảo mật thường xuyên dẫn đến việc không phát hiện được các lỗ hổng cấu hình và các sự cố bảo mật khác trong quá trình vận hành hệ thống.

Hậu quả của Security Misconfiguration có thể làm giảm tính bảo mật của hệ thống, làm lộ thông tin nhạy cảm, cho phép truy cập trái phép, gây thiệt hại đến danh tiếng và uy tín của tổ chức, hoặc làm suy yếu hoạt động của ứng dụng web.

Để ngăn chặn Security Misconfiguration, các biện pháp bảo mật sau có thể được áp dụng:

• Đảm bảo cấu hình an toàn và tối thiểu cho hệ thống, máy chủ, ứng dụng web và các thành phần khác, bao gồm việc tắt và vô hiệu hóa các tính năng không cần thiết, thiết lập quyền truy cập chính xác và áp dụng các cấu hình bảo mật khắt khe.
• Thực hiện việc cập nhật và bản vá đầy đủ cho hệ điều hành, phần mềm và thành phần bên thứ ba, để khắc phục các lỗ hổng bảo mật đã biết.
• Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên để phát hiện và khắc phục các lỗi cấu hình bảo mật trong hệ thống.
• Thực hiện giám sát và ghi log hoạt động của hệ thống để phát hiện và phản ứng nhanh chóng đối với các sự cố bảo mật và các hoạt động không đúng đắn trong quá trình vận hành.
• Tuân thủ các hướng dẫn và tiêu chuẩn bảo mật: Sử dụng các hướng dẫn và tiêu chuẩn bảo mật được thiết lập, chẳng hạn như các hướng dẫn từ OWASP, các bộ tiêu chuẩn quốc tế như ISO 27001, CIS Benchmarks, để áp dụng các cấu hình bảo mật phù hợp và đảm bảo tuân thủ các quy tắc và nguyên tắc bảo mật.
• Kiểm tra và quản lý các cấu hình: Thực hiện việc kiểm tra cấu hình bảo mật để phát hiện và khắc phục các lỗi cấu hình tiềm ẩn. Sử dụng các công cụ tự động để quét và kiểm tra tính an toàn của cấu hình hệ thống và ứng dụng web, bao gồm cả các tệp cấu hình, tùy chọn máy chủ và cấu hình môi trường.
• Giáo dục và đào tạo nhân viên: Cung cấp đào tạo và giáo dục bảo mật cho nhân viên liên quan đến việc triển khai và quản lý cấu hình hệ thống. Nhân viên nên được hướng dẫn về các quy tắc cấu hình an toàn và được nhắc nhở về tầm quan trọng của việc duy trì cấu hình bảo mật.
• Kiểm tra và giám sát liên tục: Thực hiện kiểm tra bảo mật thường xuyên và theo dõi hệ thống, để đảm bảo rằng cấu hình bảo mật vẫn được duy trì và không có sự thay đổi không đáng tin cậy. Sử dụng các công cụ giám sát hệ thống và log để phát hiện các hoạt động bất thường và các lỗi cấu hình.
• Tự động hóa quy trình triển khai và cấu hình: Sử dụng các công cụ và quy trình tự động hóa để triển khai và cấu hình hệ thống một cách đáng tin cậy và nhất quán. Điều này giảm thiểu nguy cơ lỗi cấu hình do sự can thiệp của con người và đảm bảo tính nhất quán trong các môi trường triển khai.
• Nhớ rằng Security Misconfiguration là một lỗ hổng rất phổ biến và có thể dẫn đến các hậu quả nghiêm trọng cho hệ thống và ứng dụng web. Do đó, việc áp dụng các biện pháp bảo mật và quản lý cấu hình đúng đắn là rất quan trọng để bảo vệ hệ thống khỏi các cuộc tấn công và rủi ro bảo mật.

Dưới đây là một ví dụ về lỗ hổng Security Misconfiguration trong thực tế:

Giả sử bạn là quản trị viên của một ứng dụng web thương mại điện tử. Trang web của bạn chứa thông tin về sản phẩm, đăng ký người dùng và quy trình thanh toán trực tuyến.

Tuy nhiên, bạn đã không cấu hình đúng các cài đặt bảo mật trên ứng dụng web của mình. Dưới đây là một số ví dụ về Security Misconfiguration trong trường hợp này:

1. Sử dụng mặc định cài đặt: Bạn không thay đổi cài đặt mặc định cho nền tảng, máy chủ ứng dụng hoặc cơ sở dữ liệu của bạn. Cài đặt mặc định thường có các giá trị rủi ro, như mật khẩu mặc định, truy cập rộng rãi vào các tệp tin quan trọng, hay thông tin debug được bật.
2. Thiếu cập nhật: Bạn không cập nhật các thành phần và phần mềm của ứng dụng web. Điều này có thể làm lộ các lỗ hổng bảo mật đã được vá trong các phiên bản mới hơn, cho phép kẻ tấn công tìm thấy và khai thác các lỗ hổng này.
3. Quyền hạn chế không chính xác: Bạn không thiết lập quyền hạn chính xác cho người dùng và vai trò trong ứng dụng. Điều này có thể dẫn đến việc người dùng có quyền truy cập và thực hiện các hoạt động không đúng đắn hoặc vi phạm quyền truy cập.
4. Tiết lộ thông tin gỡ lỗi: Bạn không tắt hoặc ẩn thông tin gỡ lỗi trên ứng dụng web, ví dụ như thông báo lỗi cụ thể, stack trace hoặc thông tin hệ thống. Điều này có thể cung cấp thông tin quan trọng cho kẻ tấn công và giúp họ tìm ra các lỗ hổng và khai thác chúng.
5. Không đảm bảo quản lý phiên: Bạn không quản lý phiên đúng đắn, ví dụ như không đảm bảo rằng các phiên làm việc hết hạn sau một khoảng thời gian nhất định hoặc không hủy phiên khi người dùng đăng xuất.

Trong trường hợp này, lỗ hổng Security Misconfiguration đã gây ra rủi ro bảo mật và có thể dẫn đến việc lộ thông tin nhạy cảm, tấn công từ chối dịch vụ (DoS), truy cập trái phép vào các tài nguyên quan trọng hoặc tiềm năng bị khai thác bởi kẻ tấn công.

• 7-Cross-site Scripting

Cross-Site Scripting (XSS) là một trong các lỗ hổng trong danh sách OWASP Top 10. XSS xảy ra khi ứng dụng web không xử lý và không mã hóa đúng đắn đầu vào người dùng, cho phép kẻ tấn công chèn mã độc (script) vào trang web và thực thi nó trên trình duyệt của người dùng khác.

Có ba dạng chính của XSS:

1. Reflected XSS: Dữ liệu người dùng không được lọc và trình bày trực tiếp trên trang web, cho phép mã độc được thực thi khi người dùng truy cập vào các liên kết chứa các tham số bị tấn công.
2. Stored XSS: Dữ liệu người dùng được lưu trữ trên máy chủ và hiển thị cho người dùng khác, cho phép mã độc được thực thi mỗi khi người dùng truy cập trang chứa dữ liệu này.
3. DOM-based XSS: Mã độc tác động trực tiếp đến cây DOM (Document Object Model) của trang web, thay đổi các thành phần và thực thi hành động không mong muốn.

Hậu quả của XSS có thể bao gồm đánh cắp thông tin người dùng, đánh cắp phiên làm việc, lừa đảo người dùng, hoặc đưa ra các cuộc tấn công khác như tấn công CSRF (Cross-Site Request Forgery).

Để ngăn chặn XSS, các biện pháp bảo mật sau có thể được áp dụng:

• Mã hóa và lọc đầu vào: Áp dụng các biện pháp mã hóa và lọc đầu vào để ngăn chặn mã độc được chèn vào trang web. Điều này bao gồm việc xử lý và xóa các ký tự đặc biệt và mã hóa các dữ liệu trước khi trình bày trên trang web.
• Sử dụng bộ lọc đầu ra: Sử dụng bộ lọc đầu ra để xóa hoặc mã hóa các ký tự đặc biệt trong dữ liệu trước khi hiển thị cho người dùng. Điều này giúp ngăn chặn việc thực thi mã độc khi người dùng xem trang web.
• Sử dụng HTTP-only flag cho cookie: Thiết lập cờ HTTP-only cho cookie để ngăn chặn việc truy cập cookie bằng JavaScript, giảm nguy cơ bị đánh cắp phiên làm việc.
• Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên: Thực hiện kiểm tra thâm nhập để phát hiện và khắc phục các lỗ hổng XSS trong ứng dụng web. Kiểm tra bảo mật thường xuyên giúp đảm bảo rằng các biện pháp bảo mật đang hoạt động đúng và không có sự thay đổi không mong muốn trong mã nguồn.

Dưới đây là một ví dụ về lỗ hổng Cross-site Scripting (XSS) trong thực tế:

Giả sử bạn là một người dùng tham gia vào một diễn đàn trực tuyến nơi người dùng có thể chia sẻ và thảo luận về các chủ đề. Diễn đàn này cho phép người dùng đăng bài viết và bình luận trên các bài viết khác.

Tuy nhiên, diễn đàn của bạn không kiểm tra và xử lý đúng các đầu vào người dùng. Điều này tạo cơ hội cho kẻ tấn công tận dụng lỗ hổng Cross-site Scripting.

Ví dụ, một kẻ tấn công có thể đăng một bài viết hoặc bình luận chứa đoạn mã JavaScript độc hại. Khi người dùng khác truy cập vào diễn đàn và xem bài viết hoặc bình luận này, mã JavaScript sẽ được thực thi trong trình duyệt của họ. Điều này cho phép kẻ tấn công thực hiện các hoạt động không mong muốn, như đánh cắp thông tin đăng nhập, chuyển hướng người dùng đến trang web giả mạo hoặc thực hiện các hành động không đúng đắn trên tài khoản người dùng.

Ví dụ khác là tấn công reflected XSS, trong đó kẻ tấn công tạo một đường link độc hại chứa mã JavaScript và gửi nó cho người dùng thông qua email, tin nhắn hoặc các phương tiện truyền thông khác. Khi người dùng nhấp vào liên kết này, mã JavaScript sẽ được thực thi trong trình duyệt của họ, tiềm năng gây hại và đánh cắp thông tin.

Trong cả hai trường hợp, lỗ hổng Cross-site Scripting đã cho phép kẻ tấn công chèn và thực thi mã độc JavaScript trên trang web hoặc trình duyệt của người dùng khác. Điều này có thể gây nguy hiểm về bảo mật, đánh cắp thông tin nhạy cảm và tạo điều kiện cho các cuộc tấn công khác.

• 8-Insecure Deserialization

Insecure Deserialization (Lỗi không an toàn khi thực hiện trình tự hóa) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi ứng dụng web không kiểm tra và xác thực dữ liệu được thực hiện trình tự hóa (serialization) một cách đúng đắn, cho phép kẻ tấn công thực hiện các cuộc tấn công như thực thi mã độc, ghi đè dữ liệu, hoặc thực hiện các hành động không được phép.

Quá trình trình tự hóa là quá trình chuyển đổi dữ liệu thành định dạng có thể được lưu trữ hoặc truyền tải và sau đó chuyển đổi nó trở lại dạng ban đầu khi cần thiết. Tuy nhiên, khi không có các biện pháp bảo mật đúng đắn, quá trình trình tự hóa có thể trở thành điểm tấn công cho kẻ xấu.

Các nguyên nhân và hậu quả của Insecure Deserialization có thể bao gồm:

1. Thiếu kiểm tra dữ liệu: Ứng dụng web không thực hiện kiểm tra và xác thực đầu vào khi thực hiện trình tự hóa và giải trình tự hóa dữ liệu. Điều này có thể dẫn đến việc thực thi mã độc được chèn vào dữ liệu.
2. Sử dụng các thư viện không an toàn: Sử dụng các thư viện hoặc công cụ trình tự hóa không an toàn, có các lỗ hổng bảo mật đã biết hoặc không được cập nhật đúng đắn.

Hậu quả của Insecure Deserialization có thể làm suy giảm tính bảo mật của ứng dụng, cho phép thực thi mã độc, thay đổi dữ liệu, tạo ra cuộc tấn công từ xa và ảnh hưởng xấu đến hệ thống và người dùng.

Để ngăn chặn Insecure Deserialization, các biện pháp bảo mật sau có thể được áp dụng:

• Xác thực và kiểm tra dữ liệu đầu vào: Thực hiện kiểm tra và xác thực đầu vào khi thực hiện quá trình trình tự hóa và giải trình tự hóa. Điều này bao gồm kiểm tra tính hợp lệ của dữ liệu và xác minh rằng dữ liệu không chứa mã độc hoặc dữ liệu bất thường.
• Sử dụng các thư viện và công cụ an toàn: Sử dụng các thư viện và công cụ trình tự hóa an toàn, có cập nhật đầy đủ và không chứa các lỗ hổng bảo mật đã biết.
• Giới hạn quyền hạn: Hạn chế quyền hạn của quá trình trình tự hóa và giải trình tự hóa để đảm bảo chỉ có những người dùng có quyền cần thiết mới có thể truy cập và thực hiện các hoạt động liên quan.
• Giám sát và ghi log: Giám sát hoạt động của quá trình trình tự hóa và ghi log để phát hiện các hoạt động bất thường và các cuộc tấn công tiềm ẩn.
• Kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên: Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật định kỳ để phát hiện và khắc phục các lỗ hổng về Insecure Deserialization trong ứng dụng web.

Sau đây là một ví dụ thực tế về Insecure Deserialization:

Giả sử bạn đang làm việc trên một ứng dụng web thương mại điện tử nơi người dùng có thể đăng nhập và thực hiện các giao dịch mua hàng. Ứng dụng này sử dụng cơ chế trình tự hóa và giải trình tự hóa để lưu trữ các giỏ hàng của người dùng.

Khi người dùng thực hiện thanh toán và đặt hàng, các thông tin về giỏ hàng của họ được trình tự hóa và lưu trữ trong một cookie hoặc một tệp tin trên máy chủ. Khi người dùng tiếp tục mua sắm, ứng dụng web sẽ giải trình tự hóa dữ liệu từ cookie hoặc tệp tin và hiển thị giỏ hàng của họ.

Tuy nhiên, ứng dụng web này không thực hiện kiểm tra và xác thực đầu vào một cách đúng đắn khi trình tự hóa và giải trình tự hóa dữ liệu. Điều này có thể tạo điểm tấn công cho kẻ tấn công.

Một kẻ tấn công có thể thay đổi nội dung của giỏ hàng bằng cách sửa đổi dữ liệu trình tự hóa. Ví dụ, họ có thể thay đổi số lượng và giá của các mặt hàng trong giỏ hàng hoặc thậm chí thay đổi thông tin thanh toán để lừa đảo.

Khi ứng dụng web giải trình tự hóa dữ liệu này và sử dụng nó để xác định giỏ hàng, nó sẽ sử dụng các giá trị bất hợp pháp mà kẻ tấn công đã chèn vào. Điều này dẫn đến việc hiển thị thông tin giỏ hàng không chính xác hoặc thực hiện thanh toán không đúng.

Trong trường hợp này, lỗ hổng Insecure Deserialization đã cho phép kẻ tấn công thay đổi dữ liệu giỏ hàng một cách không hợp pháp và ảnh hưởng đến tính toàn vẹn và độ tin cậy của ứng dụng. Để ngăn chặn lỗ hổng này, ứng dụng web cần thực hiện kiểm tra và xác thực đầu vào đúng đắn khi thực hiện trình tự hóa và giải trình tự hóa dữ liệu.

• 9-Components with Known Vulnerabilities (nay là A06)

Components with Known Vulnerabilities (Các thành phần có lỗ hổng đã biết) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi ứng dụng web sử dụng các thành phần bên thứ ba (như thư viện, framework, module, plugin) có lỗ hổng bảo mật đã biết và không được cập nhật lên phiên bản mới nhất hoặc không được vá lỗi.

Các nguyên nhân và hậu quả của Components with Known Vulnerabilities có thể bao gồm:

1. Không cập nhật thành phần: Thiếu việc cập nhật phiên bản của các thành phần bên thứ ba sử dụng trong ứng dụng web, không kiểm tra và không áp dụng các bản vá bảo mật mới nhất, cho phép các lỗ hổng bảo mật đã biết tiếp tục tồn tại.
2. Sử dụng thành phần không tin cậy: Sử dụng các thành phần bên thứ ba không đáng tin cậy, chẳng hạn từ nguồn không đáng tin hoặc không được đảm bảo bảo mật, có thể làm tăng nguy cơ sử dụng các thành phần có lỗ hổng bảo mật.

Hậu quả của Components with Known Vulnerabilities có thể làm suy giảm tính bảo mật của ứng dụng web và tạo điểm tấn công cho kẻ xấu. Kẻ tấn công có thể tận dụng các lỗ hổng trong các thành phần đã biết để thực hiện cuộc tấn công, bao gồm việc xâm nhập vào hệ thống, thực thi mã độc, đánh cắp thông tin nhạy cảm hoặc gây thiệt hại đến ứng dụng và hệ thống.

Để ngăn chặn Components with Known Vulnerabilities, các biện pháp bảo mật sau có thể được áp dụng:

• Quản lý và kiểm tra thành phần: Đảm bảo rằng tất cả các thành phần bên thứ ba sử dụng trong ứng dụng web được quản lý và kiểm tra. Theo dõi các bản vá bảo mật mới nhất và đảm bảo rằng tất cả các thành phần đều được cập nhật lên phiên bản mới nhất.
• Đánh giá tính tin cậy của thành phần: Kiểm tra tính tin cậy của các thành phần bên thứ ba trước khi sử dụng. Xem xét nguồn gốc, phản hồi từ cộng đồng, đánh giá bảo mật và tiêu chuẩn phát triển của thành phần trước khi quyết định sử dụng.
• Theo dõi và cảnh báo lỗ hổng: Sử dụng các công cụ quản lý lỗ hổng và cảnh báo tự động để theo dõi lỗ hổng bảo mật trong các thành phần bên thứ ba. Điều này giúp phát hiện và khắc phục các lỗ hổng đã biết một cách nhanh chóng.
• Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật thường xuyên: Thực hiện kiểm tra thâm nhập và kiểm tra bảo mật định kỳ để phát hiện và khắc phục các lỗ hổng trong các thành phần sử dụng trong ứng dụng web. Điều này giúp đảm bảo rằng không có thành phần nào có lỗ hổng bảo mật đã biết đang tồn tại trong hệ thống.

Dưới đây là một ví dụ về Components with Known Vulnerabilities trong một ứng dụng web:

Giả sử bạn đang phát triển một trang web thương mại điện tử sử dụng một framework JavaScript phổ biến để xây dựng giao diện người dùng. Framework này được sử dụng để quản lý các thành phần giao diện như menu, nút, biểu đồ và các chức năng tương tác.

Trong quá trình phát triển, bạn đã sử dụng một phiên bản cũ của framework JavaScript mà có một số lỗ hổng bảo mật đã biết. Các lỗ hổng này đã được báo cáo và vá lỗi trong các phiên bản mới hơn của framework.

Tuy nhiên, do quên hoặc không kiểm tra cập nhật, bạn tiếp tục sử dụng phiên bản cũ của framework đó trong ứng dụng web của mình.

Điều này có nghĩa là ứng dụng web của bạn có một thành phần bên thứ ba (framework JavaScript) có lỗ hổng bảo mật đã biết. Kẻ tấn công có thể phân tích và khai thác các lỗ hổng bảo mật này để thực hiện các cuộc tấn công như thực thi mã độc JavaScript, đánh cắp thông tin người dùng, hoặc xâm nhập vào hệ thống.

Trong trường hợp này, lỗ hổng Components with Known Vulnerabilities xảy ra khi phiên bản cũ của framework JavaScript vẫn được sử dụng mà không được cập nhật lên phiên bản mới nhất có các bản vá bảo mật. Điều này tạo điểm yếu trong ứng dụng web và có thể được tận dụng bởi kẻ xấu.

Để ngăn chặn lỗ hổng này, quan trọng để thường xuyên kiểm tra và cập nhật các thành phần bên thứ ba sử dụng trong ứng dụng web, bao gồm việc kiểm tra các bản vá bảo mật mới nhất và áp dụng chúng vào hệ thống.

• 10-Insufficent Logging & Monitoring

Insufficient Logging & Monitoring (Ghi log và giám sát không đủ) là một trong các lỗ hổng trong danh sách OWASP Top 10. Lỗ hổng này xảy ra khi hệ thống ứng dụng web không thực hiện ghi log và giám sát đầy đủ và hiệu quả các hoạt động quan trọng, sự kiện bảo mật và hành vi không mong muốn, điều này gây khó khăn trong việc phát hiện, khắc phục và phản ứng đối với các sự cố bảo mật.

Các nguyên nhân và hậu quả của Insufficient Logging & Monitoring có thể bao gồm:

1. Thiếu ghi log đầy đủ: Ứng dụng web không ghi log đầy đủ các sự kiện, hành động của người dùng và các hoạt động quan trọng khác, bao gồm cả các sự kiện liên quan đến bảo mật như đăng nhập không thành công, truy cập không hợp lệ, thay đổi quyền hạn, và các cuộc tấn công.
2. Thiếu giám sát thời gian thực: Hệ thống không giám sát và phân tích dữ liệu ghi log trong thời gian thực để phát hiện các sự cố bảo mật, hành vi không đúng đắn và các hoạt động không mong muốn. Điều này làm giảm khả năng phản ứng kịp thời và đúng đắn đối với các sự cố bảo mật.

Hậu quả của Insufficient Logging & Monitoring có thể làm giảm khả năng phát hiện sự tấn công, làm tăng thời gian phản ứng và giảm khả năng khắc phục sự cố bảo mật. Nó cũng làm hạn chế khả năng phân tích và đánh giá các hoạt động của hệ thống, làm giảm khả năng phát hiện các mô hình tấn công mới và nâng cao tính bảo mật tổng thể của ứng dụng web.

Để ngăn chặn Insufficient Logging & Monitoring, các biện pháp bảo mật sau có thể được áp dụng:

• Thiết lập chính sách ghi log: Xác định các sự kiện và hoạt động quan trọng cần được ghi log và thiết lập chính sách ghi log phù hợp. Bao gồm việc xác định các sự kiện bảo mật, lỗi hệ thống, truy cập không hợp lệ và các hoạt động quan trọng khác.
• Ghi log đầy đủ: Đảm bảo rằng hệ thống ghi log đầy đủ và chi tiết các sự kiện quan trọng, bao gồm cả các thông tin liên quan đến bảo mật như địa chỉ IP, ngày giờ, hành động, và thông tin người dùng.
• Giám sát thời gian thực: Thiết lập giám sát thời gian thực để theo dõi và phân tích dữ liệu ghi log trong thời gian thực. Sử dụng các công cụ và kỹ thuật phân tích dữ liệu để phát hiện các hoạt động bất thường, cuộc tấn công và sự cố bảo mật.
• Phản ứng và báo cáo: Xây dựng quy trình phản ứng và báo cáo cho việc xử lý các sự cố bảo mật được phát hiện thông qua ghi log và giám sát. Điều này bao gồm việc đảm bảo rằng có cơ chế phản hồi kịp thời và quy trình báo cáo các sự cố bảo mật cho nhóm phát triển và quản lý.

Dưới đây là một ví dụ về Insufficient Logging & Monitoring trong một ứng dụng web:

Giả sử bạn là quản trị viên của một trang web thương mại điện tử. Trang web của bạn cho phép người dùng đăng nhập, thực hiện mua hàng và thực hiện thanh toán. Bạn không thực hiện ghi log và giám sát đầy đủ và hiệu quả các hoạt động quan trọng trên trang web.

Một ngày nọ, một kẻ tấn công tìm ra một lỗ hổng trong quy trình thanh toán của trang web. Họ khai thác lỗ hổng này để thực hiện các giao dịch mua hàng giả mạo và đánh cắp thông tin người dùng. Vì không có hệ thống ghi log đầy đủ và giám sát thích hợp, bạn không nhận ra sự xâm nhập này trong thời gian thực.

Người dùng của trang web bắt đầu nhận ra các giao dịch lạ và tiền trong tài khoản của họ bị rút một cách bất thường. Tuy nhiên, bạn không nhận được cảnh báo hoặc thông báo về sự cố này do thiếu ghi log và giám sát. Mất đi cơ hội phản ứng kịp thời, bạn không thể ngăn chặn tiếp tục việc gian lận và gây thiệt hại cho người dùng và doanh nghiệp của bạn.

Trong trường hợp này, lỗ hổng Insufficient Logging & Monitoring đã cho phép kẻ tấn công thực hiện các hoạt động độc hại mà không bị phát hiện kịp thời. Thiếu ghi log đầy đủ và giám sát thích hợp đã làm giảm khả năng phát hiện, khắc phục và phản ứng đối với sự cố bảo mật, dẫn đến thiệt hại cho người dùng và doanh nghiệp.

Để tránh tình huống tương tự, quan trọng để thiết lập một hệ thống ghi log và giám sát đầy đủ và hiệu quả trong ứng dụng web của bạn. Bạn cần ghi log các sự kiện quan trọng, bao gồm các hoạt động liên quan đến bảo mật và thiết lập giám sát thời gian thực để phát hiện và phản ứng đúng đắn với các sự cố bảo mật.

Qua phần lý thuyết trên, ta có thể xử lý 4 Task đầu của TryhackMe OWASP.

Phần tiếp theo Task 5 hãy xem p2