Các lỗ hổng API OATH hàng đầu
Các lỗ hổng API OATH hàng đầu: Giới thiệu
Khi nói đến khai thác, API là nơi tốt nhất để bắt đầu. API truy cập thường bao gồm ba phần. Máy khách được cấp mã thông báo bởi Máy chủ ủy quyền chạy cùng với API. API nhận mã thông báo truy cập từ ứng dụng khách và áp dụng các quy tắc ủy quyền dành riêng cho miền dựa trên chúng.
Các ứng dụng phần mềm hiện đại dễ bị tổn thương trước nhiều mối nguy hiểm. Theo kịp tốc độ khai thác và lỗ hổng bảo mật gần đây nhất; có điểm chuẩn cho các lỗ hổng này là điều cần thiết để đảm bảo tính bảo mật của ứng dụng trước khi một cuộc tấn công xảy ra. Các ứng dụng của bên thứ ba ngày càng phụ thuộc vào giao thức OAuth. Người dùng sẽ có trải nghiệm người dùng tổng thể tốt hơn, cũng như đăng nhập và ủy quyền nhanh hơn nhờ công nghệ này. Nó có thể an toàn hơn ủy quyền thông thường vì người dùng không phải tiết lộ thông tin đăng nhập của họ với ứng dụng của bên thứ ba để truy cập vào một tài nguyên nhất định. Mặc dù bản thân giao thức là an toàn và bảo mật, nhưng cách nó được triển khai có thể khiến bạn dễ bị tấn công.
Khi thiết kế và lưu trữ API, bài viết này tập trung vào các lỗ hổng OAuth điển hình, cũng như các biện pháp giảm thiểu bảo mật khác nhau.
Cấp phép đối tượng bị hỏng
Có một bề mặt tấn công rộng lớn nếu ủy quyền bị vi phạm do các API cung cấp quyền truy cập vào các đối tượng. Vì các mục có thể truy cập API phải được xác thực nên điều này là cần thiết. Triển khai kiểm tra ủy quyền cấp đối tượng bằng cổng API. Chỉ những người có thông tin đăng nhập quyền thích hợp mới được phép truy cập.
Xác thực người dùng bị hỏng
Mã thông báo trái phép là một cách phổ biến khác để kẻ tấn công có được quyền truy cập vào API. Hệ thống xác thực có thể bị tấn công hoặc khóa API có thể bị lộ nhầm. Mã thông báo xác thực có thể là được tin tặc sử dụng để có được quyền truy cập. Chỉ xác thực mọi người nếu họ có thể tin cậy được và sử dụng mật khẩu mạnh. Với OAuth, bạn có thể vượt ra ngoài các khóa API đơn thuần và có quyền truy cập vào dữ liệu của mình. Bạn nên luôn nghĩ về cách bạn sẽ ra vào một nơi. Mã thông báo ràng buộc người gửi OAuth MTLS có thể được sử dụng cùng với TLS tương hỗ để đảm bảo rằng khách hàng không hoạt động sai và chuyển mã thông báo cho bên không chính xác trong khi truy cập vào các máy khác.
Khuyến mãi API:
Tiếp xúc dữ liệu quá mức
Không có hạn chế về số lượng điểm cuối có thể được xuất bản. Hầu hết thời gian, không phải tất cả các tính năng đều có sẵn cho tất cả người dùng. Bằng cách tiết lộ nhiều dữ liệu hơn mức cần thiết, bạn đang đặt bản thân và những người khác vào tình thế nguy hiểm. Tránh tiết lộ chuyện nhạy cảm thông tin cho đến khi nó thực sự cần thiết. Nhà phát triển có thể chỉ định ai có quyền truy cập vào nội dung nào bằng cách sử dụng Phạm vi OAuth và Xác nhận quyền sở hữu. Tuyên bố có thể chỉ định những phần dữ liệu mà người dùng có quyền truy cập. Kiểm soát truy cập có thể được thực hiện đơn giản hơn và dễ quản lý hơn bằng cách sử dụng cấu trúc tiêu chuẩn trên tất cả các API.
Thiếu tài nguyên & giới hạn tỷ lệ
Mũ đen thường sử dụng các cuộc tấn công từ chối dịch vụ (DoS) như một cách vũ phu để áp đảo máy chủ và do đó giảm thời gian hoạt động của nó xuống XNUMX. Không có hạn chế đối với các tài nguyên có thể được gọi, API rất dễ bị tấn công làm suy yếu. 'Sử dụng cổng API hoặc công cụ quản lý, bạn có thể đặt giới hạn tốc độ cho API. Lọc và phân trang nên được bao gồm, cũng như các câu trả lời bị hạn chế.
Cấu hình sai của hệ thống bảo mật
Các nguyên tắc cấu hình bảo mật khác nhau khá toàn diện, do khả năng cấu hình sai bảo mật là rất lớn. Một số điều nhỏ có thể gây nguy hiểm cho tính bảo mật của nền tảng của bạn. Chẳng hạn, có thể những chiếc mũ đen với mục đích thầm kín có thể phát hiện ra thông tin nhạy cảm được gửi để phản hồi các truy vấn không đúng định dạng.
Phân công hàng loạt
Chỉ vì một điểm cuối không được xác định công khai không có nghĩa là các nhà phát triển không thể truy cập điểm cuối đó. Một API bí mật có thể dễ dàng bị tin tặc chặn và thiết kế ngược. Hãy xem ví dụ cơ bản này, sử dụng Mã thông báo Bearer mở trong API “riêng tư”. Mặt khác, tài liệu công khai có thể tồn tại cho thứ gì đó dành riêng cho mục đích sử dụng cá nhân. Thông tin lộ ra có thể được mũ đen sử dụng để không chỉ đọc mà còn thao túng các đặc điểm của đối tượng. Hãy coi mình là một hacker khi bạn tìm kiếm những điểm yếu tiềm ẩn trong hệ thống phòng thủ của mình. Chỉ cho phép những người có quyền thích hợp truy cập vào những gì đã được trả lại. Để giảm thiểu lỗ hổng, hãy giới hạn gói phản hồi API. Người trả lời không nên thêm bất kỳ liên kết nào không thực sự cần thiết.
API được quảng cáo:
Quản lý tài sản không hợp lý
Ngoài việc nâng cao năng suất của nhà phát triển, các phiên bản và tài liệu hiện tại rất cần thiết cho sự an toàn của chính bạn. Chuẩn bị trước cho việc giới thiệu các phiên bản mới và ngừng sử dụng các API cũ. Sử dụng các API mới hơn thay vì cho phép các API cũ tiếp tục được sử dụng. Đặc tả API có thể được sử dụng làm nguồn chính xác cho tài liệu.
Tiêm
Các API dễ bị tấn công, nhưng các ứng dụng dành cho nhà phát triển bên thứ ba cũng vậy. Mã độc hại có thể được sử dụng để xóa dữ liệu hoặc đánh cắp thông tin bí mật, chẳng hạn như mật khẩu và số thẻ tín dụng. Bài học quan trọng nhất cần rút ra từ điều này là không phụ thuộc vào các cài đặt mặc định. Quản lý hoặc nhà cung cấp cổng của bạn sẽ có thể đáp ứng nhu cầu ứng dụng duy nhất của bạn. Thông báo lỗi không được bao gồm thông tin nhạy cảm. Để ngăn dữ liệu nhận dạng bị rò rỉ ra bên ngoài hệ thống, nên sử dụng Tên giả theo cặp trong mã thông báo. Điều này đảm bảo rằng không có khách hàng nào có thể làm việc cùng nhau để xác định người dùng.
Ghi nhật ký và giám sát không đầy đủ
Khi một cuộc tấn công diễn ra, các đội cần có một chiến lược phản ứng được cân nhắc kỹ lưỡng. Các nhà phát triển sẽ tiếp tục khai thác các lỗ hổng mà không bị phát hiện nếu không có hệ thống giám sát và ghi nhật ký đáng tin cậy, điều này sẽ làm tăng tổn thất và gây tổn hại đến nhận thức của công chúng về công ty. Áp dụng chiến lược kiểm tra điểm cuối sản xuất và giám sát API nghiêm ngặt. Những người kiểm tra mũ trắng tìm thấy lỗ hổng sớm sẽ được thưởng bằng một chương trình tiền thưởng. Dấu vết nhật ký có thể được cải thiện bằng cách đưa danh tính của người dùng vào các giao dịch API. Đảm bảo rằng tất cả các lớp trong kiến trúc API của bạn đều được kiểm tra bằng cách sử dụng dữ liệu Mã thông báo truy cập.
Kết luận
Kiến trúc sư nền tảng có thể trang bị cho hệ thống của họ để luôn đi trước những kẻ tấn công một bước bằng cách tuân theo các tiêu chí về lỗ hổng đã được thiết lập. Vì các API có thể cung cấp khả năng truy cập vào Thông tin nhận dạng cá nhân (PII), nên việc duy trì tính bảo mật của các dịch vụ đó là rất quan trọng đối với cả sự ổn định của công ty và việc tuân thủ luật pháp như GDPR. Không bao giờ gửi mã thông báo OAuth trực tiếp qua API mà không sử dụng Cổng API và Phương pháp tiếp cận mã thông báo Phantom.
API được quảng cáo:
