Việc cung cấp API cho khách hàng sẽ tăng doanh thu của bạn nhưng cũng mở rộng phạm vi tấn công của bạn. Các doanh nghiệp có thể cung cấp API có thể được nhúng vào các ứng dụng của bên thứ ba để giúp việc phát triển dễ dàng hơn. Ví dụ: việc nhúng phương tiện truyền thông xã hội vào một ứng dụng cho phép khách hàng thảo luận về một sản phẩm mà không cần tốn thêm chi phí cho nhóm phát triển của bạn. Công ty truyền thông xã hội đạt được lưu lượng truy cập và khả năng hiển thị, đồng thời khách hàng có thể dễ dàng phát triển trong khi thêm các tính năng vào ứng dụng của họ.
Mặc dù API tốt cho hoạt động tiếp thị và doanh thu, nhưng việc thêm API và điểm cuối sẽ mở rộng bề mặt tấn công của bạn. Việc có API là một rủi ro bổ sung có thể được quản lý nhưng tất cả các điểm cuối phải được giám sát và bảo mật chặt chẽ. Hầu hết các quản trị viên đều đồng ý rằng các API phải được giám sát, nhưng môi trường kinh doanh có nhịp độ nhanh với nhiều bản cập nhật và triển khai có thể dẫn đến việc mất dấu vết của các API và vô tình tạo thêm một rủi ro an ninh mạng được gọi là “API zombie”.
API zombie (về cơ bản) là một cơ sở hạ tầng bị lãng quên và bị bỏ qua, vẫn có sẵn để sử dụng nhưng các tổ chức không biết đến sự tồn tại của nó. API Zombie có thể được tạo trong môi trường nhỏ hoặc lớn, nhưng chúng thường được tạo trong môi trường nơi tài nguyên CNTT được xây dựng mà không có quy trình cung cấp và tài liệu nghiêm ngặt. Kiểm soát thay đổi giúp tránh các tình huống API zombie, nhưng việc triển khai hoặc cấu hình khẩn cấp được thực hiện để khắc phục một lỗi nghiêm trọng cụ thể cũng có thể xảy ra.
Trong môi trường tự động, tài nguyên đám mây thường được triển khai cùng với mã ứng dụng. Lợi ích là các nhà phát triển và người vận hành không còn cần phải nhớ triển khai phần cứng và định cấu hình phần cứng theo cách thủ công nữa. Tự động hóa trong triển khai phần mềm làm giảm sự cố dựa trên cấu hình sai hoặc tránh mọi sự cố mà nhà phát triển quên đưa vào yêu cầu cung cấp tài nguyên để hỗ trợ ứng dụng của họ.
Trong một số môi trường, nhà phát triển được cấp quyền truy cập vào máy chủ thử nghiệm của riêng họ. Những máy chủ này có thể truy cập được trên internet công cộng để các nhà phát triển có thể kiểm tra mã mới. Máy chủ thử nghiệm API có thể có sẵn trên Internet công cộng và các nhà phát triển có thể nghĩ rằng nó sẽ không bị phát hiện nếu không được xuất bản.
API Zombie có thể được tạo theo nhiều cách với các trường hợp đặc biệt của riêng chúng, ngay cả với các quy trình kiểm soát thay đổi nghiêm ngặt nhất. Cho dù chúng xảy ra do nhầm lẫn hay hướng dẫn sai, API zombie vẫn là một dạng
Giống như nhiều cách có thể tạo API zombie dựa trên tình huống, điều tương tự cũng có thể nói đối với việc tìm API zombie. Tin tặc có thể tìm thấy điểm cuối bằng cách đảo ngược mã kỹ thuật, xem xét các kho lưu trữ nguồn mở hoặc thông qua một khái niệm gọi là “fuzzing”. Làm mờ là một kiểu khám phá trong đó các tập lệnh được viết để thực hiện các yêu cầu đối với các tên điểm cuối API phổ biến. Ví dụ: điểm cuối API dùng để xác thực thường có điểm cuối có tên là “/đăng nhập” hoặc “/xác thực” hoặc tên nào đó tương tự. Các yêu cầu được gửi tới các tên điểm cuối phổ biến khác nhau dựa trên cơ sở hạ tầng của bạn để khám phá các điểm cuối.
Việc khám phá từ các kho lưu trữ nguồn mở là điều phổ biến. Các kho lưu trữ nguồn mở cũng dễ bị tiết lộ bí mật, nghĩa là các nhà phát triển có thể quên xóa các tham chiếu đến khóa riêng, thông tin xác thực và dữ liệu riêng tư khác. Các tài liệu tham khảo về điểm cuối API cũng có sẵn để khám phá và sẽ được thăm dò để tìm bất kỳ lỗ hổng nào. Nếu tổ chức của bạn không biết về các điểm cuối được tham chiếu trong mã thì chúng có thể được thăm dò mà không có bất kỳ biện pháp giảm thiểu hoặc giới hạn tốc độ nào.
API zombie không phải lúc nào cũng dễ bị khai thác lỗi. Ví dụ: việc khai thác các lỗ hổng chèn SQL có thể khiến dữ liệu bị tiết lộ thông tin nhạy cảm, nhưng một số điểm cuối được mã hóa chính xác với khả năng phục hồi trước các mối đe dọa. Trong tình huống API zombie, API có thể hoạt động bình thường nhưng có thể được sử dụng để thu thập dữ liệu mà không có bất kỳ hạn chế nào. Có thể điểm cuối có lỗi logic nghiệp vụ có thể bị khai thác nhưng nếu không có sự giám sát thì mọi hoạt động đáng ngờ sẽ không bị phát hiện.
Một ví dụ điển hình về API hoạt động bình thường nhưng được sử dụng để liệt kê dữ liệu một cách lặng lẽ là
Sau khi một nhà nghiên cứu bảo mật phát hiện ra API zombie, JustDial tuyên bố đã khắc phục sự cố, nhưng vấn đề tương tự lại được phát hiện vào năm 2020. Không rõ liệu có bên thứ ba nào ngoài nhà nghiên cứu bảo mật hay không, nhưng vì điểm cuối đã mở cho Internet công cộng với không có giám sát tại chỗ, JustDial không thể đánh giá mức độ rò rỉ dữ liệu.
Một ví dụ khác là với một trong những công ty công nghệ lớn ở San Francisco, được biết đến với một số nhà phát triển giỏi nhất trên thị trường, Facebook. Facebook đã có một số trường hợp API zombie. Năm 2016, các nhà phát triển đã triển khai miền phụ (mbasic.beta.facebook.com) để kiểm tra chức năng đặt lại mật khẩu của họ. Phiên bản sản xuất của API có giới hạn về tốc độ, vì vậy những kẻ tấn công không thể ép buộc mật mã gồm sáu chữ số được gửi cho người dùng để đặt lại mật khẩu của họ. Phiên bản beta không có giới hạn này, do đó, mật mã gồm sáu chữ số có thể bị ép buộc trong vòng vài giây, chỉ bị giới hạn bởi kết nối Internet, băng thông và tốc độ xử lý phụ trợ của điểm cuối API.
Năm 2018, Facebook lại hứng chịu một vụ khác
Một công ty nhỏ hơn—nhưng vi phạm dữ liệu nghiêm trọng từ API zombie—đã xảy ra vào năm 2022 với điểm cuối từ Travis CI. Travis CI là nhà cung cấp tự động hóa được sử dụng để triển khai cơ sở hạ tầng và mã. Một trong những điểm cuối API của Travis CI không yêu cầu xác thực và cho phép yêu cầu lấy sự kiện trong nhật ký khách hàng. Tệ hơn nữa, nhật ký được lưu trữ dưới dạng văn bản gốc, do đó dữ liệu nhật ký người dùng, bao gồm cả khóa truy cập, có thể được truy xuất mà không có bất kỳ hạn chế nào. Khi sự cố được báo cáo, Travis CI ước tính rằng 770 triệu bản ghi nhật ký người dùng, bao gồm mã thông báo truy cập, khóa và thông tin đăng nhập trên đám mây, đã bị đánh cắp.
Lý tưởng nhất là các nhà phát triển phần mềm ghi lại các thay đổi đối với cơ sở hạ tầng để kiểm soát thay đổi bao gồm các điểm cuối API mới. Sau đó, những người vận hành có thể thêm điểm cuối vào các tác nhân giám sát và các tác nhân này sẽ thu thập dữ liệu để các giám sát viên phân tích và an ninh mạng có thể cho quản trị viên biết khi phát hiện thấy hoạt động đáng ngờ. API zombie xảy ra khi điểm cuối không được ghi lại, vì vậy các tác nhân giám sát không biết về điểm cuối. Nếu không có sự giám sát, mọi yêu cầu có thể được gửi đến máy chủ mà không có bất kỳ phân tích và cảnh báo nào của quản trị viên.
Để đối phó với các API zombie tiềm ẩn, quản trị viên thường sẽ cài đặt các tác nhân trên mạng để phát hiện lưu lượng truy cập. Đại lý thu thập dữ liệu lưu lượng truy cập và phát hiện các kết nối mở trên máy chủ và cơ sở hạ tầng mạng khác. Vấn đề với chiến lược này là các API zombie thường không hoạt động mà không có lưu lượng truy cập hoặc yêu cầu nào cho đến khi chúng được phát hiện. Chúng có thể được phát hiện bởi các nhà phát triển, nhà điều hành hoặc bên thứ ba trên internet. Chỉ sau khi bên thứ ba tìm thấy điểm cuối thì lưu lượng truy cập mới được ghi lại, nhưng điều đó không có nghĩa là các yêu cầu sẽ kích hoạt cảnh báo. API zombie sẽ cho phép thực hiện các yêu cầu tiêu chuẩn mà không có bất kỳ truy vấn “hack” hoặc không đúng định dạng nào. Đó là lý do khiến API zombie trở nên nguy hiểm trong việc tiết lộ dữ liệu.
Thay vì dựa vào các tác nhân để phát hiện API zombie một cách phản ứng, giải pháp tốt hơn là làm việc với trí tuệ nhân tạo và quét mã của bạn. Chiến lược này có hai giai đoạn: quét mã kho lưu trữ của bạn để tham khảo các API nội bộ và sử dụng nhật ký sự kiện để xác định xem API có nhận được bất kỳ yêu cầu nào không.
Bước đầu tiên là quét mã để tham khảo API. Các API này có thể là bên ngoài hoặc bên trong, nhưng bạn muốn tập trung vào các API nội bộ vì cơ sở hạ tầng này ảnh hưởng đến dữ liệu của chính bạn. Các tài liệu tham khảo có thể có trong nhiều kho lưu trữ, cả đang hoạt động và không được dùng nữa. Bạn thậm chí có thể không biết rằng các tham chiếu có trong mã của mình, nhưng việc quét nó sẽ phát hiện ra chúng để có thể gửi danh sách đến trí tuệ nhân tạo (AI).
Tiếp theo là mô hình ngôn ngữ lớn (LLM) được sử dụng để nhập và phân tích nhật ký sự kiện. Nhật ký sự kiện có thể có dung lượng hàng gigabyte hoặc terabyte dữ liệu theo từng dòng. Nhật ký sự kiện rất quan trọng đối với an ninh mạng và giám sát việc sử dụng cơ sở hạ tầng, vì vậy, chúng nên được thiết lập cho các máy chủ lưu trữ API. Nếu điểm cuối API được tham chiếu trong mã nhưng có ít hoặc không có sự kiện lưu lượng truy cập thì bạn có thể có API zombie. Các API có tham chiếu và nhiều nhật ký sự kiện đang được sử dụng và giám sát để chúng không bị coi là API zombie.
Việc sử dụng LLM để xử lý phân tích trên mọi tham chiếu điểm cuối API cần có thời gian nhưng kết quả có thể khiến quản trị viên không biết về các API đang hoạt động trong môi trường của họ. Như một ví dụ, một
Câu trả lời là “Có!” API Zombie có thể để lộ dữ liệu khách hàng, dữ liệu nội bộ hoặc thông tin quan trọng khác của bạn. Trong một môi trường tuân thủ, việc giám sát này có thể khiến bạn phải trả hàng triệu USD tiền phạt. Kiện tụng, thiệt hại thương hiệu, ảnh hưởng đến doanh thu và một số hậu quả tiêu cực khác có liên quan đến cơ sở hạ tầng không được giám sát dẫn đến vi phạm dữ liệu.
Việc có được tầm nhìn tốt hơn về môi trường của tổ chức là rất quan trọng đối với an ninh mạng và ứng phó sự cố nhanh hơn. Khi ngày càng có nhiều tổ chức triển khai cơ sở hạ tầng trên đám mây, điều quan trọng hơn bao giờ hết là đảm bảo rằng bạn không gặp bất kỳ trở ngại nào, bao gồm cả API zombie. Ghi lại cơ sở hạ tầng của bạn là bước đầu tiên tuyệt vời, nhưng có thể một số API sẽ bỏ sót. Quét mã của bạn liên tục giúp xác định các API zombie, sau đó có thể bị vô hiệu hóa hoặc thêm vào các tác nhân giám sát. Khả năng hiển thị tốt hơn về cơ sở hạ tầng của bạn giúp giảm nguy cơ lộ dữ liệu nhạy cảm và giảm bề mặt tấn công của bạn.