Zodinet

Top 10 lỗ hổng bảo mật API phổ biến và cách khắc phục

1. API và tầm quan trọng của API

API là gì?

API (Application Programming Interface) là một tập hợp các định nghĩa và giao thức mà các chương trình máy tính có thể sử dụng để giao tiếp và tương tác với nhau. Nó cho phép các nhà phát triển truy cập các chức năng, dịch vụ hoặc dữ liệu của một ứng dụng, dịch vụ hoặc hệ thống mà không cần biết chi tiết về cách chúng được triển khai. API có thể được sử dụng để tích hợp các ứng dụng với nhau, truy cập dữ liệu từ các dịch vụ web, hoặc tạo ra các ứng dụng khách hàng sử dụng các dịch vụ từ xa.

Tầm quan trọng của việc bảo mật API

Bảo mật API là một trong những nhiệm vụ quan trọng hàng đầu đối với những nhà phát triển sản phẩm vì những lý do sau:

  • Bảo vệ dữ liệu nhạy cảm
  • Ngăn chặn truy cập trái phép
  • Bảo vệ chống lại tấn công DDoS
  • Đảm bảo tính toàn vẹn và xác thực dữ liệu
  • Tuân thủ các quy định pháp lý

2. Top 10 lỗ hổng API phổ biến

Dưới đây là 10 lỗ hổng bảo mật API phổ biết được thống kê trong năm 2023 bởi OWASP – một tổ chức phi lợi nhuận chuyên cung cấp các tài nguyên và công cụ nhằm nâng cao nhận thức về an ninh mạng và bảo mật phần mềm cho các nhà phát triển, quản trị viên hệ thống, lập trình viên…

Broken Object Level Authorization

BOLA xảy ra khi kiểm soát truy cập tới các đối tượng (object) trong ứng dụng không được thực hiện chính xác hoặc không đủ bảo mật, tạo điều kiện cho phép kẻ tấn công khai thác các điểm cuối API dễ bị phá vỡ uỷ quyền bằng cách thao túng ID của đối tượng được gửi trong yêu cầu. Điều này có thể dẫn đến việc tiết lộ dữ liệu cho các bên trái phép, mất dữ liệu hoặc thao túng dữ liệu. Trong một số trường hợp nhất định, việc truy cập trái phép vào các đối tượng cũng có thể dẫn đến việc chiếm đoạt toàn bộ tài khoản.

Mức độ phổ biến: cao. Sự cố này cực kỳ phổ biến trong các ứng dụng dựa trên API vì thành phần máy chủ thường không theo dõi đầy đủ trạng thái của máy khách mà thay vào đó dựa nhiều hơn vào các tham số như ID đối tượng được gửi từ máy khách để quyết định đối tượng nào sẽ truy cập.

Giải pháp ngăn chặn lỗ hổng BOLA:

  • Áp dụng kiểm soát truy cập chính xác và đủ bảo mật cho từng đối tượng trong ứng dụng
  • Xác nhận quyền truy cập của người dùng và kiểm tra tính hợp lệ của các yêu cầu thay đổi dữ liệu.
  • Ưu tiên sử dụng các giá trị ngẫu nhiên và không thể đoán trước làm GUID cho ID của bản ghi.

Broken Authentication

Xảy ra khi các biện pháp xác thực và quản lý phiên (session management) không được triển khai đúng cách. Cho phép kẻ tấn công vượt qua quá trình xác thực và truy cập trái phép vào các tài khoản người dùng, đọc dữ liệu cá nhân của họ và thay mặt họ thực hiện các hành động nhạy cảm. Các hệ thống khó có thể phân biệt hành động của kẻ tấn công với hành động của người dùng hợp pháp.

Một API sẽ dễ bị tấn công nếu:

  • Cho phép người dùng sử dụng mật khẩu với mức độ bảo mật yếu
  • Cho phép người dùng thay đổi địa chỉ email, mật khẩu hiện tại hoặc thực hiện bất kỳ thao tác nhạy cảm nào khác mà không yêu cầu xác nhận mật khẩu.
  • Gửi chi tiết xác thực nhạy cảm, chẳng hạn như mã thông báo xác thực và mật khẩu trong URL.
  • Chấp nhận mã thông báo JWT chưa được ký/được ký yếu ({"alg":"none"})
  • Không xác thực ngày hết hạn JWT.
  • Cho phép kẻ tấn công hoạt động trái phép trên cùng một tài khoản người dùng mà không cần đưa ra cơ chế khóa tài khoản/captcha.
  • Không được giám sát hoạt động của phiên đăng nhập để phát hiện các hoạt động bất thường hoặc đăng nhập từ các vị trí địa lý không thường xuyên.

Một hạ tầng microservices sẽ dễ bị tấn công nếu:

  • Các vi dịch vụ khác có thể truy cập nó mà không cần xác thực
  • Sử dụng mã thông báo yếu hoặc có thể dự đoán được để thực thi xác thực

Broken Object Property Level Authorization

BOPA xảy ra khi kiểm soát truy cập tới các thuộc tính (property) của đối tượng trong ứng dụng không được thực hiện đúng cách hoặc không đủ bảo mật. Cho phép kẻ tấn công thực hiện các hành động không được ủy quyền trên các thuộc tính của một đối tượng trong ứng dụng. Điều này có thể dẫn đến việc truy cập, sửa đổi hoặc xóa các thuộc tính mà kẻ tấn công không được phép.

Giải pháp ngăn chặn lỗ hổng BOPA:

  • Khi hiển thị một đối tượng bằng điểm cuối API, hãy luôn đảm bảo rằng người dùng phải có quyền truy cập vào các thuộc tính của đối tượng mà bạn hiển thị.
  • Tránh sử dụng các phương pháp chung chung như to_json()và to_string(). Thay vào đó, hãy chọn các thuộc tính đối tượng cụ thể mà bạn muốn trả về.
  • Nếu có thể, hãy tránh sử dụng các chức năng tự động liên kết đầu vào của máy khách thành các biến mã, đối tượng bên trong hoặc thuộc tính đối tượng (“Gán hàng loạt”).
  • Chỉ cho phép thay đổi các thuộc tính của đối tượng cần được khách hàng cập nhật.
  • Giữ cấu trúc dữ liệu được trả về ở mức tối thiểu, theo yêu cầu nghiệp vụ/chức năng cho điểm cuối.

Unrestricted Resource Consumption

Là loại lỗ hổng cho phép kẻ tấn công có thể tiêu thụ các tài nguyên hệ thống (như băng thông, bộ nhớ hoặc CPU) một cách không kiểm soát. Việc này có thể dẫn đến DoS do cạn kiệt tài nguyên, cũng có thể dẫn đến tăng chi phí vận hành như những chi phí liên quan đến cơ sở hạ tầng do nhu cầu CPU cao hơn, tăng nhu cầu lưu trữ đám mây, v.v.

Lỗ hổng này thường xuất hiện khi không có giới hạn hoặc giới hạn không đúng được đặt cho các hoạt động liên quan đến tài nguyên. Ví dụ, một ứng dụng web có thể cho phép người dùng tải lên tệp tin mà không kiểm soát dung lượng hoặc số lượng tệp tin, dẫn đến việc tiêu tốn quá nhiều lưu lượng mạng hoặc bộ nhớ.

Để ngăn chặn lỗ hổng này, các nhà phát triển cần phải:

  • Triển khai giới hạn về tần suất khách hàng có thể tương tác với API trong khung thời gian xác định (giới hạn tốc độ).
  • Sử dụng giải pháp giúp dễ dàng giới hạn bộ nhớ , CPU , số lần khởi động lại , bộ mô tả tệp và các quy trình như Bộ chứa/Mã không có máy chủ
  • Xác định và thực thi kích thước dữ liệu tối đa trên tất cả các tham số và tải trọng đến, chẳng hạn như độ dài tối đa cho chuỗi, số phần tử tối đa trong mảng và kích thước tệp tải lên tối đa (bất kể nó được lưu trữ cục bộ hay trong bộ nhớ đám mây).
  • Giới hạn tần suất một ứng dụng người dùng API có thể thực hiện một thao tác

Broken Function Level Authorization

Broken Function Level Authorization (BFLA) xảy ra khi kiểm soát truy cập đến các chức năng (function) của ứng dụng không được thực hiện đúng cách hoặc không đủ bảo mật.

Khi xảy ra lỗ hổng BFLA, kẻ tấn công có thể truy cập, thực hiện hoặc thay đổi các chức năng của ứng dụng mà không có quyền truy cập hoặc ủy quyền. Điều này có thể cho phép kẻ tấn công thực hiện các hành động không hợp lệ hoặc lợi dụng các tính năng quản lý hoặc quyền truy cập đặc biệt mà không được phép.

Giải pháp để ngăn chặn lỗ hổng BFLA, các nhà phát triển cần kiểm tra và xác nhận quyền truy cập cho mỗi chức năng của ứng dụng, áp dụng kiểm soát truy cập chính xác và đủ bảo mật, và kiểm tra tính hợp lệ của các yêu cầu thực hiện chức năng. Đồng thời, việc kiểm tra và giám sát các hoạt động không hợp lệ hoặc thực hiện chức năng không đúng cũng là một phần quan trọng trong việc ngăn chặn lỗ hổng BFLA.

Unrestricted Access to Sensitive Business Flows

Unrestricted Access to Sensitive Business Flows (UASBF) là một lỗ hổng bảo mật trong các ứng dụng doanh nghiệp. Nó xảy ra khi người dùng có quyền truy cập không kiểm soát hoặc không đủ bảo mật đến các quy trình kinh doanh nhạy cảm.

Khi UASBF xảy ra, kẻ tấn công có thể truy cập và thực hiện các hoạt động không ủy quyền trong các quy trình kinh doanh quan trọng, như quản lý tài khoản, thanh toán, đặt hàng, hay xử lý thông tin nhạy cảm khác. Điều này có thể dẫn đến việc tiết lộ thông tin quan trọng, gian lận, hoặc ảnh hưởng tiêu cực đến hoạt động kinh doanh và uy tín của tổ chức.

Để ngăn chặn lỗ hổng UASBF, các nhà phát triển và quản trị viên hệ thống cần thiết lập và kiểm tra các chính sách kiểm soát truy cập chặt chẽ, áp dụng quản lý quyền truy cập phù hợp, và giám sát các hoạt động người dùng để phát hiện và ngăn chặn các truy cập không ủy quyền vào các quy trình kinh doanh nhạy cảm. Đồng thời, việc đảm bảo tính bảo mật và quyền riêng tư của dữ liệu cũng là một yếu tố quan trọng trong việc ngăn chặn lỗ hổng UASBF.

Server-Side Request Forgery

Lỗi giả mạo yêu cầu phía máy chủ (SSRF) có thể xảy ra khi API đang tìm nạp tài nguyên từ xa mà không xác thực URI do người dùng cung cấp. Điều này cho phép kẻ tấn công lạm dụng API để gửi các yêu cầu tới hệ thống, ngay cả khi hệ thống được bảo vệ bởi tường lửa hoặc VPN.

Khi SSRF xảy ra, kẻ tấn công có thể gửi các yêu cầu từ máy chủ đến các địa chỉ IP, cổng và tài nguyên mà họ chọn, bao gồm cả hệ thống nội bộ, máy chủ ngoại tuyến hoặc các dịch vụ khác. Điều này có thể dẫn đến việc tiết lộ thông tin nhạy cảm, tấn công từ chối dịch vụ (DoS), hoặc khai thác các lỗ hổng khác trên hệ thống nội bộ.

Vậy làm thế nào để ngăn chặn lỗi trên?

  • Cô lập cơ chế tìm nạp tài nguyên trong mạng của bạn: thông thường các tính năng này nhằm mục đích truy xuất tài nguyên từ xa chứ không phải tài nguyên nội bộ.
  • Bất cứ khi nào có thể, hãy sử dụng danh sách cho phép:
    • Người dùng từ xa phải tải xuống tài nguyên từ (ví dụ: Google Drive, Gravatar, v.v.)
    • Lược đồ URL và cổng
    • Các loại phương tiện được chấp nhận cho một chức năng nhất định
  • Vô hiệu hóa chuyển hướng HTTP.
  • Sử dụng trình phân tích cú pháp URL được kiểm tra và duy trì tốt để tránh các vấn đề do sự không nhất quán trong phân tích cú pháp URL.
  • Xác thực tất cả dữ liệu đầu vào do khách hàng cung cấp.
  • Không gửi phản hồi thô cho khách hàng.

Security Misconfiguration

Xảy ra khi cấu hình hệ thống, máy chủ, ứng dụng hoặc các thành phần bảo mật không được thiết lập hoặc cấu hình chính xác, dẫn đến các thiết lập không an toàn và kẽ hở để hacker có thể tấn công vào hệ thống.

Cấu hình sai về bảo mật không chỉ làm lộ dữ liệu nhạy cảm của người dùng mà còn cả chi tiết hệ thống có thể dẫn đến xâm phạm toàn bộ máy chủ.

Để ngăn chặn lỗ hổng Security Misconfiguration, các nhà phát triển và quản trị viên hệ thống cần thiết lập và tuân thủ các hướng dẫn bảo mật, áp dụng các cấu hình an toàn cho tất cả các thành phần, cập nhật và vá các phần mềm và hệ thống thường xuyên, kiểm tra tính hợp lệ của các cấu hình và thiết lập môi trường chạy, và thực hiện quản lý bảo mật chặt chẽ cho hệ thống và ứng dụng

Improper Inventory Management

Improper Inventory Management (lưu trữ API không đúng) là một lỗ hổng trong quá trình quản lý và kiểm soát các endpoint API. Nó xảy ra khi quy trình lưu trữ API không được thực hiện đúng cách hoặc không đủ bảo mật, dẫn đến sự mất mát, lãng phí và tiềm ẩn rủi ro tài chính cho tổ chức.

Một API có “điểm mù tài liệu” nếu như:

    • Mục đích của máy chủ API không rõ ràng và không có câu trả lời rõ ràng cho các câu hỏi sau
      • API đang chạy trong môi trường nào (ví dụ: sản xuất, chạy thử, thử nghiệm, phát triển)?
      • Ai nên có quyền truy cập mạng vào API (ví dụ: công khai, nội bộ, đối tác)?
      • Phiên bản API nào đang chạy?
    • Không có tài liệu hoặc tài liệu hiện có không được cập nhật.
    • Không có kế hoạch ngừng hoạt động cho từng phiên bản API.
    • Kho lưu trữ của máy chủ bị thiếu hoặc lỗi thời.

Một API có “điểm mù luồng dữ liệu” nếu như:

Có một “luồng dữ liệu nhạy cảm” trong đó API chia sẻ dữ liệu nhạy cảm với bên thứ ba và

    • Không có sự biện minh kinh doanh hoặc sự chấp thuận của dòng chảy
    • Không có hàng tồn kho hoặc khả năng hiển thị của luồng
    • Không có khả năng hiển thị sâu về loại dữ liệu nhạy cảm nào được chia sẻ

Unsafe Consumption of APIs

Unsafe Consumption of APIs (việc sử dụng API không an toàn) là một lỗ hổng bảo mật trong việc sử dụng các giao diện lập trình ứng dụng (APIs). Nó xảy ra khi ứng dụng không kiểm soát hoặc không đảm bảo an toàn khi giao tiếp và sử dụng các API.

API có thể dễ bị tấn công nếu:

  • Tương tác với các API khác qua kênh không được mã hóa;
  • Không xác thực và vệ sinh đúng cách dữ liệu được thu thập từ các API khác trước khi xử lý hoặc chuyển dữ liệu đó đến các thành phần xuôi dòng;
  • Đi theo các chuyển hướng một cách mù quáng;
  • Không giới hạn số lượng tài nguyên có sẵn để xử lý phản hồi dịch vụ của bên thứ ba;
  • Không triển khai thời gian chờ cho các tương tác với dịch vụ của bên thứ ba;

Cách ngăn chặn lỗi Unsafe Consumption of APIs:

  • Khi đánh giá các nhà cung cấp dịch vụ, hãy đánh giá tình hình bảo mật API của họ.
  • Đảm bảo tất cả các tương tác API diễn ra qua kênh liên lạc an toàn (TLS).
  • Luôn xác thực và vệ sinh đúng cách dữ liệu nhận được từ các API tích hợp trước khi sử dụng.
  • Duy trì danh sách cho phép gồm các API tích hợp ở các vị trí nổi tiếng có thể chuyển hướng API của bạn đến: không mù quáng đi theo các chuyển hướng.

Bảo mật API là yếu tố then chốt trong việc bảo vệ dữ liệu và duy trì sự tin cậy của hệ thống. Nhận diện và khắc phục các lỗ hổng bảo mật phổ biến là bước quan trọng để ngăn chặn rủi ro. Áp dụng các biện pháp bảo mật hiện đại, thường xuyên kiểm tra, cập nhật và tuân thủ các quy định pháp lý giúp bảo vệ hệ thống trước các cuộc tấn công tiềm ẩn. Đầu tư vào bảo mật API không chỉ bảo vệ dữ liệu mà còn xây dựng một môi trường trực tuyến an toàn và đáng tin cậy.

Exit mobile version