Tản mạn về API security
Trong môi trường web, việc giao tiếp giữa client và server đa phần được thực hiện thông qua giao tiếp API. Theo số liệu, năm 2023, có khoảng hơn 70% các giao tiếp client-server sử dụng API.
Do số lượng phổ biến nên việc việc bảo đảm các API được bảo vệ là một vấn đề quan trọng. Tuy nhiên trong quá trình triển khai các lớp phòng thủ có một số vấn đề khó khăn mà ta phải đối mặt, bài viết này cùng bàn một góc nhìn nhỏ về những khó khăn đó: quản lý API trong hệ thống, từ đó có thể tìm các giải pháp giải quyết vấn đề.
API là gì
APIs (application programming interfaces) hoạt động bằng cách sử dụng các quy tắc và giao thức được xác định trước để truyền đạt yêu cầu của người dùng giữa hai hệ thống riêng biệt.
Có rất nhiều loại API khác nhau, về mục đích, ta có thể tóm lược chia thành một số loại nhất định:
- Public API: đây là những API được sử dụng rộng rãi dùng để giao tiếp giữa client và server để xử lý các tác vụ. Ở đây có thể là các API được gọi từ app hoặc từ các admin portal.
- Private/Internal API: những api được sử dụng cho các tác vụ nội bộ, thường là giữa các service gọi với nhau.(cron job)
- Partner API: đây là những API sử dụng cho đối tác.
- Composite API: đây là những API phục vụ cho nhiều mục đích, bao gồm tất cả các loại API ở trên.
Bài toán
“Chúng ta không thể bảo vệ thứ mà chúng ta không nhìn thấy”
Đối với đội ngũ làm security, một trong những công việc đầu tiên là xây dựng các lớp quản lý API. Tuy nhiên, việc thu thập và quản lý các API trong hệ thống sẽ gặp một số vấn đề khó khăn sau:
- Các lỗi bảo mật trên các endpoint: các lỗi bảo mật theo API top 10 OWASP
- Thu thập, quản lý các API trong hệ thống
- Endpoint ẩn trong hệ thống (đã loại bỏ, undocumented)
- Sự đồng bộ giữa các môi trường Hãy cùng ngồi lại và suy nghĩ về từng vấn đề một.
SỰ ĐA DẠNG VỀ CÁC PHƯƠNG PHÁP TẤN CÔNG
Đặt vấn đề:
Cho dù ở dạng nào API, web hay mobile app, các lỗi bảo mật luôn là mối quan tâm hàng đầu đối các nhà làm bảo mật. Đối với việc kiểm thử API, chúng ta có thể follow theo tiêu chuẩn Top 10 OWASP for API đối với những lỗ hổng phổ biến nhất.
Nhờ vào việc có nhiều tài liệu về secure coding style và sự nâng cao kiến thức về bảo mật, các lỗi liên quan về code cổ điển như: SQLi, Command Injection,… đã dần dần bị thay thế bởi các lỗi liên quan đến xác thực, phân quyền, secure design,… nhưng không đồng nghĩa với việc đã hạn chế được các phương thức tấn công. Các kỹ thuật tấn công hiện nay ngày càng sáng tạo và tinh vi hơn, đòi hỏi những người làm phòng thủ nhạy và phản ứng với các phương thức tấn công này.
Hướng giải quyết:
Thực hiện quy trình phát triển phần mềm an toàn SSDLC(Secure Software Development Life Cycle), nhiều công ty đã áp dụng một số biện pháp để giảm thiểu vấn đề về security: security design review, code review(SAST), DAST … vấn đề về bảo mật đã được giải quyết từ trước khi ra môi trường production(shift-left security). Một tin khá vui là hiện tại vấn đề security đã trở nên phổ biến không còn lạ lẫm với với dev, devops nữa.
Một rắc rối khác là làm sao xác định API nào thuộc team nào, đơn giản nhất là xem commit code, một phương pháp có thể thực hiện khác là thiết lập quy trình on-call về người chịu trách nhiệm về security của từng service. Phần này là một phần nhỏ trong quy trình Security Incident Response. Mục đích cuối cùng là phản ứng nhanh nhất khi có một sự số hoặc một lỗi bảo mật xảy ra trên API.
QUẢN LÝ API CỦA HỆ THỐNG
Đặt vấn đề:
Hệ thống của bạn có quản lý được các API của hệ thống? Có hoặc không? CÓ nếu bạn có sử dụng các công cụ, phần mềm để quản lý, document lại các API trong hệ thống. KHÔNG, làm sao bạn dám chắc là hệ thống của bạn quản lý được tất cả các API trong hệ thống.
Một câu chuyện không chỉ riêng ai, nhất là ở các anh em làm công ty product, một ngày nào đó bạn sẽ được báo cáo về một lỗ hổng bảo mật từ một API từ trên trời rơi xuống, bạn thậm chí còn chưa bao giờ được nhìn thấy nó.
Các nguồn thông tin API có thể đến từ một file javascript, Github hoặc trong mã nguồn của ứng dụng mobile,… được nằm rải rác trên internet. Rất nhiều các vụ tấn công API có liên quan đến các API cũ không còn được sử dụng, các API test.
Hướng giải quyết:
Câu hỏi nghiêm túc được đặt ra là bằng cách nào chúng ta không ở thế bị động, có thể thu thập và quản lý được các API trong hệ thống. Một số nguồn tài liệu mà chúng ta có thể tham khảo là từ các tài liệu kỹ thuật hoặc thực tế nhất là dựa theo mã nguồn ứng dụng.
Có thể sử dụng các phương pháp:
- API document (ex: swagger) làm một phương thức để quản lý các API trong hệ thống.
- Một số sản phẩm enterprise hoặc opensource có hỗ trợ về quản lý các API trong hệ thống(https://apidog.com/blog/api-managementg-tools/)
Ý tưởng lớn là sẽ dựng một proxy để hứng tất cả traffic đi qua môi trường staging, từ đây công cụ sẽ collect và monitor các API trong hệ thống đang được gọi.
Tuy nhiên cách này có một nhược điểm là những API cũ hoặc các API không sử dụng sẽ không thể quản lý, như vậy, cần phải kết hợp giữa các biện pháp thủ công và tự động để đảm bảo hiệu quả cao nhất.
Document, document và document: trong quy trình, hầu như tất cả các endpoint đều được định nghĩa và được đề cập trong các tài liệu kỹ thuật. Đây là một cách quan trọng giúp các dev, pentester, tester có thể hiểu rõ về các luồng trong hệ thống.
Trong tài liệu kỹ thuật và quy trình cũng nên đề cập đến vấn đề thêm, thay thế, loại bỏ các API, điều này giúp quản lý tốt hơn các API trong hệ thống.
BẢO VỆ QUÁ TRÌNH TRAO ĐỔI DỮ LIỆU GIỮA CLIENT VÀ SERVER
Đặt vấn đề:
Ngoài nhu cầu về việc đảm bảo các API không chứa các lỗi bảo mật, một số công ty còn áp dụng việc ẩn đi các API giao tiếp giữa client và server, nhằm kéo dài thời gian kẻ tấn công tìm được endpoint thật sự.
Hướng giải quyết:
Một số biện pháp được áp dụng như: obfuscate code, white box crypto, client server encryption. Ý tưởng của các giải pháp này là áp dụng mật mã học vào các mã nguồn ở client, làm cho logic chương trình trở nên khó hiểu và khó để dịch ngược trở lại chương trình gốc.
Tuy nhiên, một điểm cần phải cân nhắc đến yếu tố hài hòa giữa bảo mật và hiệu năng của ứng dụng, vì các ứng dụng này sẽ làm giảm hiệu năng của ứng dụng.
DEFINE AND ACCESS MANAGEMENT RULE
Phần này đề cập đến quy trình SSDLC, các tổ chức cần phân loại các loại API và quy ước về cách đặt tên. Ví dụ đặt tên theo mục đích sử dụng:
- /admin: các API chỉ dùng cho các hệ thống portal quản lý.
- /internal: các API chỉ dùng cho việc gọi giữa các service lẫn nhau(nội bộ)
- /partner: API phục vụ cho việc liên kết với hệ thống của đối tác.
Việc đặt tên sẽ giúp dễ dàng thiết lập các rule cho WAF, Server Gateway hoặc đội ngũ security dễ dàng hơn trong việc bảo vệ API.
SỰ ĐỒNG BỘ GIỮA CÁC MÔI TRƯỜNG
Đặt vấn đề:
Để đưa một sản phẩm ra môi trường gồm các nhiều giai đoạn, sẽ có rất nhiều branch và môi trường: dev, staging, production. Một yêu cầu quan trọng là phải có sự đồng bộ giữa các môi trường. Thông thường, quá trình security test chỉ diễn ra ở môi trường staging, do để giảm thiểu nhất những ảnh hưởng đến môi trường production. Hãy thử tưởng tượng, trong trường hợp bản vá bảo mật mà đội ngũ security báo cáo chỉ được khắc phục ở staging nhưng lại không được deploy ở production. Một câu hỏi được đặt ra là cá nhân, team nào sẽ chịu trách nhiệm cho việc đảm bảo cho sản phẩm ở các môi trường là đồng nhất nhau
Hướng giải quyết:
Mấu chốt của vấn đề này nằm ở quy trình phát triển phần mềm của từng doanh nghiệp, một số gợi ý cho bạn:
- Kiểm soát phiên bản phần mềm (Software Version Control): sử dụng các công cụ để đóng gói và quản lý các phiên bản phần mềm.
- Tự động hóa quá trình triển khai: Xây dựng pipeline triển khai để đảm bảo rằng mã nguồn được kiểm tra, xây dựng và triển khai một cách tự động và nhất quán trên các môi trường.
- Dùng hệ thống quản lý cấu hình (Configuration Management):đảm bảo rằng cấu hình của các môi trường (như cấu hình cơ sở dữ liệu, cấu hình ứng dụng) được duy trì một cách nhất quán và được tự động hóa.
Luận
Quy chung lại, việc bảo vệ các API trong hệ thống không đến từ việc chỉ chăm chăm vào các lỗi bảo mật, bảo mật là sự kết hợp giữa các phương pháp bảo mật: xây dựng chính sách bảo mật, thực thi chính sách, ….
Bảo mật là một quá trình, cần thực hiện một cách liên tục và thương xuyên chứ không phải chỉ dừng một giai đoạn nào. Với những sự chia sẻ ở trên, sẽ hữu ích cho bạn trong việc định hình chiến lược bảo vệ các API trong hệ thống.
CHÚC MỪNG NĂM MỚI 2024
Một số tài liệu bạn có thể tham khảo:
All rights reserved
