10

API Security Weekly: Sự cố số 49

Tin tức bảo mật API

Tuần này, chúng tôi sẽ kiểm tra chi tiết về hai lỗ hổng API tại Uber và Get, nền tảng bảo mật API 42Crunch được cập nhật và tầm nhìn của Red Hat về tương lai của quản lý API.

Bạn cũng có thể thích: REST API Security

Lỗ hổng bảo mật: Uber

Anand Prakash đã tìm ra cách để tiếp quản toàn bộ tài khoản trên Uber thông qua một lỗ hổng trong API của họ. Cách tiếp cận tương tự cũng hoạt động với các tài khoản cho bất kỳ dịch vụ nào của Uber, bao gồm cả tài xế và Uber Eats:

  1. Thực hiện addDrivercuộc gọi không hợp lệ (bao gồm số điện thoại hoặc địa chỉ email của người dùng.) Điều này làm cho API rò rỉ UUID của người dùng được đề cập trong thông báo lỗi trả về. Bạn thậm chí có thể tạo một tập lệnh lặp lại các cuộc gọi để lấy UUID cho nhiều người dùng Uber.
  2. Thực hiện getConsentScreenDetailscuộc gọi với UUID bạn có. Cuộc gọi này làm rò rỉ tất cả thông tin người dùng cho UUID đã cho, bao gồm cả mã xác thực ứng dụng dành cho thiết bị di động. Bây giờ bạn có những gì nó cần để tiếp quản hoàn toàn tài khoản.

Rất may, Uber đã nhanh chóng khắc phục sự cố này sau khi nó được họ chú ý.

Bài học rút ra với cái này:

  • Đảm bảo rằng các lỗi không bao giờ làm rò rỉ bất kỳ thông tin nhạy cảm nào và xác định các đầu ra API của bạn bao gồm cả lỗi một cách cẩn thận.
  • Không có lệnh gọi API nào chưa được xác thực sẽ cung cấp bất kỳ thông tin nhạy cảm nào .
  • Không có cuộc gọi chưa được xác thực nào nên cung cấp mã thông báo xác thực!

Lỗ hổng: Nhận

Get (trước đây là Qnect) là một ứng dụng phổ biến cho các hội và câu lạc bộ đại học. Nó hoạt động ở bốn quốc gia, có 159 nghìn người dùng đang hoạt động và 453 câu lạc bộ.

Một sinh viên Úc đã phát hiện ra rằng API đằng sau ứng dụng Get không được bảo vệ . Tệ hơn nữa, API đã cấp quyền truy cập không giới hạn cho tất cả người dùng và thông tin cá nhân của họ, chẳng hạn như tên, email, số điện thoại, ngày sinh và ID Facebook.

Nếu bạn là nhà phát triển ứng dụng, hãy nhớ rằng các API của bạn không chỉ là một chi tiết triển khai! Mọi người sẽ cố gắng tìm ra cách gọi họ trực tiếp:

  • Tất cả các API phải được bảo vệ.
  • Các API không nên cung cấp cho khách hàng nhiều dữ liệu hơn những gì khách hàng cần.

Công cụ: Nền tảng 42Crunch

42Crunch đã tung ra bản cập nhật cho nền tảng bảo mật API của họ .

Tính năng mới lớn nhất là API Firewall hiện cũng cung cấp chế độ không chặn. Chế độ này cho phép bạn chạy cấu hình bảo vệ cho API của mình dưới dạng chỉ đọc. API Firewall vẫn phát hiện và ghi lại tất cả các lệnh gọi tới API vi phạm hợp đồng API nhưng không chặn các cuộc gọi. Điều này giúp bạn đánh giá tác động của lưu lượng truy cập API hiện tại mà không ảnh hưởng đến người tiêu dùng API của bạn.

Ngoài ra, công cụ dành cho nhà phát triển trong nền tảng này cũng có các cải tiến, chẳng hạn như tích hợp được cải thiện giữa Kiểm tra bảo mật hợp đồng API và Trình chỉnh sửa bảo mật cũng như các cải tiến về UX đối với báo cáo kiểm toán.

Ý kiến: Tương lai của quản lý API

SD Times đã đăng một cuộc phỏng vấn với David Codelli (3Scale / Red Hat) về quan điểm của anh ấy về tương lai của quản lý API. Dưới đây là tóm tắt nhanh về các điểm chính:

  1. Các lưới dịch vụ khiến các nhà cung cấp quản lý API phải suy nghĩ lại về những gì họ muốn bảo mật và khi nào.
  2. Quản lý API cần chuyển sang mã (giống như cơ sở hạ tầng đã làm với Kubernetes).
  3. Khi thiết kế bảo mật API, các API nội bộ cần được quan tâm và chú ý như các API công khai.

Bạn có thể đăng ký nhận bản tin này tại  APIsecurity.io .

Đọc thêm

Cách bảo mật API

Bảo mật API (Sách điện tử miễn phí)

|