Top 10 lỗ hổng bảo mật theo OWASP

Open Web Application Security Project (OWASP) là một tổ chức bao gồm các chuyên gia bảo mật hàng đầu thế giới, chuyên cung cấp các thông tin về những ứng dụng và rủi ro đặt ra một cách trực tiếp, khách quan và thực tế nhất. Từ năm 2013 đến nay, cứ 4 năm 1 lần, OWASP lại công bố danh sách Top 10 các rủi ro bảo mật ứng dụng lớn nhất, được gọi là OWASP Top 10.

Danh sách này được coi là chuẩn AppSec và được cộng đồng an ninh mạng tin tưởng. Danh sách bao gồm thông tin mới nhất về các lỗ hổng, các mối đe dọa và cuộc tấn công cũng như những thủ thuật để phát hiện và khắc phục. Các thành viên dự án lập ra danh sách này dựa trên việc phân tích tỉ lệ xuất hiện và mức độ nghiêm trọng của từng mối đe dọa.

OWASP Top 10 năm 2017 được phát hành công khai, dựa trên cuộc thăm dò, kiểm tra hơn 2,3 triệu lỗ hổng tác động đến 50000 ứng dụng, bao gồm 2 bản cập nhật lỗ hổng quy mô lớn và cập nhật các kịch bản tấn công mới.

Và sau đây là danh sách Top 10 của năm 2017.

Lổ hổng Injection (Lỗi chèn mã độc)

Lỗ hổng Injection xảy ra do sự thiếu sót trong việc lọc các dữ liệu đầu vào không đáng tin cậy. Khi bạn truyền các dữ liệu chưa được lọc tới Database (Ví dụ như trên SQL), tới trình duyệt (lỗ hổng XSS), tới máy chủ LDAP (lỗ hổng LDAP Injection) hoặc tới bất cứ vị trí nào khác. Vấn đề là kẻ tấn công có thể chèn các đoạn mã độc để gây ra lộ lọt dữ liệu và chiếm quyền kiểm soát trình duyệt của khách hàng.

Mọi thông tin mà ứng dụng của bạn nhận được đều phải được lọc theo Whitelist. Bởi nếu bạn sử dụng Blacklist việc lọc thông tin sẽ rất dễ bị vượt qua (Bypass). Tính năng Pattern matching sẽ không hoạt động nếu thiết lập Blacklist.

Có dễ bị lỗi chèn mã độc hay không?

Một ứng dụng Web sẽ có thể là nạn nhân của Injection nếu:

  • Dữ liệu cung cấp từ người dùng được gửi lên tuỳ ý, không được kiểm tra tính hợp lệ, không qua bộ lọc hay được “dọn dẹp” trước
  • Sử dụng các câu truy vấn động, trong đó dữ liệu người dùng cấp được kết nối với mã gốc để tạo câu query hoàn chỉnh, thực thi trực tiếp mà không có cơ chế kiểm soát, xử lý
  • Cách ngăn chặn lỗ hổng:

Để chống lại lỗ hổng này chỉ “đơn giản” là vấn đề bạn đã lọc đầu vào đúng cách chưa hay việc bạn cân nhắc  liệu một đầu vào có thể được tin cậy hay không. Về căn bản, tất cả các đầu vào đều phải được lọc và kiểm tra trừ trường hợp đầu vào đó chắc chắn đáng tin cậy.(Tuy nhiên việc cẩn thận kiểm tra tất cả các đầu vào là luôn luôn cần thiết).

Ví dụ, trong một hệ thống với 1000 đầu vào, lọc thành công 999 đầu vào là không đủ vì điều này vẫn để lại một phần giống như “gót chân Asin”, có thể phá hoại hệ thống của bạn bất cứ lúc nào. Bạn có thể cho rằng đưa kết quả truy vấn SQL vào truy vấn khác là một ý tưởng hay vì cơ sở dữ liệu là đáng tin cậy. Nhưng thật không may vì đầu vào có thể gián tiếp đến từ những kẻ có ý đồ xấu. Đây được gọi là lỗi Second Order SQL Injection.

Việc lọc dữ liệu khá khó vì thế các bạn nên sử dụng các chức năng lọc có sẵn trong framework của mình. Các tính năng này đã được chứng minh sẽ thực hiện việc kiểm tra một cách kỹ lưỡng. Bạn nên cân nhắc sử dụng các framework vì đây là một trong các cách hiệu quả để bảo vệ máy chủ của bạn.

injection

Broken Authentication

Nguy cơ đối mặt với lỗ hổng:

  • Một ứng dụng Web sẽ có thể là nạn nhân nếu: Ứng dụng cho phép hacker tiến hành các cuộc tấn công vét cạn Brute Force hoặc các kiểu tấn công tự động khác.
  • Các bạn có thể hiểu đơn giản là ứng dụng Web của chúng ta cho phép request liên tục nhiều API từ cùng một IP hoặc cố gắng truy cập vào một tài khoản nhiều lần mà không có cơ chế quản lý ví dụ như lock tài khoản đó nếu xuất hiện những hành vi như vậy
  • Cho phép người dùng đặt các mật khẩu yếu, không đạt tiêu chuẩn. Không có cơ chế bắt buộc thay đổi mật khẩu mặc định chẳng hạn “Password1” hay “admin/admin”
  • Cơ chế khôi phục mật khẩu (trường hợp người dùng quên mật khẩu) yếu hoặc không an toàn, chẳng hạn cơ chế trả lời câu hỏi mà bạn hay thấy nếu sử dụng Yahoo từ 7-8 năm trước, đây thực sự là một giải pháp rất tệ ở thời điểm hiện tại
  • Lưu trữ Password dạng Plaintext (bản rõ) mà không mã hoá, hoặc sử dụng những thuật toán mã hoá hay các mã băm đơn giản, dễ dàng bị crack
  • Thiếu hoặc cơ chế xác thực 2 lớp không hiệu quả
  • Hiển thị trực tiếp Session IDs hoặc các thông số quan trọng trong Params của URL
  • Không có cơ chế luân phiên thay đổi Session IDs sau khi đăng nhập thành công
  • Việc cài đặt thời gian tồn tại của Session IDs không đúng
  • Cách ngăn chặn lỗ hổng:

Cách đơn giản nhất để tránh lỗ hổng bảo mật web này là sử dụng một framework. Trong trường hợp bạn muốn tự tạo ra bộ xác thực hoặc mã hóa cho riêng mình, hãy nghĩ đến những rủi ro mà bạn sẽ gặp phải và tự cân nhắc kĩ trước khi thực hiện.

Broken Authentication

Lỗ hổng XSS (Cross Site Scripting)

Lỗ hổng XSS (Cross-scite Scripting) là một lỗ hổng rất phổ biến. Kẻ tấn công chèn các đoạn mã JavaScript vào ứng dụng web. Khi đầu vào này không được lọc, chúng sẽ được thực thi mã độc trên trình duyệt của người dùng. Kẻ tấn công có thể lấy được cookie của người dùng trên hệ thông hoặc lừa người dùng đến các trang web độc hại.

Nguy cơ đối mặt với lỗ hổng:

  • Ứng dụng của chúng ta trao đổi thông tin dưới dạng bản rõ (Plain text)
  • Sử dụng các thuật toán mã hoá quá cũ và không còn an toàn ở thời điểm hiện tại (Chẳng hạn 1 số hệ mật rất phổ biến trong quá khứ như DES nhưng đến nay đã không còn an toàn)
  • Cơ chế sinh khoá yếu, không đủ an toàn. Việc lựa chọn kích thước khoá cũng như thuật toán sinh phù hợp là điều vô cùng quan trọng
  • Ứng dụng phía người dùng không xác thực các chứng chỉ khi trao đổi thông tin với Server
  • Cách ngăn chặn lỗ hổng:
  • Xác định mức độ nhạy cảm của các thông tin được lưu trữ dựa theo tính chất hệ thống, luật pháp. Từ đó lựa chọn cơ chế kiểm soát phù hợp cho từng mức độ
  • Lọc và loại bỏ những thông tin nhạy cảm không cần thiết, hạn chế rủi ro mất mát có thể xảy ra
  • Đảm bảo sử dụng những thuật toán mã hoá, sinh khoá tiêu chuẩn, an toàn ở thời điểm hiện tại
  • Không lưu những thông tin nhạy cảm tại Cache

Broken Access Control

Khi người dùng bị hạn chế kiểm soát truy cập, tin tặc có thể khai thác và truy cập các chức năng hoặc dữ liệu trái phép. Kiểm soát truy cập nhằm mục đích kiểm soát người dùng được ủy quyền được phép hay không được phép làm gì trong một ứng dụng và để thiết lập quyền kiểm soát truy cập một cách hợp lí, ứng dụng phải đảm bảo rằng nó đang nghiêm túc thực hiện kiểm tra ủy quyền và xác thực hợp lệ để xác định người dùng được đặc quyền, thực tế là những người dùng Internet ngẫu nhiên.

 Nguyên nhân lỗi kiểm soát truy cập xảy ra có thể là do các nhà phát triển thường bị bế tắc trong việc kiểm soát truy cập phù hợp với các quy tắc đặt ra. A5 – Security Misconfiguration (Sai sót cấu hình an ninh)

 Do cấu hình an ninh lỏng lẻo tại các tầng kiến trúc của web như nền tảng, framework, máy chủ, cơ sở dữ liệu và mã tùy chỉnh nên tin tặc có thể khai thác tấn công và có quyền truy cập dữ liệu. Vì thế, tất cả các tầng kiến trúc của web phải được cập nhật thường xuyên

Broken Access Control

Sensitive Data Exposure (Rò rỉ dữ liệu)

Lỗ hổng này thuộc về khía cạnh crypto và tài nguyên. Dữ liệu nhạy cảm phải được mã hóa mọi lúc, bao gồm cả khi gửi đi và khi lưu trữ – không được phép có ngoại lệ. Thông tin thẻ tín dụng và mật khẩu người dùng không bao giờ được gửi đi hoặc được lưu trữ không được mã hóa. Rõ ràng thuật toán mã hóa và hashing không phải là một cách bảo mật yếu. Ngoài ra, các tiêu chuẩn an ninh web đề nghị sử dụng AES (256 bit trở lên) và RSA (2048 bit trở lên).

Cần phải nói rằng các Session ID và dữ liệu nhạy cảm không nên được truyền trong các URL và cookie nhạy cảm nên có cờ an toàn.

Cách ngăn chặn lỗ hổng:

  • Sử dụng HTTPS có chứng chỉ phù hợp và PFS (Perfect Forward Secrecy). Không nhận bất cứ thông tin gì trên các kết nối không phải là HTTPS. Có cờ an toàn trên cookie.
  • Bạn cần hạn chế các dữ liệu nhạy cảm có khả năng bị lộ của mình. Nếu bạn không cần những dữ liệu nhạy cảm này, hãy hủy nó. Dữ liệu bạn không có không thể bị đánh cắp.
  • Không bao giờ lưu trữ thông tin thẻ tín dụng, nếu không muốn phải đối phó với việc tuân thủ PCI. Hãy đăng ký một bộ xử lý thanh toán như Stripe hoặc Braintree.
  • Nếu bạn có dữ liệu nhạy cảm mà bạn thực sự cần, lưu trữ mã hóa nó và đảm bảo rằng tất cả các mật khẩu được sử dụng hàm Hash để bảo vệ. Đối với Hash, nên sử dụng bcrypt. Nếu bạn không sử dụng mã hoá bcrypt, hãy tìm hiểu về mã Salt để ngăn ngừa rainbow table attack.

XML External Entities (XXE)

XML External Entities ( còn được gọi là XXE) là lỗ hổng bảo mật cho phép kẻ tấn công can thiệp vào quá trình xử lý dữ liệu XML của ứng dụng. Nó thường cho phép kẻ tấn công xem các tệp trên hệ thống tệp của máy chủ ứng dụng và tương tác với bất kỳ hệ thống back-end hoặc bên ngoài thứ ba nào mà ứng dụng có thể truy cập được.

Trong một số tình huống, kẻ tấn công có thể leo thang cuộc tấn công XXE để xâm nhập máy chủ bên dưới hoặc cơ sở hạ tầng phụ trợ khác, bằng cách tận dụng lỗ hổng XXE để thực hiện các cuộc tấn công giả mạo yêu cầu phía máy chủ (SSRF).

Security Misconfiguration

Trong thực tế, máy chủ website và các ứng dụng đa số bị cấu hình sai. Có lẽ do một vài sai sót như:

  • Chạy ứng dụng khi chế độ debug được bật.
  • Directory listing
  • Sử dụng phần mềm lỗi thời (WordPress plugin, PhpMyAdmin cũ)
  • Cài đặt các dịch vụ không cần thiết.
  • Không thay đổi default keyhoặc mật khẩu
  • Trả về lỗi xử lý thông tin cho kẻ tấn công lợi dụng để tấn công, chẳng hạn như stack traces.

Cách ngăn chặn lỗ hổng:

Có một quá trình “xây dựng và triển khai” tốt (tốt nhất là tự động). Cần một quá trình audit các chính xác bảo mật trên máy chủ trước khi triển khai.

Insecure Deserialization

Deserialization là quá trình khôi phục luồng bytes này thành một bản sao đầy đủ chức năng của đối tượng ban đầu, ở trạng thái chính xác khi nó được tuần tự hoá. Sau đó, logic của web có thể tương tác với đối tượng này, giống như bất kỳ đối tượng nào khác.

Serialization (tuần tự hoá) là quá trình chuyển đổi các cấu trúc dữ liệu phức tạp, chẳng hạn như các đối tượng và trường của chúng, thành một định dạng “phẳng hơn” có thể được gửi và nhận dưới dạng một dòng byte tuần tự. Việc sắp xếp thứ tự dữ liệu nằm mục đích:

  • Ghi dữ liệu phức tạp vào bộ nhớ liên quá trình, tệp hoặc cơ sở dữ liệu.
  • Gửi dữ liệu phức tạp, chẳng hạn như qua mạng, giữa các thành phần khác nhau của ứng dụng hoặc trong lệnh gọi API.

Điều quan trọng, khi tuần tự hóa một đối tượng, trạng thái của nó cũng được duy trì. Nói cách khác, các thuộc tính của đối tượng được giữ nguyên, cùng với các giá trị được chỉ định của chúng.

Using Components with Known Vulnerabilities (Sử dụng các thành phần có lỗ hổng đã biết)

Đây là vấn đề xảy ra khi sử dụng các bộ thư viện đã tồn tại lỗ hổng. Trước khi tích hợp một mã nguồn mới vào website, hãy thực hiện một số nghiên cứu hoặc kiểm tra bảo mật. Sử dụng mã nguồn mà bạn nhận được từ một người ngẫu nhiên trên GitHub hoặc một số diễn đàn có thể rất thuận tiện. Nhưng hãy sẵn sàng trước nguy cơ đối diện với một lỗ hổng bảo mật web nghiêm trọng.

Ví dụ: Nhiều trường hợp, trang admin bị lộ không phải vì các lập trình viên sai sót, mà vì phần mềm của bên thứ ba vẫn chưa được cập nhật. Nếu bạn nghĩ rằng họ sẽ không tìm thấy cài đặt phpmyadmin ẩn của bạn, hãy tìm hiểu về dirbuster.

Cách ngăn chặn lỗ hổng:

Chú ý cẩn thận khi sử dụng các thành phần của bên thứ 3, không nên là một coder copy-paste. Kiểm tra cẩn thận các đoạn code quan trọng của bạn. Nếu các đoạn code này có lỗ hổng, tin tặc có thể đọc cơ sở dữ liệu, tệp tin cấu hình, mật khẩu… của bạn.

Cập nhật mọi thứ: Đảm bảo bạn đang sử dụng phiên bản mới nhất của tất cả mọi thứ và có kế hoạch cập nhật chúng thường xuyên. Ít nhất là đăng ký bản tin về các lỗ hổng bảo mật mới liên quan đến sản phẩm.

Insufficient Logging & Monitoring (Ghi nhật ký và giám sát không đầy đủ)

Khi một tổ chức không có đủ khả năng ghi nhật ký, phát hiện, giám sát và phản hồi, những kẻ tấn công sẽ dựa vào những điểm yếu này để đạt được mục tiêu của chúng mà không bị phát hiện. Việc thiếu các phương pháp này bao gồm những điều như:

  • Các sự kiện có thể kiểm tra, chẳng hạn như đăng nhập, đăng nhập không thành công và giao dịch giá trị cao không được ghi lại.
  • Cảnh báo và lỗi tạo ra thông báo nhật ký không đầy đủ hoặc không rõ ràng.
  • Nhật ký của các ứng dụng và API không được giám sát hoạt động đáng ngờ.
  • Nhật ký chỉ được lưu trữ cục bộ.
  • Các ngưỡng cảnh báo thích hợp và quy trình báo cáo phản hồi không đúng vị trí hoặc không hiệu quả.
  • Kiểm tra thâm nhập và quét bằng các công cụ DAST không kích hoạt cảnh báo.
  • Các ứng dụng không thể phát hiện, báo cáo hoặc cảnh báo về các cuộc tấn công đang hoạt động trong thời gian thực hoặc gần thời gian thực.

Kết luận

Lỗ hổng bảo mật trong website là một điều hay gặp phải nhất, nhất là đối với các lập trình viên ít kinh nghiệm. Để có thể ngăn chặn được các lỗi này đòi hỏi phải có sự thống nhất trong việc lập trình. Chúng tôi sẽ viết bài viết mới nhất để nhằm tránh cách lỗi lập trình này.

Xem thêm hướng dẫn testing owasp

Quý khách có thể tham khảo hơn ở các dịch vụ do websitehcm.com cung cấp như: dịch vụ seo, dịch vụ viết content , dịch vụ chăm sóc website, thiết kế web giá rẻ

Leave a Reply