10 mối đe dọa hàng đầu trong Ứng dụng web của OWASP

Bạn đang xem tài liệu về Apigee Edge.
Chuyển đến tài liệu về Apigee X. thông tin

Tài liệu này mô tả nhiều phương pháp mà bạn có thể sử dụng trong Apigee để giải quyết các lỗ hổng bảo mật do OWASP xác định. Để biết thêm các phương pháp được ghi nhận cho Apigee, hãy xem bài viết 10 phương án giảm thiểu hàng đầu của OWASP năm 2021 trên Google Cloud.

Tổng quan

Hệ sinh thái API phải chịu nhiều cuộc tấn công từ cả ứng dụng bên ngoài và bên trong. Việc cung cấp và sử dụng API tạo ra nhiều cơ hội to lớn cho các nhà cung cấp dịch vụ, nhưng cũng gây ra một số rủi ro bảo mật. Nhà phát triển phải nhận biết được những thách thức này và giải quyết chúng khi tạo và sử dụng API.

OWASP là một cộng đồng mở chuyên giúp các tổ chức phát triển, mua và duy trì các ứng dụng và API đáng tin cậy. Thông qua dự án Bảo mật API của OWASP, OWASP công bố các rủi ro bảo mật nghiêm trọng nhất đối với ứng dụng web và API REST, đồng thời đưa ra các đề xuất để giải quyết những rủi ro đó.

Với Apigee, lớp proxy API có thể phát hiện, chặn và báo cáo các yêu cầu API không đúng định dạng từ ứng dụng trước khi các yêu cầu được xử lý trên hệ thống phụ trợ, nhờ đó giảm thiểu rủi ro và bảo vệ các dịch vụ của bạn. Yêu cầu có định dạng không hợp lệ có thể bao gồm bất kỳ thành phần nào tạo nên giao thức cấp ứng dụng HTTP:

  • URL
  • Tiêu đề
  • Đường dẫn
  • Dung lượng

Yêu cầu API không đúng định dạng có thể đến từ ứng dụng đã biết hoặc chưa biết do nhà phát triển bên ngoài, nhà phát triển nội bộ hoặc bot độc hại phát triển.  Các loại yêu cầu này chiếm phần lớn các mối đe doạ OWASP, nhưng có các thành phần bổ sung của lớp proxy API cơ bản có thể giảm thiểu rủi ro, chẳng hạn như ẩn dữ liệu, ghi nhật ký, quản trị, v.v.

Nền tảng quản lý API thông minh của Apigee giúp bạn giải quyết liền mạch các lỗ hổng bảo mật API hàng đầu của OWASP khi bạn áp dụng phương pháp tập trung vào việc sử dụng để thiết kế API và kết nối các API đó với hệ thống phụ trợ. Dưới đây là danh sách các chính sách/cấu hình mà Apigee đề xuất cho các mối đe doạ OWASP REST hàng đầu.

Giải pháp của Apigee cho 10 mối đe doạ hàng đầu của OWASP năm 2017

Có nhiều vấn đề bảo mật liên quan đến việc xây dựng và bảo mật ứng dụng web. OWASP đã phát hành danh sách 10 mối đe doạ bảo mật hàng đầu của OWASP năm 2017 cho các ứng dụng web.  Mặc dù có nhiều phần trong một ứng dụng web, nhưng hầu hết các ứng dụng web hiện đại đều phụ thuộc nhiều vào API REST.  Apigee không phải là công cụ xử lý mọi nhu cầu bảo mật của ứng dụng web, nhưng có thể đóng vai trò quan trọng trong việc bảo mật API REST. Sau đây là các mối đe doạ bảo mật hàng đầu của OWASP kèm theo nội dung mô tả cách bạn có thể sử dụng Apigee để giải quyết những mối đe doạ đó.

A1:2017 – Chèn

Để bảo vệ khỏi việc chèn dữ liệu không đáng tin cậy như SQL, NoSQL, LDAP và JavaScript, điều này có thể dẫn đến việc thực thi các lệnh ngoài ý muốn hoặc truy cập dữ liệu trái phép, Apigee cung cấp một số chính sách xác thực dữ liệu đầu vào để xác minh rằng các giá trị do ứng dụng cung cấp khớp với dự kiến trước khi cho phép xử lý thêm. Apigee Edge, đóng vai trò là máy chủ cho các yêu cầu API sắp tới, sẽ kiểm tra để đảm bảo rằng cấu trúc tải trọng nằm trong phạm vi chấp nhận được, còn gọi là kiểm tra giới hạn. Bạn có thể định cấu hình proxy API để quy trình xác thực dữ liệu đầu vào chuyển đổi dữ liệu đầu vào nhằm xoá các chuỗi ký tự có rủi ro và thay thế bằng các giá trị an toàn.

Có một số phương pháp để xác thực dữ liệu đầu vào bằng nền tảng Apigee:

Xác thực loại nội dung:

A2:2017 – Quản lý phiên và xác thực bị lỗi

Kẻ tấn công có thể truy cập vào mật khẩu, mã thông báo phiên và khoá để mạo danh người dùng khác bằng cách tận dụng các lỗi triển khai trong ứng dụng. Đây là vấn đề về cách triển khai hơn là vấn đề về sản phẩm.  Apigee cung cấp các chính sách VerifyApiKey, OAuth và JSON Web Token (JWT) giúp bảo vệ khỏi lỗ hổng này.

Xác thực khoá API

Xác thực khoá API là hình thức bảo mật dựa trên ứng dụng đơn giản nhất có thể được định cấu hình cho một API. Ứng dụng khách chỉ cần hiển thị một khoá API cùng với yêu cầu của ứng dụng, sau đó Apigee Edge, thông qua một chính sách đính kèm với proxy API, sẽ kiểm tra để đảm bảo khoá API đang ở trạng thái được phê duyệt cho tài nguyên đang được yêu cầu.

Apigee hỗ trợ việc tạo và xác thực Khoá API. Apigee tạo khoá API và khoá bí mật khi một ứng dụng dành cho nhà phát triển được tạo và phê duyệt, ứng dụng này được liên kết với một hoặc nhiều sản phẩm API.

Đôi khi, thuật ngữ "khoá API" có thể mang nhiều ý nghĩa. Trong Apigee, khi mối quan hệ giữa ứng dụng và sản phẩm được hình thành, Apigee sẽ tạo mã ứng dụng và khoá ứng dụng.  Một số người gọi cả mã nhận dạng và khoá bí mật là khoá API. Một số người chỉ gọi mã ứng dụng là khoá API. Trong giao diện người dùng Edge, bạn sẽ thấy "consumer key" (khoá người dùng) và "consumer secret" (mật khẩu người dùng).

Trong chính sách VerifyAPIKey, chỉ mã ứng dụng khách hoặc "khoá người dùng" mới được xác minh. Nhà phát triển sẽ nhận được khoá người dùng khi đăng ký ứng dụng của họ với Apigee và liên kết ứng dụng đó với một sản phẩm API. Nhà phát triển đưa khoá người dùng vào các lệnh gọi mà ứng dụng thực hiện đến proxy API được đóng gói trong sản phẩm API.

Apigee cũng hỗ trợ tính năng nhập khoá API hiện có từ các nguồn bên ngoài.

Đối với các loại cấp phép OAuth, cả mã ứng dụng và mật khẩu ứng dụng đều được sử dụng.

OAuth 2.0

Khung uỷ quyền OAuth 2.0 cho phép ứng dụng bên thứ ba có quyền truy cập hạn chế vào một dịch vụ HTTP, thay mặt cho chủ sở hữu tài nguyên bằng cách điều phối hoạt động tương tác phê duyệt giữa chủ sở hữu tài nguyên và dịch vụ HTTP hoặc bằng cách cho phép ứng dụng bên thứ ba tự lấy quyền truy cập.

Các chính sách OAuth 2.0 của Apigee cho phép bạn triển khai và tuỳ chỉnh 4 loại cấp quyền OAuth 2.0. Bạn có thể thực thi mã truy cập OAuth bằng cách sử dụng chính sách OAuthv2. Người dùng phải được đăng ký và có một ứng dụng được phê duyệt đã cấp cho họ quyền truy cập vào API. Đổi lại, họ sẽ nhận được mã ứng dụng khách API và mật khẩu ứng dụng khách. Người dùng phải trải qua một trong các quyền cấp OAuth để được xác thực, qua đó cấp cho họ một mã truy cập mờ. Bạn có thể dùng mã thông báo này để kiểm soát quyền truy cập vào API.

JWT

Mã thông báo web JSON (JWT) thường được dùng để chia sẻ các tuyên bố hoặc xác nhận giữa các ứng dụng đã kết nối. Apigee cung cấp dịch vụ hỗ trợ JWT bằng 3 chính sách.

  • Tạo mã thông báo JWT (hỗ trợ chữ ký HS256 và RS256)
  • Xác thực mã thông báo JWT
  • Giải mã mã thông báo JWT mà không xác thực

A3:2017 – Rò rỉ dữ liệu nhạy cảm

Kẻ tấn công nhắm đến dữ liệu nhạy cảm như thông tin thẻ tín dụng, số an sinh xã hội, thông tin đăng nhập, thông tin nhận dạng cá nhân (PII) và mã số thuế để thực hiện hành vi đánh cắp danh tính, đánh cắp tiền, lừa đảo và các tội phạm khác. Các ứng dụng web cần triển khai tính năng mã hoá, cả khi lưu trữ và khi truyền, cũng như các chiến lược khác để đảm bảo bảo vệ dữ liệu nhạy cảm.

TLS (Bảo mật tầng truyền tải, tiền thân là SSL) là công nghệ bảo mật chuẩn để thiết lập một đường liên kết được mã hoá giữa máy chủ web và ứng dụng web, chẳng hạn như trình duyệt hoặc ứng dụng. Apigee hỗ trợ cả TLS một chiều và hai chiều.

TLS hướng bắc (ứng dụng kết nối với API đóng vai trò là máy chủ) được hỗ trợ thông qua việc sử dụng cấu hình Máy chủ ảo. Bạn có thể định cấu hình máy chủ lưu trữ ảo cho TLS một chiều hoặc hai chiều.

TLS hướng Nam (apigee làm ứng dụng kết nối với dịch vụ phụ trợ) được hỗ trợ thông qua việc sử dụng cấu hình Máy chủ mục tiêu.  Bạn có thể định cấu hình Máy chủ mục tiêu cho TLS một chiều hoặc hai chiều.

Apigee hỗ trợ nhiều tuỳ chọn cấu hình TLS.

Việc thực thi TLS 2 chiều đảm bảo rằng máy khách đang sử dụng một chứng chỉ đã được đưa vào Apigee. OWASP cũng cung cấp các phương pháp hay nhất về TLS.

Trong Apigee lai, TLS có sẵn tại điểm truy cập thông qua bí danh máy chủ lưu trữ, đây là một khái niệm tương tự như máy chủ lưu trữ ảo.

Sau đây là các nguyên tắc bảo mật dữ liệu nhạy cảm:

  • Sử dụng một nền tảng hỗ trợ TLS một chiều và hai chiều. Nền tảng này sẽ bảo vệ ở cấp giao thức.
  • Sử dụng các chính sách như Chính sách AssignMessage và Chính sách JavaScript để xoá dữ liệu nhạy cảm trước khi dữ liệu đó được trả về cho ứng dụng.
  • Sử dụng các kỹ thuật OAuth tiêu chuẩn và cân nhắc thêm HMAC, hàm băm, trạng thái, số chỉ dùng một lần, PKCE hoặc các kỹ thuật khác để cải thiện mức độ xác thực cho mỗi yêu cầu.
  • Sử dụng chế độ cài đặt che dữ liệu để che dữ liệu nhạy cảm trong công cụ Theo dõi cạnh.
  • Hãy cẩn thận khi lưu trữ bất kỳ dữ liệu nhạy cảm nào trong bộ nhớ đệm (hoặc mã hoá dữ liệu nhạy cảm được lưu trữ trong bộ nhớ đệm). Trong Edge, bạn có thể mã hoá dữ liệu nhạy cảm ở trạng thái tĩnh trong bản đồ khoá-giá trị.

A4:2017 – Thực thể bên ngoài XML

Các hệ thống hoặc ứng dụng xử lý XML cần xử lý "tham chiếu thực thể bên ngoài" trong XML – tham chiếu đến các tệp hoặc dữ liệu được thay thế bằng dữ liệu thực tế trong quá trình xử lý XML. Nếu các ứng dụng hoặc trình xử lý XML đã cũ hoặc được triển khai không tốt, kẻ tấn công có thể xâm nhập dữ liệu và sử dụng dữ liệu đó để đánh cắp thông tin hoặc phát động nhiều loại cuộc tấn công vào hệ thống, chẳng hạn như từ chối dịch vụ.

Chính sách ExtractVariables của Apigee cho phép bạn trích xuất nội dung từ một yêu cầu hoặc phản hồi và gán nội dung đó cho một biến. Bạn có thể trích xuất bất kỳ phần nào của thông báo, bao gồm cả tiêu đề, đường dẫn URI, tải trọng JSON/XML, tham số biểu mẫu và tham số truy vấn. Chính sách này hoạt động bằng cách áp dụng một mẫu văn bản cho nội dung tin nhắn và khi tìm thấy nội dung trùng khớp, hãy đặt một biến bằng nội dung tin nhắn đã chỉ định.

Apigee có một trình phân tích cú pháp XML tích hợp sẵn trong nền tảng sử dụng XPath để trích xuất dữ liệu. API này cũng có chính sách XMLThreatProtection để bảo vệ khỏi các tải trọng XML độc hại.

A5:2017 – Lỗi kiểm soát quyền truy cập

Sau khi người dùng đăng nhập và có quyền truy cập vào một hệ thống, bạn cần có các biện pháp kiểm soát uỷ quyền thích hợp để người dùng chỉ có thể xem và làm những việc mà họ được phép. Nếu không có các biện pháp kiểm soát quyền truy cập mạnh mẽ, kẻ tấn công có thể xem dữ liệu trái phép và thường là dữ liệu nhạy cảm hoặc thao túng dữ liệu và hành vi của hệ thống theo cách độc hại.

Apigee hỗ trợ phương pháp phân lớp để triển khai các biện pháp kiểm soát quyền truy cập nhằm ngăn chặn các bên xấu thực hiện các thay đổi trái phép hoặc truy cập vào hệ thống.

Chế độ kiểm soát quyền truy cập cho giao diện người dùng Edge

Chế độ kiểm soát quyền truy cập vào Cổng nhà phát triển Apigee

Các chế độ kiểm soát quyền truy cập vào API thời gian chạy Apigee

  • Bạn có thể thực thi quyền truy cập vào API thông qua khoá API, mã thông báo OAuth, phạm vi OAuth, chứng chỉ và các kỹ thuật khác.
  • Nhà cung cấp API định cấu hình những tài nguyên có sẵn bằng cách xác định một sản phẩm API. Quyền truy cập được cấp theo cách thủ công trong giao diện người dùng, thông qua API quản lý hoặc thông qua cổng thông tin dành cho nhà phát triển. Khi ứng dụng của nhà phát triển được cấp quyền truy cập vào một sản phẩm API, họ sẽ nhận được mã ứng dụng và khoá bí mật được dùng trong quy trình xác thực.
  • Apigee có thể tích hợp với bất kỳ nhà cung cấp danh tính nào để thực hiện OAuth.
  • Apigee có thể tạo mã thông báo JWT hoặc các kỹ thuật khác để gửi danh tính người dùng đến các dịch vụ mục tiêu. Các dịch vụ mục tiêu có thể sử dụng danh tính đó để hạn chế quyền truy cập vào các dịch vụ và dữ liệu nếu cần.

A6:2017-Cấu hình bảo mật sai

Việc định cấu hình sai bảo mật rất dễ bị bỏ qua, thường là do quản trị viên và nhà phát triển tin tưởng nhầm rằng hệ thống mà họ sử dụng vốn đã an toàn. Việc định cấu hình bảo mật không chính xác có thể xảy ra theo nhiều cách, chẳng hạn như tin tưởng các cấu hình mặc định hoặc tạo một số cấu hình có thể không an toàn, để thông báo lỗi chứa thông tin nhạy cảm, lưu trữ dữ liệu trên đám mây mà không có biện pháp kiểm soát bảo mật thích hợp, định cấu hình không chính xác tiêu đề HTTP, v.v. Nền tảng Apigee cung cấp một số cơ chế để cho phép bạn kiểm soát, quản lý và theo dõi các cấu hình bảo mật, bao gồm cả các luồng dùng chung có thể sử dụng lại.

Luồng dùng chung cho phép nhà phát triển API kết hợp các chính sách và tài nguyên thành một nhóm có thể sử dụng lại. Bằng cách thu thập chức năng có thể sử dụng lại ở một nơi, luồng dùng chung giúp bạn đảm bảo tính nhất quán, rút ngắn thời gian phát triển và dễ dàng quản lý mã hơn. Bạn có thể đưa một luồng dùng chung vào bên trong các proxy API riêng lẻ, hoặc bạn có thể tiến thêm một bước nữa và đặt các luồng dùng chung vào lệnh gọi luồng để tự động thực thi logic luồng dùng chung cho mọi proxy API được triển khai trong cùng một môi trường với luồng dùng chung.

Các bản phát hành sản phẩm Apigee đảm bảo bảo vệ khỏi các thư viện có lỗ hổng. Apigee có thể phát hành các bản vá hoặc bản cập nhật bổ sung nếu phát hiện thấy lỗ hổng mới. Đám mây công khai của Edge được vá tự động. Khách hàng sử dụng Edge for Private Cloud (tại chỗ) phải tự áp dụng các bản vá sản phẩm.

A7:2017-Tập lệnh trên nhiều trang web (XSS)

Lỗ hổng tập lệnh trên nhiều trang web (XSS) cho phép kẻ tấn công thực thi tập lệnh trong trình duyệt web của người dùng để kiểm soát phiên hoạt động của người dùng, thao túng trang web hoặc tác động độc hại đến người dùng theo những cách khác. Các vấn đề về XSS không nhất thiết phải liên quan đến API, nhưng Apigee cung cấp các chính sách bảo vệ mối đe doạ có thể được tận dụng để bảo vệ chống lại XSS trong API.  Sử dụng biểu thức chính quy, với chính sách RegularExpressionProtection hoặc chính sách JavaScript, hãy kiểm tra tải trọng và giá trị thông số cho JavaScript và các cuộc tấn công khác thuộc loại chèn.

CORS, một trong những giải pháp thường được triển khai cho chính sách cùng nguồn gốc do tất cả trình duyệt thực thi, có thể được triển khai bằng cách sử dụng chính sách AssignMessage.

A8:2017 – Huỷ chuyển đổi tuần tự không an toàn

Những kẻ tấn công có thể sử dụng các lỗ hổng trong quá trình giải mã tuần tự cho nhiều loại cuộc tấn công, chẳng hạn như phát lại, nâng cao đặc quyền và chèn. Việc giải mã không an toàn cũng có thể cho phép thực thi mã từ xa.

Apigee không khuyến khích giải mã tuần tự. Tuy nhiên, chính sách JSONThreatProtection và chính sách RegularExpressionProtection có thể giúp bảo vệ khỏi các tải trọng JSON độc hại. Bạn cũng có thể dùng chính sách về JavaScript để quét trọng tải nhằm tìm nội dung độc hại. Bạn có thể sử dụng bộ nhớ đệm và các chính sách khác để bảo vệ khỏi các cuộc tấn công phát lại. Ở cấp cơ sở hạ tầng, nền tảng Apigee cũng tích hợp các hàng rào để bảo vệ các quy trình đang chạy.

A9:2017 – Sử dụng các thành phần có lỗ hổng đã biết

Vì các khung, thư viện và mô-đun chạy với quyền truy cập CRUD và thực thi đầy đủ, nên kẻ tấn công có thể tận dụng các lỗ hổng thành phần để tấn công hệ thống.

Các bản phát hành sản phẩm thường xuyên của Apigee đảm bảo khả năng bảo vệ khỏi các lỗ hổng thành phần, đặc biệt là khi phát hiện các lỗ hổng cụ thể. Đám mây công khai của Apigee được vá tự động và Apigee sẽ thông báo cho khách hàng sử dụng Edge cho đám mây riêng tư khi có bản vá tại chỗ để cài đặt.

A10:2017 – Không đủ tính năng ghi nhật ký và giám sát

Khi bạn không thực hiện đầy đủ việc ghi nhật ký, giám sát và quản lý sự cố trong hệ thống, kẻ tấn công có thể thực hiện các cuộc tấn công sâu hơn và kéo dài hơn vào dữ liệu và phần mềm.

Apigee có một số cách để ghi nhật ký, giám sát, xử lý lỗi và ghi nhật ký kiểm tra.

Ghi nhật ký

  • Bạn có thể gửi thông điệp nhật ký đến Splunk hoặc điểm cuối syslog khác bằng cách sử dụng chính sách MessageLogging.
  • Bạn có thể lấy dữ liệu phân tích API thông qua API phân tích và nhập hoặc xuất dữ liệu đó sang các hệ thống khác.
  • Trong Edge cho Private Cloud, bạn có thể sử dụng chính sách MessageLogging để ghi vào tệp nhật ký cục bộ. Bạn cũng có thể xem tệp nhật ký của từng thành phần đang chạy.
  • Bạn có thể sử dụng chính sách JavaScript để gửi thông điệp nhật ký đến điểm cuối ghi nhật ký REST đồng bộ hoặc không đồng bộ.

Giám sát

  • Sử dụng giao diện người dùng hoặc API Theo dõi API để thường xuyên theo dõi các API và phần phụ trợ cũng như kích hoạt các lệnh gọi.
  • Sử dụng tính năng giám sát tình trạng để thường xuyên theo dõi phần phụ trợ của máy chủ mục tiêu.
  • Apigee đưa ra các đề xuất để giám sát Edge cho Private Cloud.
  • Apigee cũng cung cấp các phương pháp hay nhất mà nhóm của bạn có thể tận dụng để theo dõi chương trình API.

Xử lý lỗi

Apigee cung cấp một cơ chế xử lý lỗi mạnh mẽ, linh hoạt cho các proxy API. Tương tự như cách một chương trình Java phát hiện ngoại lệ, các proxy API có thể phát hiện lỗi và xác định cách trả về phản hồi thích hợp cho ứng dụng khách. Tính năng xử lý lỗi tuỳ chỉnh của Apigee cho phép bạn thêm chức năng như ghi nhật ký thông báo bất cứ khi nào xảy ra lỗi.

Nhật ký kiểm tra

Nền tảng Apigee lưu giữ nhật ký kiểm tra theo dõi các thay đổi đối với proxy API, sản phẩm và nhật ký tổ chức.  Bạn có thể xem nhật ký này thông qua giao diện người dùng hoặc thông qua API Kiểm tra.

Giải pháp của Apigee cho các lỗ hổng OWASP năm 2013

Khi OWASP cập nhật danh sách của họ cho năm 2017, một số lỗ hổng trong danh sách năm 2013 đã bị loại bỏ. Tuy nhiên, các lỗ hổng này vẫn là mối đe doạ hợp lệ. Các phần sau đây mô tả cách xử lý các mối đe doạ này bằng Apigee.

A8:2013 – Giả mạo yêu cầu trên nhiều trang web (CSRF)

Yêu cầu giả mạo trên nhiều trang web cho phép kẻ tấn công chuyển tiếp thông tin xác thực, cookie phiên và dữ liệu khác của người dùng đến một ứng dụng web dễ bị tấn công qua HTTP, lừa ứng dụng web tin rằng các yêu cầu đó là yêu cầu hợp lệ của người dùng.

Nguyên tắc:

  • Đây là vấn đề về trình duyệt chứ không phải vấn đề về sản phẩm API. Bạn có thể giải quyết lỗ hổng này bằng OpenID Connect, OAuth và các kỹ thuật khác.
  • Cân nhắc sử dụng các kỹ thuật HMAC, trạng thái, hàm băm, số chỉ dùng một lần hoặc PKCE để ngăn chặn các cuộc tấn công giả mạo và phát lại.

A10:2013 – Lệnh chuyển hướng và chuyển tiếp chưa được xác thực

Nếu một ứng dụng web thực hiện lệnh chuyển hướng nhưng không xác thực rằng lệnh chuyển hướng đó đang đưa người dùng đến các trang web đáng tin cậy và dự kiến, thì kẻ tấn công có thể đưa người dùng đến các đích độc hại để thực hiện hành vi lừa đảo, thực thi phần mềm độc hại và các cuộc tấn công khác.

Nguyên tắc:

  • Sử dụng OAuth và thực thi quy trình xác thực tại mỗi yêu cầu.
  • Ngăn chặn các lệnh chuyển hướng 302 không mong muốn bằng cách kiểm tra mã phản hồi trong logic proxy API và xử lý các lệnh chuyển hướng một cách thích hợp.