Với sự phụ thuộc ngày càng tăng vào các ứng dụng di động để liên lạc, thương mại và cộng tác, việc bảo vệ tính toàn vẹn của các hệ thống cung cấp năng lượng cho các ứng dụng này là điều tối quan trọng. API, đường dẫn cho phép các ứng dụng phần mềm khác nhau giao tiếp và trao đổi dữ liệu, đã trở thành một thành phần thiết yếu của hệ sinh thái kỹ thuật số hiện đại. Một trong những lý do chính khiến bảo mật API trở nên quan trọng trong thiết kế và phát triển ứng dụng là việc áp dụng rộng rãi các API RESTful, được xây dựng trên các nguyên tắc phi trạng thái và dựa trên các phương thức HTTP tiêu chuẩn để liên lạc. Mặc dù cách tiếp cận này đơn giản hóa thiết kế API và cho phép tích hợp liền mạch, nhưng nó có thể khiến API gặp nhiều lỗ hổng bảo mật nếu không được bảo vệ đầy đủ. Một số mối đe dọa phổ biến bao gồm truy cập trái phép, rò rỉ dữ liệu, tấn công tiêm nhiễm và tấn công từ chối dịch vụ (DoS).

Blog về bảo mật API này làm sáng tỏ bảo mật API là gì, Top 10 API của OWASP và cách AppSealing đưa ra các chiến lược thiết yếu để bảo vệ tài sản kỹ thuật số của bạn và nâng cao khả năng phục hồi của hệ sinh thái ứng dụng của bạn.

OWASP API Top 10

Top 10 API của Dự án Bảo mật Ứng dụng Web Mở (Open Web Application Security Project – OWASP) cung cấp tài nguyên quan trọng cho các tổ chức để tăng cường bảo mật cho các giao diện lập trình ứng dụng (API) của họ. Nó phục vụ như một khuôn khổ tiêu chuẩn ngành, cung cấp hướng dẫn về việc xác định và giảm thiểu các rủi ro bảo mật cấp bách nhất của API.

Để luôn cập nhật các mối đe dọa mới nổi và những thay đổi trong bối cảnh API, các nhà phát triển, chuyên gia bảo mật và tổ chức cần ưu tiên tìm hiểu và giải quyết các rủi ro liên quan đến API. Tính bảo mật, tính toàn vẹn và tính sẵn có của thông tin nhạy cảm phải được đảm bảo để tránh các vi phạm tiềm ẩn. Bằng cách thực hiện các biện pháp cần thiết này, các tổ chức có thể bảo vệ thông tin quan trọng khỏi bị truy cập trái phép hoặc tấn công mạng vào hệ thống API của họ.

Trước khi tìm hiểu sâu hơn về bảo mật API, hãy cùng tìm hiểu về các lỗ hổng API trong tin tức và lý do tại sao chúng lại gây chú ý.

Vi phạm Experian: Một sinh viên chưa tốt nghiệp tại Học viện Công nghệ Rochester đã phát hiện ra một lỗ hổng bảo mật lớn trong một điểm cuối API khi đang tìm kiếm các điều khoản cho vay sinh viên tốt hơn. Lỗ hổng cho phép bất kỳ ai có quyền truy cập vào thông tin cá nhân cơ bản, chẳng hạn như tên, địa chỉ và ngày sinh của một người – thông tin có thể lấy được dễ dàng – để truy xuất dữ liệu tín dụng có độ nhạy cao, bao gồm cả điểm tín dụng. Dữ liệu bị lộ này gây ra rủi ro nghiêm trọng đối với hành vi trộm cắp danh tính, gian lận tài chính và các tội phạm mạng khác nếu bị các tác nhân độc hại truy cập. Trường hợp này cho thấy tầm quan trọng của việc triển khai các biện pháp bảo mật mạnh mẽ cho API, vì ngay cả những sơ suất nhỏ cũng có thể dẫn đến vi phạm nghiêm trọng quyền riêng tư và xâm phạm dữ liệu người dùng. Vi phạm này nhấn mạnh nhu cầu cấp thiết đối với các tổ chức là ưu tiên bảo mật API bằng cách sử dụng các cơ chế xác thực mạnh như kiểm soát truy cập và hệ thống giám sát liên tục được thiết kế để ngăn chặn truy cập trái phép hoặc khả năng lạm dụng dữ liệu nhạy cảm của người dùng.

Một câu chuyện xúc động xuất hiện giữa những tin tức nghiệt ngã về cuộc xâm lược Ukraine của Nga. Những anh hùng Ukraine giấu tên Những chiếc máy kéo bị vô hiệu hóa từ xa trị giá 5 triệu đô la mà quân đội Nga đã đánh cắp từ một đại lý được ủy quyền của John Deere ở thành phố Melitopol bị chiếm đóng. Những người lính đã mang theo 27 mảnh máy móc nông nghiệp và gửi chúng đến Chechnya, cách đó hơn 700 dặm, chỉ để biết rằng chúng không thể hoạt động do “công tắc tiêu diệt”. Đại lý đã sử dụng công nghệ GPS được nhúng trong mỗi máy cho mục đích theo dõi. Mặc dù có báo cáo cho rằng thiết bị đã bị mắc kẹt tại một trang trại gần Grozny vào cuối ngày 1 tháng 5, nhưng có tin đồn rằng một số người Nga có thể đã tìm được thành công các chuyên gia có thể giúp vượt qua các biện pháp bảo vệ kỹ thuật số làm hỏng máy.

Ngày nay, trong một thế giới mà hầu như mọi ngành công nghiệp đều dựa vào các công nghệ dựa trên phần mềm, bảo mật API đã trở thành một khía cạnh không thể thiếu trong hoạt động kinh doanh. Các nhà phát triển có kiến thức và kỹ năng cần thiết để duy trì và bảo vệ lớp bảo vệ quan trọng này được các công ty hoạt động trong nhiều lĩnh vực khác nhau, từ tài chính đến máy móc nông nghiệp, săn đón. Do đó, các nhà phát triển phải theo kịp các tiến bộ trong các công cụ bảo mật API và các phương pháp hay nhất để đảm bảo rằng hệ thống phần mềm của tổ chức của họ luôn an toàn trước các mối đe dọa trên mạng.

API1:2019 – Broken Object-Level Authorization 

API1:2019 – Ủy quyền cấp đối tượng bị hỏng đề cập đến lỗ hổng bảo mật khi API không thể thực thi các biện pháp kiểm soát truy cập thích hợp trên các tài nguyên nhạy cảm. Trong trường hợp này, người dùng trái phép có thể truy cập hoặc thao tác đối tượng mà họ không được phép tương tác. Lỗ hổng bảo mật này thường phát sinh khi một API sử dụng các mã định danh có thể dự đoán hoặc dễ đoán cho các tài nguyên và không thực hiện kiểm tra ủy quyền phù hợp.

Kẻ tấn công có thể khai thác lỗ hổng này bằng cách thao túng số nhận dạng đối tượng trong yêu cầu API để truy cập tài nguyên trái phép, có khả năng làm lộ dữ liệu nhạy cảm hoặc hành động trái phép thay mặt cho người dùng khác.

Ví dụ: API mua sắm trực tuyến sử dụng ID đơn hàng dạng số trong URL, chẳng hạn như “/orders/12345”. Kẻ tấn công có thể thay đổi ID đơn đặt hàng trong URL để truy cập các đơn đặt hàng thuộc về người dùng khác mà không được phép thích hợp. Để giảm thiểu lỗ hổng này, các nhà phát triển nên triển khai các cơ chế kiểm soát truy cập mạnh mẽ, đảm bảo rằng người dùng chỉ có thể truy cập vào các tài nguyên mà họ được phép xem.

Ví dụ: API mua sắm trực tuyến sử dụng ID đơn hàng dạng số trong URL, chẳng hạn như “/orders/12345”. Kẻ tấn công có thể thay đổi ID đơn đặt hàng trong URL để truy cập các đơn đặt hàng thuộc về người dùng khác mà không được phép thích hợp. Để giảm thiểu lỗ hổng này, các nhà phát triển nên triển khai các cơ chế kiểm soát truy cập mạnh mẽ, đảm bảo rằng người dùng chỉ có thể truy cập vào các tài nguyên mà họ được phép xem.

API2:2019 – Xác thực người dùng bị hỏng

API2:2019 – Xác thực người dùng bị hỏng là một lỗ hổng bảo mật xảy ra khi cơ chế xác thực người dùng của API được triển khai không đúng cách hoặc được bảo vệ không đầy đủ. Sự cố này có thể khiến API dễ bị tấn công, cho phép các tác nhân độc hại bỏ qua xác thực, mạo danh người dùng hợp pháp hoặc giành quyền truy cập trái phép vào dữ liệu và tài nguyên nhạy cảm.

Xác thực người dùng bị hỏng có thể do nhiều yếu tố khác nhau, chẳng hạn như chính sách mật khẩu yếu, thiếu xác thực đa yếu tố, xử lý mã thông báo không an toàn hoặc lỗ hổng trong quy trình xác thực. Khi cơ chế xác thực của API không mạnh mẽ, kẻ tấn công có thể khai thác những điểm yếu này để truy cập trái phép vào hệ thống, xâm phạm tài khoản người dùng và có khả năng dẫn đến các vi phạm bảo mật khác.

Ví dụ: API cho phép người dùng đặt lại mật khẩu của họ bằng câu hỏi bảo mật nhưng không giới hạn số lần thử trả lời chúng. Kẻ tấn công có thể khởi động một cuộc tấn công vũ phu đối với các câu hỏi bảo mật để giành quyền truy cập trái phép vào tài khoản của người dùng. Để giải quyết lỗ hổng này, các nhà phát triển nên triển khai các cơ chế xác thực mạnh mẽ, chẳng hạn như xác thực đa yếu tố và giới hạn tốc độ đối với các lần thử xác thực.

Ví dụ: API cho phép người dùng đặt lại mật khẩu của họ bằng câu hỏi bảo mật nhưng không giới hạn số lần thử trả lời chúng. Kẻ tấn công có thể khởi động một cuộc tấn công vũ phu đối với các câu hỏi bảo mật để giành quyền truy cập trái phép vào tài khoản của người dùng. Để giải quyết lỗ hổng này, các nhà phát triển nên triển khai các cơ chế xác thực mạnh mẽ, chẳng hạn như xác thực đa yếu tố và giới hạn tốc độ đối với các lần thử xác thực.

API3:2019 – Tiếp xúc dữ liệu quá mức

API3:2019 – Phơi bày dữ liệu quá mức là một rủi ro bảo mật khi API để lộ nhiều dữ liệu hơn mức cần thiết, có khả năng cho phép kẻ tấn công truy cập thông tin nhạy cảm. Lỗ hổng này thường bắt nguồn từ việc các nhà phát triển cho rằng máy khách lọc ra dữ liệu nhạy cảm trước khi hiển thị cho người dùng. Do đó, API có thể trả về nhiều thông tin hơn ứng dụng khách yêu cầu, làm tăng nguy cơ rò rỉ dữ liệu. Việc để lộ dữ liệu quá mức có thể dẫn đến việc truy cập trái phép và khai thác dữ liệu nhạy cảm, chẳng hạn như thông tin nhận dạng cá nhân (PII) hoặc thông tin kinh doanh bí mật. Những kẻ tấn công có thể sử dụng dữ liệu này cho nhiều mục đích xấu khác nhau, bao gồm đánh cắp danh tính, lừa đảo tài chính hoặc gián điệp công ty.

Ví dụ

API phương tiện truyền thông xã hội trả về dữ liệu hồ sơ đầy đủ của người dùng, bao gồm email, số điện thoại và ngày sinh, mặc dù ứng dụng khách chỉ yêu cầu tên người dùng và ảnh hồ sơ. Kẻ tấn công có thể khai thác lỗ hổng này để thu thập dữ liệu nhạy cảm của người dùng. Để tránh lộ dữ liệu quá mức, nhà phát triển nên triển khai lọc dữ liệu ở cấp API, chỉ trả lại dữ liệu cần thiết cho mỗi yêu cầu.

API4:2019 – Thiếu tài nguyên và giới hạn tỷ lệ

API4:2019 – Thiếu tài nguyên và giới hạn tốc độ đề cập đến rủi ro bảo mật liên quan đến các API không triển khai các biện pháp kiểm soát đầy đủ để hạn chế số lượng yêu cầu mà khách hàng có thể thực hiện trong một khoảng thời gian nhất định. Nếu không có các biện pháp kiểm soát như vậy, các API trở nên dễ bị tấn công bởi các cuộc tấn công khác nhau, chẳng hạn như tấn công từ chối dịch vụ (DoS) hoặc tấn công vũ phu, có thể tiêu tốn tài nguyên hệ thống và làm gián đoạn dịch vụ. Khi các API thiếu khả năng quản lý tài nguyên và giới hạn tốc độ thích hợp, kẻ tấn công có thể khai thác điểm yếu này để áp đảo hệ thống với các yêu cầu cao. Điều này có thể dẫn đến sự cố máy chủ, thời gian phản hồi chậm hoặc thậm chí là hệ thống hoàn chỉnh không khả dụng, ảnh hưởng nghiêm trọng đến trải nghiệm người dùng và có khả năng gây thiệt hại về tài chính hoặc uy tín cho tổ chức.

Ví dụ:

Một API thiếu giới hạn tốc độ trên điểm cuối đăng nhập của nó, cho phép kẻ tấn công gửi hàng nghìn yêu cầu đăng nhập mỗi giây để đoán thông tin đăng nhập của người dùng. Để giảm thiểu rủi ro này, các nhà phát triển nên triển khai giới hạn tốc độ và các biện pháp kiểm soát quản lý tài nguyên khác, chẳng hạn như bộ nhớ đệm và điều tiết yêu cầu.

API5:2019 – Ủy quyền cấp chức năng bị hỏng

API5:2019 – Ủy quyền cấp chức năng bị hỏng đề cập đến một lỗ hổng trong API xảy ra khi người dùng có thể thực hiện các hành động mà lẽ ra họ không được phép thực hiện, thường là do kiểm tra quyền không đầy đủ. Vấn đề bảo mật này có thể cho phép kẻ tấn công leo thang đặc quyền của chúng và thực hiện các hành động trái phép, có khả năng làm tổn hại đến dữ liệu nhạy cảm hoặc chức năng hệ thống. Ủy quyền cấp chức năng bị hỏng phát sinh khi cơ chế ủy quyền của API không xác minh đúng vai trò, quyền hoặc đặc quyền của người dùng trước khi cấp quyền truy cập vào các chức năng hoặc tài nguyên cụ thể. Một số yếu tố, chẳng hạn như triển khai kiểm soát truy cập không chính xác, phụ thuộc vào thực thi phía máy khách hoặc xác thực vai trò người dùng không đầy đủ, có thể gây ra điều này.

Ví dụ:

API thương mại điện tử có một điểm cuối để cập nhật giá sản phẩm mà chỉ quản trị viên mới có thể truy cập được. Tuy nhiên, do kiểm tra quyền không đầy đủ, người dùng thông thường có thể truy cập điểm cuối này và sửa đổi giá. Để giải quyết vấn đề này, nhà phát triển nên triển khai cơ chế ủy quyền mạnh mẽ và xác minh quyền của người dùng đối với từng yêu cầu API.

API6:2019 – Chuyển nhượng hàng loạt

API6:2019 – Chuyển nhượng hàng loạt là một lỗ hổng xảy ra khi một API cho phép ứng dụng khách cập nhật hoặc tạo các thuộc tính mà lẽ ra họ không có quyền truy cập, thường là do liên kết dữ liệu do ứng dụng cung cấp với các thuộc tính đối tượng nội bộ mà không có quá trình lọc hoặc xác thực đầy đủ. Điều này có thể cho phép kẻ tấn công sửa đổi dữ liệu nhạy cảm hoặc leo thang đặc quyền bằng cách thao túng các tham số đầu vào trong các yêu cầu API. Các lỗ hổng chuyển nhượng hàng loạt có thể phát sinh do sự phụ thuộc của nhà phát triển vào các tính năng liên kết dữ liệu tự động mà khung ứng dụng web cung cấp. Các tính năng này thường liên kết dữ liệu do người dùng cung cấp với các thuộc tính đối tượng bên trong mà không xem xét các rủi ro bảo mật tiềm ẩn. Do đó, những kẻ tấn công có thể khai thác sự giám sát này để giả mạo các thuộc tính nên bị hạn chế hoặc không được hiển thị cho khách hàng.

Ví dụ:

Kẻ tấn công sửa đổi yêu cầu đăng ký người dùng để bao gồm tham số “isAdmin=true”, khiến API tạo một người dùng mới có đặc quyền quản trị. Để ngăn việc gán hàng loạt, nhà phát triển nên triển khai xác thực và lọc đầu vào, đảm bảo rằng khách hàng chỉ có thể sửa đổi các thuộc tính mà họ được phép thay đổi.

API7:2019 – Cấu hình sai bảo mật

API7:2019 – Cấu hình sai bảo mật đề cập đến một lỗ hổng khi API được triển khai hoặc duy trì với cấu hình không an toàn, khiến nó dễ bị tấn công. Rủi ro này có thể phát sinh từ nhiều yếu tố, bao gồm cài đặt mặc định không an toàn, cấu hình không đầy đủ hoặc đặc biệt, tiêu đề bảo mật không chính xác hoặc lưu trữ đám mây không được bảo vệ. Cấu hình sai bảo mật có thể là do thiếu tăng cường bảo mật phù hợp, chẳng hạn như không thay đổi thông tin đăng nhập mặc định, bật các tính năng không cần thiết hoặc không hạn chế quyền truy cập vào thông tin nhạy cảm. Những cấu hình sai này có thể khiến API bị tấn công, bao gồm truy cập trái phép, rò rỉ dữ liệu hoặc xâm phạm toàn bộ hệ thống.

Ví dụ:

Một máy chủ API được triển khai với các cài đặt mặc định, bao gồm cả việc bật danh sách thư mục. Kẻ tấn công có thể khai thác cấu hình sai này để khám phá và truy cập các tệp nhạy cảm hoặc dữ liệu cấu hình. Để giải quyết rủi ro này, các nhà phát triển nên tuân theo các phương pháp hay nhất về bảo mật, chẳng hạn như tắt các tính năng không cần thiết, thay đổi thông tin xác thực mặc định cũng như thường xuyên xem xét và cập nhật cấu hình.

API8:2019 – Injection

API8:2019 – Injection đề cập đến một lỗ hổng phát sinh khi API không xác thực đúng cách hoặc làm sạch dữ liệu do người dùng cung cấp, khiến nó dễ bị tấn công bằng cách inject mã. Các cuộc tấn công này có thể bao gồm inject SQL, tiêm lệnh hoặc các hình thức inject mã khác, cho phép kẻ tấn công thực thi các lệnh ngoài ý muốn, truy cập thông tin nhạy cảm hoặc xâm phạm hệ thống.

Các lỗ hổng được inject thường là kết quả của việc sử dụng dữ liệu do người dùng cung cấp trong việc xây dựng các truy vấn, lệnh hoặc các biểu thức khác mà không có quy trình xác thực hoặc vệ sinh đầu vào phù hợp. Những kẻ tấn công có thể khai thác các lỗ hổng này bằng cách gửi mã độc hại hoặc đầu vào được chế tạo đặc biệt như một phần của yêu cầu API. Nếu không được xử lý đúng cách, nó có thể dẫn đến việc thực thi mã của kẻ tấn công ở phía máy chủ hoặc trong bối cảnh phiên của người dùng khác.

Ví dụ:

Kẻ tấn công gửi mã SQL độc hại dưới dạng tham số trong yêu cầu API. API không thể xác thực và làm sạch đầu vào, dẫn đến việc thực thi mã SQL của kẻ tấn công, mã này có thể tiết lộ dữ liệu nhạy cảm hoặc sửa đổi cơ sở dữ liệu. Các nhà phát triển nên triển khai các kỹ thuật xác thực, khử trùng và tham số hóa đầu vào phù hợp để giảm thiểu các lỗ hổng tiêm chích.

API9:2019 – Quản lý tài sản không đúng cách

API9:2019 – Quản lý nội dung không đúng cách là một lỗ hổng phát sinh khi các API không được ghi lại, tạo phiên bản hoặc bảo mật đúng cách, khiến việc quản lý và bảo vệ chúng khỏi bị truy cập hoặc khai thác trái phép trở nên khó khăn. Rủi ro này có thể xuất phát từ việc thiếu khoảng không quảng cáo API phù hợp, các phiên bản API lỗi thời hoặc chưa được vá lỗi, sự không nhất quán giữa môi trường phát triển, thử nghiệm và sản xuất hoặc kiểm soát truy cập không đầy đủ. Quản lý tài sản không đúng cách có thể dẫn đến nhiều vấn đề bảo mật khác nhau, chẳng hạn như truy cập trái phép vào dữ liệu nhạy cảm, khai thác các lỗ hổng đã biết trong các phiên bản API lỗi thời hoặc làm lộ chức năng quan trọng của hệ thống. Trong một số trường hợp, kẻ tấn công cũng có thể tận dụng các API được quản lý kém để truy cập vào các phần khác của ứng dụng hoặc cơ sở hạ tầng, có khả năng dẫn đến các sự cố bảo mật nghiêm trọng hơn.

VÍ dụ:

Một tổ chức triển khai nhiều phiên bản API nhưng không gỡ bỏ được các phiên bản cũ hơn, dễ bị tấn công. Kẻ tấn công có thể khai thác các lỗ hổng đã biết trong các phiên bản API lỗi thời để truy cập trái phép hoặc xâm phạm hệ thống. Để giải quyết vấn đề này, các tổ chức nên duy trì kho API toàn diện, đảm bảo rằng tất cả các phiên bản API đều được cập nhật và triển khai các biện pháp kiểm soát truy cập phù hợp.

API10:2019 – Ghi nhật ký và giám sát không đầy đủ

Việc thiếu các cơ chế giám sát và ghi nhật ký đầy đủ trong API có thể gây khó khăn cho việc phát hiện và ứng phó với các sự cố bảo mật kịp thời và hiệu quả, có khả năng cho phép kẻ tấn công khai thác lỗ hổng hoặc xâm phạm dữ liệu nhạy cảm mà không bị phát hiện. Ghi nhật ký và giám sát không đầy đủ có thể do nhiều yếu tố khác nhau, chẳng hạn như lưu trữ nhật ký không đầy đủ, thiếu phân tích nhật ký hoặc cơ chế cảnh báo không đầy đủ. Khi một API thiếu ghi nhật ký và giám sát thích hợp, các nhóm bảo mật sẽ khó xác định và điều tra các hoạt động đáng ngờ, theo dõi nguyên nhân gốc rễ của vấn đề hoặc thu thập bằng chứng để phản hồi sự cố và pháp y.

Ví dụ:

API bị vi phạm dữ liệu do lỗ hổng chưa biết trước đó. Tuy nhiên, do không ghi nhật ký và giám sát đầy đủ, nhóm bảo mật vẫn không biết về vi phạm trong một thời gian dài, cho phép kẻ tấn công lấy được một lượng lớn dữ liệu nhạy cảm. Các tổ chức nên triển khai các giải pháp giám sát và ghi nhật ký toàn diện để giảm thiểu rủi ro này, bao gồm cảnh báo theo thời gian thực và phân tích nhật ký tự động để phát hiện và ứng phó kịp thời với các sự cố bảo mật.

Kết luận

Duy trì bảo mật API là một nỗ lực liên tục. Nó không chỉ liên quan đến việc thực hiện các bước tích cực như tạo ra một thiết kế an toàn, đánh giá các mối đe dọa tiềm ẩn, củng cố hệ thống phòng thủ và thiết lập các biện pháp bảo vệ mà còn đòi hỏi sự quan sát, đánh giá, khắc phục và thông báo liên tục. Tuy nhiên, việc bảo vệ tài sản không xác định là không thể; do đó, hiểu biết toàn diện về tài nguyên của bạn và tầm quan trọng của top 10 Bảo mật API OWASP là điều cần thiết để ưu tiên các khía cạnh quan trọng và quản lý rủi ro tiềm ẩn một cách hiệu quả.