Mỗi pull request Việc thêm hoặc thay đổi một endpoint sẽ làm thay đổi bề mặt tấn công của API. Hầu hết các công cụ bảo mật API không nhận ra điều này cho đến khi endpoint đó hoạt động và đã bắt đầu nhận lưu lượng truy cập. Đến lúc đó, việc khắc phục không còn là một thay đổi nhỏ trong quá trình xem xét mã nữa, mà là một cuộc thảo luận về xử lý sự cố.
Bảo mật API là việc tìm kiếm và khắc phục các rủi ro trong cách một ứng dụng công khai các điểm cuối của nó: ai có thể gọi chúng, dữ liệu chúng trả về là gì và liệu chúng có thực hiện đúng như mô tả trong tài liệu hay không.
Hầu hết các công cụ được xây dựng để giải quyết vấn đề này đều kiểm tra API trong quá trình thực thi, từ bên ngoài, giống như cách mà kẻ tấn công sẽ làm. Cách tiếp cận đó có hiệu quả, nhưng nó chỉ hoạt động sau khi API đã được triển khai. Xygeni Nó đi theo con đường sớm hơn: nó đọc mã nguồn và đặc tả API của bạn trước khi bất kỳ yêu cầu nào được gửi đến điểm cuối.
Bốn cách để kiểm thử API và câu trả lời của từng cách
Hầu hết các chương trình đã hoàn thiện đều chạy nhiều hơn một trong số này:
- Kiểm tra tĩnh Nó phân tích mã nguồn và thông số kỹ thuật API trước khi triển khai. Nó trả lời câu hỏi “chúng ta vừa để lộ những gì?”. Đây là phương pháp mà bài viết này tập trung vào.
- Kiểm thử động (DAST) Nó gửi lưu lượng truy cập thực tế đến một API đang hoạt động và quan sát phản hồi của API đó. Nó trả lời câu hỏi "hiện tại thực sự có thể truy cập và khai thác được những gì?"
- Rò rỉ Nó ném các dữ liệu đầu vào bị lỗi hoặc không mong đợi vào các điểm cuối để làm nổi bật các sự cố và lỗi trong các trường hợp ngoại lệ. Nó trả lời câu hỏi "điều gì sẽ xảy ra khi nhận được dữ liệu đầu vào mà chúng ta không lường trước được?"
- Kiểm thử xâm nhập thủ công Nó bổ sung khả năng phán đoán của con người để tìm ra các lỗi logic mà các công cụ tự động bỏ sót. Nó trả lời câu hỏi “một kẻ tấn công thông minh sẽ xâu chuỗi các phép toán như thế nào?”
Không có giải pháp nào thay thế cho giải pháp khác. Chúng giải quyết những câu hỏi khác nhau ở những giai đoạn khác nhau trong vòng đời của chương trình, và điểm yếu lớn nhất của hầu hết các chương trình chính là câu hỏi đầu tiên.
Vì sao hầu hết các công cụ bảo mật API nhận ra rủi ro quá muộn?
Kiểm thử bảo mật API thời gian thực gửi lưu lượng truy cập đến một ứng dụng đang hoạt động và quan sát cách ứng dụng phản hồi. Đây là một lớp bảo mật hợp lệ và cần thiết. Tuy nhiên, về bản chất, nó cũng là một chỉ báo chậm: một điểm cuối phải tồn tại, được triển khai và có thể truy cập được trước khi trình quét thời gian thực có thể đưa ra bất kỳ thông tin nào về nó. Bất cứ lỗ hổng nào nó tìm thấy đều đã bị lộ trong suốt thời gian quét diễn ra.
Còn một vấn đề nữa nằm bên dưới vấn đề về thời gian. Các công cụ thời gian chạy chỉ có thể kiểm tra những gì chúng biết là tồn tại. Nếu một điểm cuối chưa từng được ghi lại, hoặc đặc tả OpenAPI trở nên lỗi thời ngay khi ai đó phát hành một tuyến đường mới, thì trình quét thời gian chạy không có cách nào biết được nó ở đó. Nó kiểm tra bản đồ, chứ không phải lãnh thổ.
Kiểm thử bảo mật API tĩnh khắc phục cả hai lỗ hổng bằng cách chuyển việc kiểm tra đến nơi điểm cuối được định nghĩa: mã của bạn và đặc tả API của bạn, trước khi triển khai. Điều tương tự cũng áp dụng cho API tĩnh, giúp việc kiểm thử bảo mật API tĩnh được thực hiện hiệu quả hơn. pull request phần giới thiệu điểm cuối là pull request Điều đó làm nổi bật rủi ro của nó.
Bảo mật API tĩnh thực sự có nghĩa là gì?
Xygeni xây dựng kho API của bạn từ hai nguồn: mã nguồn ứng dụng và thông số kỹ thuật API, bao gồm OpenAPI và Swagger.
Bản kê khai chỉ bao gồm thông số kỹ thuật cho thấy các điểm cuối (endpoint) mà ai đó đã nhớ ghi lại. Bản kê khai chỉ bao gồm mã nguồn cho thấy những gì tồn tại nhưng không nhất thiết là cách nó được thiết kế để sử dụng. Đọc cả hai sẽ cho bạn bức tranh toàn diện: các điểm cuối mà nhóm của bạn đã ghi lại, và những điểm cuối mà không ai ghi lại.
Kho hàng đó là nền tảng mà mọi thứ khác được xây dựng dựa trên đó:
- Tổng số API được phát hiện và tài sản có nguy cơ bị đe dọa được đo lường so với mức cơ sở.
- Các điểm cuối được phân loại theo phương thức HTTP
- Các vấn đề được nhóm theo dịch vụ
- Mỗi điểm cuối (endpoint) với phương thức, đường dẫn, dịch vụ, mô-đun, trạng thái xác thực và điểm rủi ro của nó.
Các trưởng nhóm kỹ thuật của bạn có thể hình dung được cấu trúc giao diện API mà không cần mở bất kỳ yêu cầu hỗ trợ nào.
Mỗi điểm cuối mà Xygeni tìm thấy, cùng với phương thức, trạng thái xác thực và điểm rủi ro, được xây dựng từ mã nguồn và thông số kỹ thuật.
Production note Cắt phần bảng AI Triage từ bất kỳ ảnh chụp màn hình Bảo mật API nào.
Được đối chiếu với danh sách Top 10 các lỗ hổng bảo mật API của OWASP.
Các phát hiện này phản ánh khuôn khổ mà các nhóm bảo mật và kiểm toán viên của bạn đã sử dụng. Xygeni phát hiện rủi ro trên toàn bộ API Security của OWASP. 10 vị trí hàng đầu (2023):
Có một hạng mục bị cố tình bỏ qua. API6, Truy cập không hạn chế vào các luồng nghiệp vụ nhạy cảm, yêu cầu hiểu rõ quy trình nghiệp vụ được cho phép những gì, và không có công cụ phân tích tĩnh nào phát hiện điều đó một cách đáng tin cậy. Bất kỳ nhà cung cấp nào tuyên bố ngược lại đều chỉ đang bán cho bạn một ô chọn. Vấn đề đó sẽ thuộc về việc phân tích mối đe dọa và các chuyên gia kiểm thử xâm nhập của bạn.
Không phải mọi phát hiện đều có giá trị như nhau: Độ nhạy của dữ liệu và các sự kết hợp nguy hiểm
Một danh sách kết quả đơn giản coi điểm cuối kiểm tra sức khỏe chưa được xác thực giống như điểm cuối chưa được xác thực trả về hồ sơ khách hàng. Đó không phải là cùng một vấn đề, và mô hình ưu tiên chấm điểm chúng như nhau sẽ khiến nhóm của bạn quen bỏ qua danh sách đó.
Xygeni phân loại dữ liệu mà mỗi điểm cuối xử lý, gắn cờ PII, PCI và PHI trong các tham số yêu cầu và trong phản hồi, đồng thời ghép nối điều đó với trạng thái xác thực của điểm cuối.
Nó cũng liên kết các phát hiện rơi vào cùng một điểm cuối và nâng cao mức độ nghiêm trọng khi chúng chồng chất lên nhau. Rò rỉ thông tin nhận dạng cá nhân (PII) trong phản hồi đã là một phát hiện nghiêm trọng. Rò rỉ tương tự trên một điểm cuối không yêu cầu xác thực là rất nghiêm trọng, và nền tảng sẽ chấm điểm theo cách đó thay vì để người dùng tự phát hiện ra kết nối.
Các điểm cuối "ma" và "mồ côi": Sự lệch lạc giữa mã và đặc tả
Vì Xygeni đọc mã nguồn và đặc tả API của bạn song song, nó sẽ phát hiện ra những điểm không khớp. Sự khác biệt đó thể hiện qua ba mẫu dễ nhận biết:
- Các điểm cuối không được ghi chép lại. Chúng tồn tại trong mã lập trình và chưa bao giờ được thêm vào tài liệu đặc tả.
- Các điểm cuối "ma". Chúng được đánh dấu là lỗi thời hoặc đã ngừng sử dụng, nhưng vẫn có thể truy cập được.
- Các điểm cuối mồ côi. Không ai trong đội hiện tại sở hữu chúng.
Không có mục nào trong số này xuất hiện trong danh mục chỉ có thông số kỹ thuật, bởi vì chính thông số kỹ thuật đó lại đang thiếu chúng.
Bằng chứng bạn có thể dựa vào để hành động, chứ không phải là giấy triệu tập để điều tra.
Mỗi phát hiện đều chỉ ra chính xác thành phần chịu trách nhiệm: tệp, lớp, phương thức và dòng cụ thể gây ra lỗi, cùng với mã gây lỗi được hiển thị bên cạnh. Mỗi lỗi cũng đi kèm với mức độ nghiêm trọng, hạng mục OWASP API Security Top 10, mã CWE, trạng thái xác thực của điểm cuối và phân loại độ nhạy cảm của dữ liệu liên quan.
Một lỗi chỉ nêu tên điểm cuối (endpoint) khiến nhà phát triển phải tìm kiếm khắp mã nguồn trước khi họ có thể bắt đầu sửa chữa bất cứ điều gì. Một lỗi nêu tên dòng lệnh (line) sẽ giúp họ tìm ra lỗi ngay lập tức.
Kết quả xuất ra dưới dạng JSON, CSV, Markdown và SARIF 2.1.0, vì vậy chúng sẽ được lưu trữ trong thư mục tCác công cụ mà nhóm của bạn đã sử dụng.
Trình xử lý, dòng lệnh và đoạn mã gây ra lỗ hổng. Đây không phải là một phiếu cần điều tra.
Vì sao trò chơi này chỉ có trên một nền tảng duy nhất, chứ không phải trên một hệ máy chơi game khác?
Xygeni vận hành API Security song song với SAST, SCA, Bảo mật bí mật, IaC và ĐÔNG bên trong một nền tảng duy nhất, được liên kết thông qua ASPMThay vì cung cấp nó như một công cụ riêng biệt với các tính năng riêng, chúng tôi sẽ sử dụng công cụ này. login và lượng công việc tồn đọng của chính nó.
Điều đó quan trọng vì các phát hiện tĩnh và phát hiện trong quá trình thực thi trả lời những câu hỏi khác nhau về cùng một điểm cuối, và chúng hữu ích hơn khi kết hợp với nhau hơn là khi tách rời. Phát hiện tĩnh cho bạn biết một điểm cuối có rủi ro trước khi nó được triển khai. DAST xác nhận những gì thực sự có thể truy cập và khai thác được sau khi nó đang chạy.
Chia nhỏ việc đó ra hai bảng điều khiển và rủi ro tương quan sẽ trở thành hai danh sách công việc tồn đọng không liên quan. Không ai đối chiếu chúng, và điểm cuối vừa không được ghi chép lại vừa không được xác thực sẽ nằm trong cả hai hàng đợi.
Hãy xem bề mặt tấn công thực sự của API. Bảo mật API có sẵn dưới dạng Enterprise Đây là một tiện ích bổ sung cho nền tảng Xygeni, và quá trình quét sẽ được thực hiện trên các kho lưu trữ của riêng bạn trong cơ sở hạ tầng của chính bạn.
FAQ
Liệu nó có thể xác định được điểm cuối nào xử lý dữ liệu nhạy cảm không?
Đúng vậy. Xygeni gắn cờ PII, PCI và PHI trong các thông số và phản hồi điểm cuối, và sử dụng phân loại đó để xếp hạng các phát hiện theo mức độ tiếp xúc thực tế.
Nó có thể chạy trên mọi hệ điều hành không? pull request?
Đúng vậy. Quét tăng dần chỉ phân tích các điểm cuối đã thay đổi và bản kê khai mà nó tạo ra có thể giúp tập trung quá trình quét DAST tiếp theo vào cùng các điểm cuối đó, do đó việc kiểm thử tĩnh và kiểm thử thời gian chạy luôn được đồng bộ với những gì thực sự đã thay đổi.
Mã của tôi có rời khỏi môi trường hiện tại không?
Không. Quá trình quét được thực hiện trên cơ sở hạ tầng của riêng bạn. Chỉ có kết quả được tải lên, được bảo vệ trong quá trình truyền tải và khi lưu trữ.
Làm thế nào để có được bảo mật API?
Bảo mật API có sẵn dưới dạng Enterprise Tiện ích bổ sung. Hãy yêu cầu bản thử nghiệm (PoC) và chúng tôi sẽ thảo luận về phạm vi dự án với bạn.
