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.
Truy cập vào tài liệu 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 các phương pháp khác được ghi lại cho Apigee, hãy xem Các lựa chọn giảm thiểu OWASP Top 10 2021 trên Google Cloud.

Tổng quan

Hệ sinh thái API phải đối mặt với nhiều cuộc tấn công từ cả máy khách 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 cho các nhà cung cấp dịch vụ, nhưng cũng tiềm ẩn một số rủi ro bảo mật. Nhà phát triển phải nhận thức đượ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 cũng như API đáng tin cậy. Thông qua dự án Bảo mật API của OWASP, OWASP công bố những rủi ro bảo mật nghiêm trọng nhất đối với các ứ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 bị lỗi từ máy khách 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 không đúng định dạng có thể bao gồm mọi thành phần tạo nên giao thức ở cấp ứng dụng HTTP:

  • URL
  • Tiêu đề
  • Đường dẫn
  • Phần tải

Yêu cầu API không đúng định dạng có thể đến từ các ứ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 tạo ra.  Những loại yêu cầu này chiếm phần lớn các mối đe doạ OWASP, nhưng có thêm các thành phần của lớp proxy API cơ bản có thể giảm thiểu rủi ro, chẳng hạn như che 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 chúng với các hệ thống phụ trợ. Sau đâ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ạ REST hàng đầu của OWASP.

Các 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 mối lo ngại về bảo mật khi xây dựng và bảo mật các ứ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 có nghĩa là xử lý mọi nhu cầu bảo mật của một ứng dụng web, nhưng có thể đóng vai trò quan trọng trong việc bảo mật các 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ả về cách bạn có thể sử dụng Apigee để giúp giải quyết những mối đe doạ đó.

A1:2017 – Injection (Tiêm mã độc)

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

A2:2017 – Xác thực và quản lý phiên có vấn đề

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 khai thác các lỗi triển khai trong ứng dụng. Đây là vấn đề về việc triển khai chứ không phải 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 mà bạn có thể định cấu hình cho một API. Ứng dụng khách chỉ cần xuất hiện 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 được đính kèm vào một proxy API, sẽ kiểm tra để đảm bảo rằng khoá API ở 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á và bí mật API khi một ứng dụng nhà phát triển được tạo và phê duyệt, ứng dụng đó được liên kết với một hoặc nhiều sản phẩm API.

Thuật ngữ "khoá API" đôi khi 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ột mã ứng dụng và khoá bí mật ứ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 "khoá của người dùng:" và "khoá bí mật của người dùng".

Trong chính sách VerifyAPIKey, chỉ có mã ứng dụng khách hoặc "khoá của người dùng:" được xác minh. Nhà phát triển sẽ nhận được một khoá của 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á của người dùng: vào các lệnh gọi mà ứng dụng thực hiện đến các proxy API được đi kèm trong sản phẩm API.

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

Đối với các loại cấp OAuth, cả mã ứng dụng khách và khoá bí mật đều được dùng.

OAuth 2.0

Khung uỷ quyền OAuth 2.0 cho phép một ứng dụng bên thứ ba có đượ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 một 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 có được quyền truy cập thay mặt cho chính ứng dụng đó.

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 quyền sử dụng OAuth 2.0. Bạn có thể thực thi mã truy cập OAuth bằ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 API và khoá bí mật của ứng dụng. Người tiêu dùng phải trải qua một trong các cấp OAuth để được xác thực, cấp này sẽ cấp cho họ một mã truy cập không công khai. 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 yêu cầu hoặc khẳng định giữa các ứng dụng được kết nối. Apigee cung cấp hỗ trợ JWT bằng 3 chính sách.

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

A3:2017 – Lộ 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, gian lận và các tội ác khác. Các ứng dụng web cần triển khai phương thức 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 tiêu chuẩn để thiết lập một đường liên kết được mã hoá giữa máy chủ web và máy khách 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ủ ảo cho TLS một chiều hoặc hai chiều.

TLS chiều nam (apigee là một ứ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 Target Server (Máy chủ đích).  Bạn có thể định cấu hình Máy chủ đích cho TLS một chiều hoặc hai chiều.

Apigee hỗ trợ nhiều lựa 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 tích hợp vào Apigee. OWASP cũng cung cấp các phương pháp hay nhất về TLS.

Trong Apigee hybrid, TLS có sẵn tại cổng vào thông qua một 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 máy khách.
  • Sử dụng các kỹ thuật OAuth tiêu chuẩn và cân nhắc việ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 từng 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ụ Edge Trace.
  • Hãy cẩn thận khi lưu trữ mọi dữ liệu nhạy cảm 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 khi không hoạt động trong các 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 – các tham chiếu đến 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 kém, thì 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 thực hiện 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à chỉ định 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, chính sách sẽ đặt một biến có nội dung tin nhắn được chỉ định.

Apigee có một trình phân tích cú pháp XML tích hợp trong nền tảng sử dụng XPath để trích xuất dữ liệu. Nó cũng có chính sách XMLThreatProtection để ngăn chặn các tải trọng XML độc hại.

A5:2017 – Kiểm soát quyền truy cập bị lỗi

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 phải thiết lập các chế độ 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 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 hệ thống một cách độc hại.

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

Quyền kiểm soát truy cập cho giao diện người dùng Edge

Kiểm soát quyền truy cập vào Cổng nhà phát triển Apigee

Quyền kiểm soát truy cập để 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 các 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 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 khách 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 mọi nhà cung cấp danh tính để 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 khi cần.

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

Lỗi cấu hình 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 nhầm tưởng rằng các hệ thống mà họ sử dụng vốn dĩ đã an toàn. Cấu hình sai về bảo mật có thể xảy ra theo nhiều cách khác nhau, chẳng hạn như tin tưởng cấu hình mặc định hoặc tạo cấu hình một phần có thể không an toàn, cho phép thông báo lỗi chứa thông tin chi tiết nhạy cảm, lưu trữ dữ liệu trên đám mây mà không có các biện pháp kiểm soát bảo mật thích hợp, định cấu hình sai tiêu đề HTTP, v.v. Nền tảng Apigee cung cấp một số cơ chế để bạn kiểm soát, quản lý và giám sát 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.

Một 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ể dùng lại. Bằng cách ghi lại chức năng có thể 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à quản lý mã dễ dàng hơn. Bạn có thể đưa một quy trình dùng chung vào bên trong từng 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 quy trình dùng chung trong các lệnh gọi quy trình để tự động thực thi logic quy trình dùng chung cho mọi proxy API được triển khai trong cùng một môi trường dưới dạng một quy trình dùng chung.

Các bản phát hành sản phẩm Apigee đảm bảo khả năng 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 các lỗ hổng mới. Đám mây công cộng biên được vá tự động. Khách hàng sử dụng Edge for Private Cloud (tại cơ sở) 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)

Tấn cô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 các phiên người dùng, thao túng trang web hoặc gây ảnh hưở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ệ khỏi mối đe doạ mà bạn có thể tận dụng để chống lại XSS trong API.  Sử dụng biểu thức chính quy, bằng chính sách RegularExpressionProtection hoặc chính sách JavaScript, hãy kiểm tra tải trọng và giá trị tham số đối với JavaScript và các cuộc tấn công kiểu chèn khác.

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

A8:2017 – Phân tích cú pháp không an toàn

Kẻ tấn công có thể sử dụng các lỗ hổng trong quá trình chuyển đổi tuần tự thành song song cho nhiều loại cuộc tấn công, chẳng hạn như phát lại, leo thang đặc quyền và chèn mã. Việc giải tuần tự hoá 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 việc khử tuần tự hoá. Tuy nhiên, chính sách JSONThreatProtection và chính sách RegularExpressionProtection có thể giúp bảo vệ khỏi tải trọng JSON độc hại. Bạn cũng có thể dùng chính sách JavaScript để quét tải trọng 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 có các biện pháp bảo vệ được tích hợp sẵn để 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 thực thi và CRUD đầy đủ, nên kẻ tấn công có thể khai thác các lỗ hổng của 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ệ trước các lỗ hổng bảo mật của thành phần, đặc biệt là khi phát hiện thấy các lỗ hổng bảo mật cụ thể. Đám mây công cộng Apigee được vá tự động và Apigee thông báo cho khách hàng Edge cho Đám mây riêng tư khi có các bản vá tại chỗ để cài đặt.

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

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 của mình, 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 đối với dữ liệu và phần mềm.

Apigee có nhiều cách để thực hiện việc 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 báo 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 đó vào các hệ thống khác.
  • Trong Edge cho Đám mây riêng tư, bạn có thể sử dụng chính sách MessageLogging để ghi vào các tệp nhật ký cục bộ. Các tệp nhật ký của từng thành phần đang chạy cũng có sẵn.
  • Bạn có thể dùng chính sách JavaScript để gửi thông báo nhật ký đến một điểm cuối ghi nhật ký REST một cách đồ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 Giám sát API để thường xuyên giám sát các API và phần phụ trợ, đồng thời kích hoạt cảnh báo.
  • Sử dụng tính năng giám sát tình trạng sức khoẻ để thường xuyên giám sát các phần phụ trợ của máy chủ đích.
  • Apigee cung cấp đề 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 để giám sát chương trình API.

Xử lý lỗi

Apigee cung cấp một cơ chế xử lý lỗi mạnh mẽ và linh hoạt cho các proxy API. Tương tự như cách một chương trình Java sẽ bắt các ngoại lệ, các proxy API có thể bắt lỗi và xác định cách trả về các phản hồi thích hợp cho máy khách. Tính năng xử lý lỗi tuỳ chỉnh của Apigee cho phép bạn thêm các 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ữ một nhật ký kiểm tra để theo dõi các thay đổi đối với các 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 Audits API.

Giải pháp của Apigee cho các lỗ hổng bảo mật 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 bảo mật trong danh sách năm 2013 đã bị loại bỏ. Tuy nhiên, chúng vẫn là những mối đe doạ hợp lệ. Các phần sau đây mô tả cách xử lý những 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 của phiên và các 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 gửi người dùng đến các trang web đáng tin cậy, dự kiến, thì kẻ tấn công có thể gửi người dùng đến các đích đến độ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 ở 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 của proxy API và xử lý các lệnh chuyển hướng một cách thích hợp.