Tôi chắc chắn rằng hầu hết tất cả các bạn sẽ biết về OWASP. Tuy nhiên, đối với bối cảnh, hãy để tôi chỉ ngắn gọn về điều tương tự.
OWASP là một tổ chức phi lợi nhuận quốc tế chuyên về bảo mật ứng dụng web. Đây là một nỗ lực hoàn toàn dựa trên nguồn mở và cộng đồng để chia sẻ các bài báo, phương pháp luận, tài liệu, công cụ và công nghệ trong lĩnh vực bảo mật ứng dụng web.
Khi chúng ta nói về API, hầu như chúng ta đều nói về REST và OWASP có một dự án dành riêng cho bảo mật API. Vì loạt bài viết này tập trung vào bảo mật API, chúng tôi sẽ không đi vào chi tiết về bảo mật ứng dụng web. Bạn có thể sử dụng các liên kết được cung cấp để tìm thêm về những điều này. Hãy để chúng tôi dành thời gian tìm hiểu về nền tảng, trước khi đi sâu vào dự án bảo mật API.
Lý lịch
Dự án được thừa nhận rộng rãi nhất của OWASP là OWASP top 10. Đây là danh sách các rủi ro bảo mật được tổng hợp bởi các chuyên gia bảo mật trên toàn thế giới. Báo cáo này được cập nhật liên tục, nêu ra những mối quan tâm về bảo mật ứng dụng web và đặc biệt tập trung vào Top 10 những rủi ro nghiêm trọng nhất. Theo OWASP, báo cáo này là một “Top 10 của OWASP là một tài liệu nhận thức tiêu chuẩn dành cho các nhà phát triển và bảo mật ứng dụng web. Nó thể hiện sự đồng thuận rộng rãi về các rủi ro bảo mật quan trọng nhất đối với các ứng dụng web.” Họ khuyến nghị tất cả các công ty kết hợp báo cáo vào các quy trình của họ để giảm thiểu và / hoặc giảm thiểu rủi ro bảo mật. Phiên bản mới nhất đã được xuất bản vào năm 2017 và dưới đây là danh sách.
- Mũi tiêm
- Xác thực bị hỏng
- Phơi nhiễm dữ liệu nhạy cảm
- Các thực thể vĩnh cửu XML (hoặc XXE)
- Kiểm soát truy cập bị hỏng
- Cấu hình sai bảo mật
- Cross-Site Scripting (hoặc XSS)
- Hủy đăng ký không an toàn
- Sử dụng các thành phần với các lỗ hổng đã biết
- Ghi nhật ký và giám sát không đầy đủ
Bảo mật API khác với bảo mật ứng dụng web như thế nào
Mặc dù API có nhiều điểm tương đồng với các ứng dụng web, nhưng về cơ bản cả hai đều khác nhau về bản chất.
Trong các ứng dụng web, tất cả quá trình xử lý được thực hiện trên máy chủ và trang web kết quả được gửi trở lại trình duyệt web để hiển thị. Do tính chất này, chúng có điểm vào hạn chế và bề mặt tấn công là kết quả của các trang web. Điều này có thể dễ dàng được bảo vệ bằng cách đặt tường lửa ứng dụng web (WAF) trước máy chủ ứng dụng.
Trong hầu hết các ứng dụng hiện đại, chính giao diện người dùng sử dụng API để gửi và nhận dữ liệu từ các máy chủ phụ trợ và cung cấp chức năng của ứng dụng. Khách hàng có trách nhiệm thực hiện kết xuất và chuyển đổi các phản hồi thành một trang web.
Ngoài ra, với sự gia tăng của kiến trúc microservices, các thành phần riêng lẻ trở thành API và nó trở thành một thế giới hoàn toàn khác, nơi các khách hàng giao diện người dùng có thể tương tác với hàng trăm dịch vụ thông qua các lệnh gọi API. Điều này làm tăng đáng kể bề mặt tấn công. Bây giờ tất cả các API đó trở thành điểm vào và bề mặt tấn công.
Không thể bảo vệ các điểm vào này bằng các giải pháp WAF vì chúng không thể phân biệt giữa các lệnh gọi API hợp pháp và độc hại.
Tại sao lại có một dự án riêng biệt về bảo mật API?
Kể từ lần phát hành đầu tiên vào năm 2003, 10 dự án hàng đầu của OWASP đã là tài nguyên hữu ích nhất về rủi ro bảo mật ứng dụng web và đề xuất các cách giảm thiểu những vấn đề này.
Ngày nay, hầu như tất cả việc phát triển ứng dụng như ngân hàng, bán lẻ, giao thông vận tải, thiết bị thông minh đều được thực hiện với các API.
Các API rất quan trọng đối với ứng dụng SaaS và thiết bị di động hiện đại. Về bản chất, API tiết lộ dữ liệu và logic nghiệp vụ, thường những dữ liệu này có bản chất nhạy cảm, chẳng hạn như Thông tin nhận dạng cá nhân (PII). Bởi vì API này ngày càng trở thành mục tiêu của những kẻ tấn công.
Vì API đang thay đổi cách chúng tôi thiết kế và phát triển ứng dụng của mình, điều này cũng đang thay đổi cách chúng tôi nghĩ về bảo mật của mình. Cần có một cách tiếp cận mới về rủi ro bảo mật. Để đáp ứng nhu cầu này, OWASP đã quyết định đưa ra một phiên bản khác của Top 10 dành riêng cho bảo mật API được đặt tên là ” Dự án bảo mật API OWASP “. Báo cáo đầu tiên được phát hành vào ngày 26 tháng 12 năm 2019.
Dưới đây là 10 rủi ro bảo mật API hàng đầu của OWASP và mô tả ngắn gọn của chúng như được cung cấp bởi báo cáo chính thức.
Cấp phép cấp đối tượng bị hỏng API1: 2019
Các API có xu hướng để lộ các điểm cuối xử lý số nhận dạng đối tượng, tạo ra vấn đề Kiểm soát truy cập cấp độ trên bề mặt tấn công rộng rãi. Kiểm tra ủy quyền mức đối tượng nên được xem xét trong mọi chức năng truy cập nguồn dữ liệu bằng cách sử dụng đầu vào từ người dùng.
API2: 2019 Xác thực người dùng bị hỏng
Cơ chế xác thực thường được triển khai không chính xác, cho phép những kẻ tấn công xâm phạm mã thông báo xác thực hoặc khai thác các lỗ hổng triển khai để giả định danh tính của người dùng khác tạm thời hoặc vĩnh viễn. Làm giảm khả năng xác định khách hàng / người dùng của hệ thống, ảnh hưởng đến bảo mật API nói chung.
API3: 2019 Phơi nhiễm dữ liệu quá mức
Mong muốn triển khai chung, các nhà phát triển có xu hướng hiển thị tất cả các thuộc tính đối tượng mà không xem xét độ nhạy cá nhân của chúng, dựa vào khách hàng để thực hiện lọc dữ liệu trước khi hiển thị cho người dùng.
API4: 2019 Thiếu Tài nguyên & Giới hạn Tỷ lệ
Thông thường, các API không áp đặt bất kỳ hạn chế nào về kích thước hoặc số lượng tài nguyên có thể được khách hàng / người dùng yêu cầu. Điều này không chỉ có thể ảnh hưởng đến hiệu suất máy chủ API, dẫn đến Từ chối dịch vụ (DoS), mà còn mở ra cánh cửa cho các lỗi xác thực như bạo lực.
API5: 2019 Cấp phép cấp chức năng bị hỏng
Các chính sách kiểm soát truy cập phức tạp với các phân cấp, nhóm và vai trò khác nhau, và sự tách biệt không rõ ràng giữa chức năng quản trị và chức năng thường xuyên, có xu hướng dẫn đến sai sót về ủy quyền. Bằng cách khai thác những vấn đề này, kẻ tấn công có quyền truy cập vào tài nguyên và / hoặc chức năng quản trị của người dùng khác.
API6: 2019 Phân công hàng loạt
Việc ràng buộc khách hàng cung cấp dữ liệu (ví dụ: JSON) với các mô hình dữ liệu mà không có tính năng lọc thuộc tính thích hợp dựa trên danh sách trắng, thường dẫn đến Gán hàng loạt. Việc đoán các thuộc tính đối tượng, khám phá các điểm cuối API khác, đọc tài liệu hoặc cung cấp các thuộc tính đối tượng bổ sung trong tải trọng yêu cầu, cho phép kẻ tấn công sửa đổi các thuộc tính đối tượng mà chúng không được phép.
Cấu hình sai bảo mật API7: 2019
Định cấu hình sai bảo mật thường là kết quả của cấu hình mặc định không an toàn, cấu hình không đầy đủ hoặc đặc biệt, lưu trữ đám mây mở, tiêu đề HTTP được định cấu hình sai, phương thức HTTP không cần thiết, chia sẻ tài nguyên Cross-Origin dễ dãi (CORS) và thông báo lỗi dài dòng chứa thông tin nhạy cảm.
API8: 2019 tiêm
Các lỗi tiêm, chẳng hạn như SQL, NoSQL, Command Injection, v.v., xảy ra khi dữ liệu không đáng tin cậy được gửi đến trình thông dịch như một phần của lệnh hoặc truy vấn. Dữ liệu độc hại của kẻ tấn công có thể đánh lừa trình thông dịch thực hiện các lệnh ngoài ý muốn hoặc truy cập dữ liệu mà không có sự cho phép thích hợp.
API9: 2019 Quản lý tài sản không phù hợp
Các API có xu hướng hiển thị nhiều điểm cuối hơn các ứng dụng web truyền thống, làm cho tài liệu phù hợp và cập nhật rất quan trọng. Máy chủ phù hợp và khoảng không quảng cáo phiên bản API đã triển khai cũng đóng một vai trò quan trọng để giảm thiểu các vấn đề như phiên bản API không dùng nữa và điểm cuối gỡ lỗi bị lộ.
API10: 2019 Ghi nhật ký & Giám sát không đầy đủ
Ghi nhật ký và giám sát không đầy đủ, cùng với việc tích hợp thiếu hoặc không hiệu quả với phản ứng sự cố, cho phép kẻ tấn công tấn công hệ thống hơn nữa, duy trì sự bền bỉ, xoay trục đến nhiều hệ thống hơn để giả mạo, trích xuất hoặc phá hủy dữ liệu. Hầu hết các nghiên cứu vi phạm đều cho thấy thời gian để phát hiện vi phạm là hơn 200 ngày, thường được phát hiện bởi các bên bên ngoài hơn là các quy trình hoặc giám sát nội bộ.