Với số lượngngày càng tăng của các mối đe dọa an ninh mạng, kiểm thử bảo mật đã trở nên quantrọng hơn bao giờ hết.Lợi ích chính của kiểm thử bảo mật là phát hiện các lỗ hổng và điểm yếu
TỔNG QUAN VỀ KIỂM THỬ BẢO MẬT VÀ VẤN ĐỀ KIỂM THỬ TRÊN MICROSERVICES
Tổng quan về kiểm thử bảo mật
1.1.1 Khái niệm kiểm thử bảo mật
Kiểm thử bảo mật là một loại kiểm thử phần mềm, là quá trình đánh giá tính bảo mật của một hệ thống hoặc ứng dụng bằng cách xác định và đánh giá các lỗ hổng và mối đe dọa tiềm ẩn
Mục tiêu lớn nhất là để đảm bảo rằng ứng dụng và hệ thống không bị truy cập trái phép, đánh cắp dữ liệu, có thể chống được các cuộc tấn công hoặc các vi phạm bảo mật khác Kiểm thử bảo mật giúp xác định các mối đe dọa trong hệ thống và đo lường các lỗ hổng tiềm ẩn của nó, để hệ thống không ngừng hoạt động hoặc bị khai thác Nó cũng giúp phát hiện tất cả các rủi ro bảo mật có thể có trong hệ thống và giúp các nhà phát triển khắc phục các sự cố này thông qua mã hóa.
Kiểm thử bảo mật có thể được thực hiện ở nhiều giai đoạn khác nhau của 1 vòng đời phát triển phần mềm, các giai đoạn này bao gồm giai đoạn thu thập yêu cầu, thiết kế, mã hóa và thử nghiệm Việc này cũng có thể được thực hiện theo định kì sau khi hệ thống hoặc ứng dụng đã được triển khai để có thể đảm bảo rằng tất cả đều được an toàn.
1.1.2 Tầm quan trọng của kiểm thử bảo mật
Kiểm thử bảo mật là một quy trình quan trọng của quá trình phát triển phần mềm giúp đảm bảo tính bảo mật của phần mềm, ứng dụng, hệ thống Với số lượng ngày càng tăng của các mối đe dọa an ninh mạng, kiểm thử bảo mật đã trở nên quan trọng hơn bao giờ hết.
Lợi ích chính của kiểm thử bảo mật là phát hiện các lỗ hổng và điểm yếu trong hệ thống hoặc ứng dụng một cách kịp thời, trước khi chúng bị kẻ tấn công khai thác. Điều này giúp cho các tổ chức có thể giảm thiểu các rủi ro rò rỉ dữ liệu, bảo vệ các dữ liệu nhạy cảm và duy trì được lòng tin của khách hàng.
Việc kiểm thử bảo mật cũng giúp các tổ chức đáp ứng các yêu cầu tuân thủ quy định, điều này có thể rất quan trọng đối với các ngành như chăm sóc sức khỏe,tài chính, chính phủ Các quy định tuân thủ yêu cầu các tổ chức thực hiện các biện pháp thích hợp nhằm bảo mật hệ thống và dữ liệu, và kiểm thử bảo mật là một phần cần thiết để đáp ứng các yêu cầu đó.
Một lợi ích khác đó là giúp giảm thiểu chi phí phát triển phần mềm Bằng việc xác định sớm các lỗ hổng bảo mật trong chu kỳ phát triển, các tổ chức sẽ không cần tốn kém tiền bạc và thời gian để làm lại, bên cạnh đó là các thiệt hại pháp lý hoặc uy tín tiềm ẩn do vi phạm dữ liệu.
Cuối cùng, kiểm thử bảo mật giúp các tổ chức cải thiện tình trạng bảo mật tổng thể của họ Bằng cách liên tục kiểm thử và cải thiện hệ thống của mình, các tổ chức có thể vượt qua các mối đe dọa mới nổi và duy trì khả năng phòng thủ mạnh mẽ trước các cuộc tấn công mạng.
Tóm lại, kiểm tra bảo mật là điều cần thiết để bảo vệ dữ liệu nhạy cảm, đáp ứng các yêu cầu quy định, giảm chi phí phát triển và cải thiện tình hình bảo mật tổng thể Khi các mối đe dọa mạng tiếp tục phát triển, các tổ chức phải ưu tiên kiểm tra bảo mật để đảm bảo an toàn và bảo mật cho hệ thống và dữ liệu của họ.
Bảo mật dữ liệu và an ninh mạng rất quan trọng trong thế giới ngày nay vì ngày càng có nhiều thông tin nhạy cảm được lưu trữ và truyền bằng kỹ thuật số, có thể bị tội phạm mạng truy cập và khai thác, có khả năng gây hại đáng kể cho các cá nhân, tổ chức và toàn xã hội.
1.1.3 Các kỹ thuật kiểm thử bảo mật
Fuzz testing (fuzzing) là kỹ thuật được dùng trong kiểm thử phần mềm, bằng cách gửi dữ liệu ngẫu nhiên không mong muốn đến hệ thống hoặc ứng dụng để tìm các lỗ hổng bảo mật và lỗi lập trình. Để thực hiện fuzz testing có thể dùng các công cụ tự động để tạo và gửi một dữ liệu lớn đến phần mềm đang thực nghiệm Các input có thể là ngẫu nhiên hoặc biến đổi một cách có hệ thống từ các input có sẵn Mục đích là để kiểm tra tính mạnh mẽ của phần mềm đối với những dữ liệu đầu vào không mong muốn hoặc không hợp lệ mà phần mềm có thể nhận được trong thực tế.
Mục tiêu của fuzz testing là xác định các lỗ hổng như tràn bộ đệm, ngoại lệ chưa được xử lý và các lỗi khác có thể bị kẻ tấn công khai thác Bằng cách kiểm tra cách hệ thống phản ứng với đầu vào không mong muốn, có thể nhìn ra được những điểm yếu mà các phương pháp khác không thể chỉ ra được.
Injection testing là kỹ thuật được sử dụng để tìm ra các lỗ hổng liên quan đến việc xác thực đầu vào Kỹ thuật này được thiết kế để xác định và khai thác lỗ hổng cho phép kẻ tấn công đưa mã độc hoặc lệnh vào hệ thống thông qua các ô tìm kiếm,biểu mẫu đăng nhập hoặc tham số truy vấn cơ sở dữ liệu.
Injection testing có nhiều kiểu khác nhau, bao gồm SQL injection, kịch bản chéo trang (XSS) và tiêm lệnh.
SQL injection là kỹ thuật cho phép kẻ tấn công chèn mã SQL vào các trường nhập liệu trong hệ thống và có thể trích xuất hoặc sửa đổi dữ liệu nhạy cảm được lưu trữ trong cơ sở dữ liệu.
Các cuộc tấn công XSS liên quan đến việc đưa các tập lệnh độc hại hoặc các đoạn mã độc vào bên trong trang web, điều này cho phép kẻ tấn công đánh cắp thông tin đăng nhập của người dùng hoặc kiểm soát tài khoản người dùng
Tổng quan về Microservices
Microservices là một kiến trúc phần mềm phân tán, trong đó các ứng dụng được phân chia thành các thành phần nhỏ hơn và độc lập với nhau, được gọi là các microservice Mỗi microservice đảm nhiệm một chức năng cụ thể trong hệ thống và có thể được phát triển, triển khai và quản lý độc lập với các microservice khác.Với kiến trúc microservices, các ứng dụng phần mềm được xây dựng thành nhiều phần nhỏ hơn, dễ dàng quản lý và mở rộng hơn Mỗi microservice có thể được phát triển độc lập, sử dụng các công nghệ và ngôn ngữ lập trình khác nhau và có thể được phát triển bởi các nhóm phát triển khác nhau Các microservice có thể được triển khai và quản lý độc lập, và có thể được sử dụng lại cho các ứng dụng khác nhau.Kiến trúc microservices giúp giảm thiểu sự phụ thuộc giữa các thành phần,tăng tính mô-đun, cải thiện tính linh hoạt và dễ dàng mở rộng hệ thống Tuy nhiên,cần có sự quản lý và giám sát kỹ lưỡng để đảm bảo tính đồng bộ và đảm bảo rằng các microservice hoạt động đúng cách với nhau.
1.2.2 Mô hình kiến trúc Microservices
Hình 1 1 Mô hình kiến trúc Micorservices
Sơ đồ trên là một thể hiện của mô hình microservice Trên thực tế mô hình microservice được áp dụng vào các sản phẩm có rất nhiều biến thể, sẽ rất khó để có một mô hình phù hợp và chính xác cho từng bài toán.
Theo kiến trúc trên, một ứng dụng được chia thành một bộ các microservice, mỗi microservice thực chất là một service có thể được triển khai và chạy độc lập. Chúng tách biệt về mặt mã nguồn, về hoạt động và dữ liệu Mỗi microservice có nơi chứa dữ liệu của riêng của nó và chỉ có nó có quyền truy cập vào vùng dữ liệu này.
Do các microservice là độc lập, chúng không giao tiếp trực tiếp với nhau mà qua một thành phần trung gian được gọi là API gateway Có thể thấy vai trò của API gateway rất quan trọng trong mô hình microservice Nó là điểm đến và đi của mọi yêu cầu hay phản hồi.
1.2.3 Các đặc trưng của mô hình Microservices
Hầu hết các kiến trúc microservices đều có một vài đặc điểm chung sau đây:
- Triển khai độc lập: Mỗi microservice có thể được triển khai một cách độc lập với các dịch vụ khác, cho phép linh hoạt hơn trong việc phát triển, và có thể thay đổi một dịch vụ mà không lo sợ ảnh hưởng đến các dịch vụ khác cũng như ứng dụng lớn.
- Đơn trách nhiệm: Mỗi một microservice sẽ chịu trách nhiệm cho một chức năng duy nhất Tức là mỗi microservice được thiết kế để thực hiện một nhiệm vụ cụ thể và chúng ta có thể dễ dàng tối ưu hóa cho nhiệm vụ đó.
- Liên kết lỏng lẻo: Microservice được ghép nối với nhau một cách lỏng lẻo, có nghĩa là chúng có thể giao tiếp với nhau mà không cần tích hợp một cách chặt chẽ Vì vậy nên chúng ta có thể thay đổi một dịch vụ mà không sợ ảnh hưởng đến dịch vụ khác.
- Dựa trên API: Các microservice giao tiếp với nhau và với các máy khách bằng cách sử dụng API Điều này cho phép mỗi microservice hiển thị chức năng riêng của nó cho các service khác theo hướng tiêu chuẩn.
- Đa ngôn ngữ: Microservices có thể được phát triển bằng nhiều ngôn ngữ lập trình và framework khác nhau Điều này cho phép các nhà phát triển sử dụng công cụ tốt nhất cho công việc, thay vì bị hạn chế bởi một nhóm công nghệ duy nhất
- Tính đóng gói: Microservices thường được triển khai bằng cách sử dụng các công nghệ đóng gói như Docker Điều này cho phép mỗi microservices được đóng gói và triển khai dưới dạng một đơn vị độc lập, bao gồm tất cả các phần con của nó.
- Khả năng mở rộng: Kiến trúc microservices có khả năng mở rộng cao, cho phép các ứng dụng phát triển và thích ứng với nhu cầu thay đổi Điều này là do mỗi microservices có thể thay đổi quy mô độc lập với các microservices khác, cho phép ứng dụng được tối ưu hóa với các khối lượng công việc cụ thể.
- Khả năng chịu lỗi: Vì các microservices được thiết kế độc lập và liên kết lỏng nên chúng có thể thay thế hoặc thay đổi quy mô để đối phó với lỗi hoặc các vấn đề về hiệu suất mà không ảnh hưởng đến phần còn lại của ứng dụng Điều này khiến cho kiến trúc microservices có khả năng chịu lỗi cao.
1.2.4 Các ưu và nhược điểm của Microservice a Ưu điểm:
Chi phí thấp – Hiệu quả cao: Các ứng dụng sử dụng microservice thường đơn giản và có hiệu quả cao hơn so với các ứng dụng sử dụng kiến trúc nguyên khối nên tổng chi phí thường sẽ thấp hơn Ngoài ra, vì các dịch vụ nhỏ độc lập với nhau nên chúng không yêu cầu mức độ liên kết và giao tiếp cao giống các ứng dụng nguyên khối Microservice cũng cải thiện hiệu quả và giảm số lượng lỗi bằng cách cho phép các dịch vụ khác nhau sử dụng các công nghệ phù hợp khác nhau.
Tăng tính linh hoạt và khả năng mở rộng: Microservice được triển khai theo dạng mô đun nhỏ nên chúng có thể được triển khai nhanh hơn so với ứng dụng nguyên khối Sự linh hoạt này là một lợi thế lớn cho các tổ chức, công ty cần phản ứng nhanh với những thay đổi của thị trường Vì các dịch vụ nhỏ được phát triển riêng biệt, nên các nhà phát triển có thể mở rộng, thêm bớt dịch vụ mà không sợ làm ảnh hưởng đến toàn bộ ứng dụng.
Bảo trì và cập nhật dễ dàng: Vì microservice nhỏ và độc lập, mỗi dịch vụ sẽ chịu trách nhiệm cho một số tác vụ cụ thể nên ít có khả năng xảy ra lỗi khi thực hiện cập nhật Điều này làm cho việc bảo trì và cập nhật ít rủi ro và đỡ tốn thời gian hơn.
Bài toán kiểm thử trên Microservices
1.3.1 Khảo sát các vấn đề an toàn, bảo mật trong Microservices a Những thách thức hàng đầu về bảo mật Microservices
Vì bản chất của kiến trúc microservices đặc biệt nên việc bảo mật nó là 1 thách thức rất lớn Có khá nhiều khó khăn trong việc bảo mật trên microservice:
Bề mặt giao tiếp càng rộng nguy cơ bị tấn công càng cao: Khác với 1 ứng dụng monolithic giao tiếp giữa các thành phần diễn ra trong một quy trình đơn lẻ thì với microservices giao tiếp giữa các thành phần được thiết kế 1 cách độc lập riêng biệt với mỗi microservice và mỗi microservice lại có các cách nhận request và các công truy cập riêng biệt Thay vì có 1 vài cổng truy cập nhất định như monolithic thì với microservice số lượng cổng truy cập được nhân lên rất nhiều lần Và với số lượng cổng truy cập tăng thì nguy cơ bị tấn công cũng tăng theo Tình trạng này trở thành 1 trong những thách thức cơ bản trong vấn đề bảo mật của microservice Vì thế nên mỗi cổng truy cập đều phải được bảo vệ như nhau để hệ thống được bảo vệ một cách tốt nhất.
Kiểm soát bảo mật phân tán có thể dẫn đến hiệu suất kém: Khác với monolithic mỗi microservice phải được kiểm tra bảo mật 1 cách độc lập, ở góc nhìn của 1 ứng dụng monolithic nơi việc kiểm tra bảo mật được thực hiện 1 lần và các yêu cầu sẽ được gửi đến các thành phần tương ứng thì việc kiểm tra bảo mật ở mỗi cổng truy cập của từng microservice có vẻ như là dư thừa Ngoài ra trong khi xác thực các yêu cầu ở mỗi microservice ta đôi khi cần phải kết nối tới service bảo mật token Những lần kiểm tra bảo mật lặp lại này cùng với các kết nối có thể làm giảm đáng kể hiệu suất của hệ thống Một số hệ thống đã giải quyết vấn đề này bằng cách tin vào mạng và tránh kiểm tra từng microservice vì vậy theo thời gian nguyên tắc mạng tin cậy đã trở thành 1 nguyên mẫu nhưng hiện tại ngành công nghiệp đang hướng tới nguyên tắc mạng không tin cậy Ở đây mọi microservice đều phải xem xét hiệu suất tổng thể và thực hiện các biện pháp phòng ngừa để giải quyết triệt để các nhược điểm.
Sự phức tạp trong việc triển khai bootstrapping trust giữa các microservice khó khăn: Ngoài việc bảo mật việc quản lý 10-15 hay hàng trăm service độc lập sẽ khó như thế nào Việc quản lý các microservice quy mô lớn sẽ vô cùng khó khăn nếu ta không biết các tự động hoá May mắn thay, ta đã có sự giúp đỡ của các container như docker để giúp đỡ việc này.
Việc các request trải rộng trên nhiều service sẽ khó để theo dõi hơn: Khả năng quan sát sẽ là thước đo để ta có thể suy luận về trang thái của hệ thống dựa trên các kết quả đầu ra của nó Logs, metrics và traces là 3 khái niệm cơ bản của khả năng quan sát:
Logs là các sự kiện được ta ghi lại tương ứng với các service nhất định Qua việc tổng hợp các logs ta sẽ tạo ra các metrics Theo 1 khía cạnh nào đó, metrics chính là các số liệu ánh xạ trạng thái của hệ thống.
Ví dụ: số lượng truy cập không hợp lệ trong 1h cao bất thường điều này phản ảnh có thể hệ thống đang bị tấn công qua đó ta có thể config một giá trị nhất định cho số lần đăng nhập không hợp lệ, nếu quá hệ thống sẽ kích hoạt cảnh báo Traces cũng được dựa trên logs nhưng cung cấp 1 góc nhìn khác về hệ thống,việc tracing giúp bạn theo dõi các request từ khi nó đi vào hệ thống cho đến khi ra.Việc này cũng có thể trở nên rất khó với microservice bởi 1 request có thể vào từ 1 microservice và lan toả ra nhiều service khác Việc liên kết giữa các yêu cầu trong microservice cũng là 1 thách thức.
Tính bất biến của vùng chứa cũng là 1 thách thức khi ta duy trì thông tin đăng nhập service và chính sách kiểm soát đăng nhập: Mẫu triển khai phổ biến nhất của microservice là 1 container, mà 1 container theo phương pháp hay nhất nên là 1 máy chủ không thay đổi trạng thái sau khi khởi động, nói cách khác 1 container một khi đã xuất hiện thì sẽ không thay đổi bất kì tệp nào trong hệ thống tệp của nó, hoặc duy trì bất cứ trạng thái thời gian trong chính container đó Điều này giúp việc triển khai microservice trở nên rõ ràng và đơn giản.
Trong kiến trúc bảo mật của microservice bản thân mỗi microservice là 1 điểm thực thi bảo mật và với 1 máy chủ không thay đổi ta không thể duy trì các bản cập nhật Mỗi microservice cũng phải duy trì thông tin xác thực của riêng mình, chẳng hạn như chứng chỉ Để bảo mật tốt hơn, các thông tin đăng nhập này cần được luân phiên định kỳ Bạn có thể giữ chúng cùng với chính microservice nhưng bạn nên có cách đưa chúng vào microservice tại thời điểm nó khởi động Với các máy chủ không thay đổi, quy trình này có thể là một phần của quy trình phân phối liên tục mà không cần đưa thông tin đăng nhập vào chính microservice
Kiến trúc Polyglot đòi hỏi nhiều chuyên môn bảo mật hơn đối với mỗi team developer: Trong quá trình triển khai microservices, các dịch vụ giao tiếp với nhau qua mạng Chúng không phụ thuộc vào việc triển khai của từng dịch vụ mà phụ thuộc vào giao diện dịch vụ Tình huống này cho phép mỗi microservice chọn ngôn ngữ lập trình và framework của riêng mình để triển khai Trong môi trường nhiều team, trong đó mỗi team phát triển microservices của riêng mình, mỗi team có thể linh hoạt chọn nhóm công nghệ tối ưu cho các yêu cầu của mình Kiến trúc này, cho phép các thành phần khác nhau trong hệ thống chọn framework phù hợp nhất với chúng, được gọi là kiến trúc đa ngôn ngữ
Kiến trúc đa ngôn ngữ khiến vấn đề bảo mật trở nên khó khăn Bởi vì các nhóm khác nhau sử dụng các framework khác nhau để phát triển nên mỗi nhóm phải có các chuyên gia bảo mật của riêng mình Các chuyên gia này phải chịu trách nhiệm xác định các hướng dẫn và thực tiễn bảo mật tốt nhất, nghiên cứu các công cụ bảo mật cho từng framework để phân tích code và kiểm thử động, đồng thời tích hợp các công cụ đó vào quy trình xây dựng. b Các lỗ hổng API trong Microservices
Trong mô hình Microservices, API (Application Programming Interface) là cầu nối chính giữa các microservice, và chúng cũng là điểm tiếp xúc với bên ngoài hệ thống Do đó, việc bảo vệ API là một vấn đề quan trọng để đảm bảo an toàn và bảo mật trong môi trường Microservices Dưới đây là một số lỗ hổng thường gặp trong API của Microservices:
- Thiếu kiểm tra đầu vào: Đây là một lỗ hổng phổ biến khi các API không kiểm tra và xác thực đầu vào một cách đầy đủ Các kiểm tra đầu vào, chẳng hạn như kiểm tra định dạng, kiểm tra đối số và kiểm tra giá trị, giúp ngăn chặn các cuộc tấn công như injection hoặc tấn công từ chối dịch vụ (DoS).
- Quản lý xác thực yếu: Việc xác thực là quan trọng để đảm bảo rằng chỉ có người dùng được ủy quyền mới có thể truy cập vào các API Tuy nhiên, trong một số trường hợp, cơ chế xác thực yếu, như sử dụng mật khẩu yếu, không có xác thực hai yếu tố hoặc không kiểm tra đúng cơ chế xác thực, có thể dẫn đến việc tấn công như tấn công Brute Force hoặc tấn công tràn bộ nhớ đệm.
- Lỗ hổng phân quyền: Việc quản lý phân quyền là quan trọng để đảm bảo rằng người dùng chỉ có quyền truy cập vào những API mà họ được ủy quyền Một lỗ hổng phân quyền có thể dẫn đến việc người dùng có thể truy cập và thao tác với dữ liệu hoặc chức năng mà họ không được phép.
Kết luận chương 1
Chương 1 của đồ án đã trình bày tổng quan về kiểm thử bảo mật và vấn đề kiểm thử bảo mật trên microservices, đưa ra các khái niệm, kỹ thuật, quy trình và các loại kiểm thử bảo mật Bên cạnh đó, tìm hiểu chuyên sâu về kiến trúc microservices, bài toán kiểm thử bảo mật trên microservices Đây là cơ sở lý thuyết để tiến hành tìm hiểu và triển khai nghiên cứu kỹ thuật kiểm thử an toàn sẽ được trình bày ở chương 2 dưới đây.
NGHIÊN CỨU KỸ THUẬT KIỂM THỬ AN TOÀN TRÊN MICROSERVICES
Kỹ thuật kiểm thử tính đáp ứng API
2.1.1 Mô hình API gateway a Khái niệm
API Gateway là một công cụ quản lý API nằm giữa các client (máy khách) và các backend service Có thể xem API Gateway như một cánh cổng trung gian, đồng thời là cổng vào duy nhất tới hệ thống Microservices API Gateway chấp nhận tất cả request và lệnh call API từ client Sau đó API Gateway sẽ chỉnh sửa, xác thực, điều hướng chúng đến các Microservices phía sau và tìm nạp, tổng hợp tài nguyên thích hợp để gửi phản hồi cho các request Thông thường, API Gateway xử lý một request bằng cách gọi nhiều Microservices và tổng hợp lại để xác định đường dẫn tốt nhất. Các trang web thương mại điện tử có thể sử dụng API Gateway cung cấp cho các client di động một endpoint nhằm truy xuất tất cả chi tiết của một sản phẩm chỉ với một request API Gateway sẽ gọi cho nhiều service khác nhau, như thông tin và đánh giá sản phẩm, sau đó tổng hợp kết quả. b Các thành phần của API Gateway
Một API Gateway gồm có các thành phần như sau:
- Thành phần API và tiến trình API (API composition and processing)
- Quản lý hạn mức truy cập (Managing access quotas)
- Theo dõi tình trạng của API (API health monitoring)
2.1.2 Kong API Gateway a Vai trò của Kong API Gateway
Kong API Gateway có vai trò quan trọng trong việc quản lý và giám sát các API Nó đóng vai trò như một cánh cửa (gateway) giữa các ứng dụng, dịch vụ và khách hàng, giúp tạo ra một lớp trung gian giữa các thành phần khác nhau của hệ thống và quản lý lưu lượng API
Vai trò chính của Kong API Gateway là giúp quản lý, bảo mật, giám sát và tối ưu hóa các API trong hệ thống.
Hình 2 1 Kong API Gateway b Chức năng của API Gateway
Một số chức năng chính của Kong API Gateway:
- Quản lý API: Kong API Gateway cho phép quản lý các API trong hệ thống, bao gồm quản lý các URL, tài nguyên, đối tượng và chức năng API Nó cung cấp giao diện quản lý trực quan để giúp người dùng quản lý các tài nguyên này.
- Bảo mật API: Kong API Gateway hỗ trợ nhiều phương thức bảo mật để bảo vệ các API khỏi các cuộc tấn công và lộ thông tin Các phương thức bảo mật này bao gồm JWT, OAuth2, Basic Authentication và API Key.
- Phân phối tải: Kong API Gateway có tính năng phân phối tải để giảm thiểu tải cho các máy chủ backend và tăng hiệu suất hệ thống Nó có thể điều chỉnh tải theo nhiều cách khác nhau, bao gồm định tuyến dựa trên vị trí, định tuyến dựa trên nội dung và định tuyến dựa trên người dùng.
- Chuyển đổi giao thức: Kong API Gateway có thể chuyển đổi giao thức của các API để cho phép các ứng dụng khác nhau có thể truy cập API bằng các phương thức khác nhau Các giao thức mà nó hỗ trợ bao gồm HTTP, HTTPS, WebSockets và TCP.
- Quản lý định tuyến: Kong API Gateway có tính năng quản lý định tuyến để định tuyến yêu cầu API đến các máy chủ backend phù hợp Nó hỗ trợ nhiều loại định tuyến khác nhau, bao gồm định tuyến cơ bản, định tuyến theo nội dung và định tuyến dựa trên người dùng.
- Giám sát API: Kong API Gateway có tính năng giám sát API để giúp người dùng theo dõi hiệu suất và sử dụng các API Nó cung cấp các báo cáo và thông tin chi tiết về lưu lượng và sử dụng API.
- Plugin tùy chỉnh: Kong API Gateway cung cấp nhiều plugin để giúp người dùng tùy chỉnh các chức năng của Gateway và mở rộng các tính năng của nó.
Thêm vào đó, Kong API Gateway còn có khả năng tích hợp với các công nghệ khác để tạo ra một hệ thống đầy đủ tính năng Ví dụ, nó có thể tích hợp với các công nghệ như Docker, Kubernetes, Cassandra, và Redis để tạo ra một hệ thống phân phối tải và khả năng mở rộng tốt hơn. c Những lợi ích khi sử dụng API Gateway
Kong Gateway là nền tảng mã nguồn mở, do đó nó miễn phí Ngoài ra, một số lợi ích tiêu biểu của Kong Gateway là:
- Kong là nền tảng có thể mở rộng nhanh chóng, hiệu năng cao
- Dễ dàng tích hợp vào các hệ thống hiện có.
- Được xây dựng bằng công nghệ đáng tin cậy như NGINX, Apache Cassandra hoặc PostgreSQL.
- Có thể mở rộng chức năng thông qua các plugin đa dạng.
- Có thể được triển khai trên đám mây hoặc vật lý.
- Sử dụng thị trường API lớn của Kong Inc API hiện có.
Hình 2 2 Kong API Gateway là nền tảng có thể mở rộng nhanh chóng d Nhược điểm của Kong API Gateway
Mặc dù Kong API Gateway có nhiều ưu điểm, nhưng cũng có một số nhược điểm cần được lưu ý Dưới đây là một số nhược điểm của Kong API Gateway:
- Khó cấu hình: Cấu hình Kong API Gateway có thể rất phức tạp đối với những người mới bắt đầu Điều này đặc biệt đúng nếu bạn không có kinh nghiệm với các công nghệ mạng và hệ thống phân tán.
- Tốn thời gian để cài đặt: Việc cài đặt Kong API Gateway và tích hợp nó vào hệ thống có thể mất một khoảng thời gian đáng kể Điều này đặc biệt đúng đối với các tổ chức lớn hoặc các hệ thống phức tạp.
- Không có tính năng gateway truyền thống: Kong API Gateway không cung cấp tất cả các tính năng của một gateway truyền thống, ví dụ như các tính năng VPN hoặc tường lửa
- Phụ thuộc vào các plugin bên thứ ba: Mặc dù Kong API Gateway cung cấp một số plugin tích hợp sẵn, nhưng nhiều tính năng phải được cung cấp bởi các plugin bên thứ ba Điều này có thể dẫn đến sự phụ thuộc vào các plugin không chính thức hoặc có thể gây ra các vấn đề về tương thích.
- Không hoàn toàn mã nguồn mở: Mặc dù Kong API Gateway được xây dựng trên nền tảng mã nguồn mở, nhưng phiên bản Enterprise của nó có một số tính năng bản quyền và phải trả phí sử dụng.
Kỹ thuật kiểm thử tính tương thích
2.2.1 Bài toán kiểm thử tính tương thích của hệ API trên mô hình API gateway Kiểm thử tính tương thích của hệ API trên mô hình API Gateway là một bước quan trọng để đảm bảo rằng hệ thống hoạt động đúng và đáp ứng được các yêu cầu của người dùng Dưới đây là một số phương pháp kiểm thử tính tương thích của hệ API trên mô hình API Gateway:
- Kiểm thử tính tương thích của các API endpoints: Kiểm tra tính tương thích của các API endpoints với các yêu cầu và phản hồi của chúng trên API Gateway Sử dụng các công cụ kiểm thử API như Postman, Insomnia hoặc cURL để gửi các yêu cầu và xác định xem phản hồi từ API Gateway có đúng với các yêu cầu của hệ thống hay không Để kiểm tra tính tương thích của API hệ thống trên cổng API mô hình, bạn có thể thực hiện các bước sau:
- Xác định các điểm cuối API của hệ thống và xác định các yêu cầu và phản hồi cho từng điểm cuối.
- Tạo một bộ dữ liệu kiểm tra đại diện cho các yêu cầu khác nhau tới các điểm cuối API Bộ dữ liệu này nên bao gồm các trường hợp bình thường và các trường hợp đặc biệt như lỗi và giá trị biên của các tham số.
- Khai thác API Gateway và liên kết các API endpoints của hệ thống với các endpoint trên Gateway.
- Sử dụng một công cụ kiểm tra API như Postman hoặc Insomnia để gửi các yêu cầu trong bộ dữ liệu kiểm tra tới các điểm cuối trên Cổng API.
- Kiểm tra phản hồi từ các điểm cuối API và đảm bảo rằng chúng tương thích với các yêu cầu đã được định nghĩa trước đó.
- Kiểm tra các lỗi và trường hợp đặc biệt để đảm bảo rằng hệ thống trả lời đúng các mã lỗi và phản hồi cho các trường hợp này.
- Lặp lại các bước trên cho tất cả các điểm cuối API của hệ thống và đảm bảo rằng tất cả các yêu cầu đều được trả lời đúng trên API Gateway.
Ngoài ra, cần đảm bảo rằng API Gateway được cấu hình đúng để trả lời các yêu cầu và phản hồi của hệ thống Các tiêu chí kiểm tra cần tập trung vào độ tin cậy, hiệu suất và bảo mật của API Gateway.
2.2.2 Kỹ thuật tích hợp API service trên gateway
Khi tích hợp API service trên gateway, có nhiều kỹ thuật khác nhau để lựa chọn Dưới đây là một số kỹ thuật phổ biến để tích hợp API service trên gateway:
- Reverse Proxy: Đây là kỹ thuật đơn giản nhất trong các kỹ thuật tích hợp API service trên gateway Các request từ client được định tuyến đến gateway, sau đó gateway sử dụng proxy server để chuyển tiếp request đến API service tương ứng Reverse Proxy cung cấp một số tính năng như phân tán tải và bộ nhớ đệm, tuy nhiên, nó không thể xử lý các request phức tạp hơn.
- API Gateway: Đây là kỹ thuật phức tạp hơn so với Reverse Proxy API
Gateway là một dịch vụ trung tâm định tuyến các request từ client đến các API service tương ứng API Gateway có thể xử lý các request phức tạp hơn, cung cấp chức năng xác thực và phân quyền, và cho phép triển khai các chính sách bảo mật phức tạp.
- Service Mesh: Đây là một kiến trúc phân tán trong đó các dịch vụ liên lạc trực tiếp với nhau thông qua một mạng lưới proxy sidecar Service Mesh cung cấp khả năng quản lý dịch vụ phức tạp, phân tán tải, bảo mật và theo dõi, tuy nhiên, nó yêu cầu sử dụng các proxy sidecar trong mỗi dịch vụ, do đó làm tăng chi phí vận hành.
Khi lựa chọn kỹ thuật tích hợp API service trên gateway, cần xem xét các yêu cầu và đặc điểm của hệ thống, cũng như các tính năng mà mỗi kỹ thuật cung cấp để chọn phương pháp tốt nhất.
Thiết kế của API gateway bao gồm ba yếu tố: bản thân cổng API, ứng dụng API client và nền tảng tự phục vụ hỗ trợ Một vai trò quan trọng của cổng API là tất cả khách hàng và người tiêu dùng truy cập vào các vi dịch vụ thông qua một cổng hợp nhất và xử lý tất cả các chức năng phi kinh doanh ở lớp cổng Thông thường, cổng cũng cung cấp API truy cập REST/HTTP Máy chủ đăng ký và quản lý dịch vụ thông qua Cổng API Lấy cổng API dịch vụ nền tảng làm ví dụ, nó có thể được chia thành hai phần: hệ thống con tác nhân yêu cầu dịch vụ và hệ thống con quản lý cổng. Đồng thời, nó tương tác với trung tâm xác thực dịch vụ nền tảng để xử lý xác thực yêu cầu dịch vụ Mặt khác, thông tin phiên bản dịch vụ và thông tin giao diện được tải từ trung tâm đăng ký dịch vụ nền tảng Kiến trúc của cổng API dịch vụ nền tảng được hiển thị trong hình.
2.2.2.3 Hệ thống con yêu cầu cổng API dịch vụ nền tảng
Hệ thống con quản lý cổng dựa trên nền tảng gói gọn logic nghiệp vụ chính vào các vi dịch vụ và triển khai cũng như bảo trì một cách độc lập Giao diện quản lý của cổng API được tích hợp vào nền tảng quản lý tích hợp để quản lý, kết hợp với Spring Web để triển khai quản lý API, quản lý quyền, kiểm soát luồng, giám sát hệ thống và các chức năng khác thông qua kiến trúc ba tầng: Dịch vụ, Dịch vụ nội bộ, và DAO Nghĩa là, trung tâm khám phá và đăng ký dịch vụ có thể đồng bộ hóa thông tin dịch vụ và thông tin giao diện của Microservices trong thời gian thực, đồng thời hỗ trợ nhân viên quản lý thêm giao diện API theo cách thủ công Kiến trúc logic nghiệp vụ của hệ thống cổng API cổng dịch vụ nền tảng và phân tách giao diện cổng thông tin cũng là cách tiếp cận kiến trúc của các dịch vụ siêu nhỏ và các dịch vụ được kết hợp trong một kịch bản dịch vụ siêu nhỏ Một cổng thông tin doanh nghiệp tự do kết hợp nhiều dịch vụ siêu nhỏ để triển khai các chức năng kinh doanh nhất định, đạt được sự tách rời các giao diện và logic nghiệp vụ phức tạp, đồng thời đảm bảo quy mô và phạm vi hợp lý của một dự án Đây cũng là điểm khác biệt giữa cách tiếp cận kiến trúc vi dịch vụ và kiến trúc nguyên khối.
2.2.2.4 Thiết kế chi tiết Để xác thực cổng API, giám sát, cân bằng tải, lưu vào bộ nhớ đệm, cắt và quản lý yêu cầu, xử lý phản hồi tĩnh, v.v Công nghệ cổng API không khó tiếp cận. Tuy nhiên, để thực hành tốt nhất, việc thiết kế Thực hiện chức năng chính là rất quan trọng Ví dụ: lựa chọn chế độ xác thực cổng, chức năng xác minh quyền, chức năng kiểm soát luồng, chức năng viết lại URL, chuyển tiếp proxy yêu cầu cổng API dịch vụ, hệ thống quản lý nền cổng API, triển khai chức năng kiểm soát luồng cấp người dùng giao diện dịch vụ cấu hình.
Hiện tại trong Microservices, API bảo vệ chỉ cần được gọi bởi những khách hàng đã đồng ý ủy quyền Hiện tại, hầu hết các phương thức được sử dụng thuộc ba loại: AppKeys, OAuth2 và OAuth2+JWT Các phương thức xác thực này có những đặc điểm và ưu điểm riêng:
Kỹ thuật kiểm thử một số tấn công lên Microservices
2.3.1 Giới thiệu công cụ kiểm thử tính bảo mật Microservices
Kiểm tra bảo mật được thực hiện để đảm bảo rằng dữ liệu trong một hệ thống thông tin được bảo vệ và người dùng trái phép không thể truy cập được Nó bảo vệ các ứng dụng khỏi phần mềm độc hại nghiêm trọng và các mối đe dọa không lường trước khác có thể làm hỏng ứng dụng.
Kiểm tra bảo mật giúp tìm ra tất cả các lỗ hổng và điểm yếu của hệ thống trong giai đoạn ban đầu Nó được thực hiện để kiểm tra xem ứng dụng đã mã hóa mã bảo mật hay chưa và không thể truy cập được bởi người dùng trái phép.
Công cụ Invicti, ngoài việc sử dụng để kiểm thử ứng dụng web nói chung nó còn hỗ trợ kiểm tra bảo mật của dịch vụ Microservice Chức năng đầu tiên phải kể đến của nó là dò quét phổ biến quét thông tin qua đường dẫn URL là một trình quét tự động chính xác các lỗ hổng như SQL Injection và Cross-site Scripting trong các ứng dụng web và API web, bao gồm cả những ứng dụng được phát triển bằng CMS nguồn mở trong đó có cả Microservice Người dùng có thể dùng để kiểm thử các phương thức xác thức như: đăng nhập, JSON Web Token (JWT), kiểm tra lỗi truy cập bộ đệm, kiểm tra tính bảo mật của các API của bên thứ ba (bên mà ta sử dụng API của họ để tích hợp vào ứng dụng hoặc hệ thống của bạn), kiểm tra sự thay đổi và cập nhật phần mềm các bản vá của Microservices Invicti có khả năng chính xác cho kết quả chứng minh các lỗ hổng là có thật, vì vậy ta không cần phải lãng phí hàng giờ để xác minh thủ công các lỗ hổng đã xác định sau khi quá trình quét kết thúc, các lỗi Về việc cài đặt thì nó có sẵn dưới dạng phần mềm Windows và dịch vụ trực tuyến Do tiền thân của nó là Acunetix nên nó được tích hợp với Acunetix Online để cung cấp kiểm tra an ninh mạng chu vi toàn diện dựa trên kiểm toán ứng dụng web Acunetix, với mục tiêu chính của kiểm toán bảo mật là xác định các lỗ hổng, rủi ro và sự không tuân thủ các tiêu chuẩn, quy trình và các yêu cầu bảo mật đã được thiết lập. b Cơ chế thực thi
Cơ chế thực thi của Invicti dựa trên việc kết hợp sự tự động hóa và kiểm tra thủ công để đảm bảo rằng các lỗ hổng bảo mật trong ứng dụng web được phát hiện và khắc phục một cách hiệu quả,dựa trên việc kiểm tra bảo mật ứng dụng web bằng cách tìm kiếm các lỗ hổng và các điểm yếu có thể bị tấn công trong mã nguồn và cấu trúc của ứng dụng Quá trình kiểm tra bảo mật bắt đầu bằng việc Invicti quét toàn bộ ứng dụng web, phân tích các yếu tố bảo mật như trường nhập dữ liệu, quyền truy cập, xử lý lỗi, và cấu trúc hệ thống Khi các lỗ hổng được phát hiện, Invicti cung cấp thông tin chi tiết về vấn đề và đề xuất các biện pháp khắc phục Điều này giúp nhóm phát triển và quản lý bảo mật của một tổ chức có thể nắm bắt và giải quyết các lỗ hổng bảo mật trong ứng dụng web của họ c Ví dụ
Khi sử dụng Invicti để kiểm tra lỗ hổng mã nguồn mới như một phần của quy trình phát triển web, bạn có thể dễ dàng thiết lập cấu hình quét có thể tái sử dụng cho một trang web Sau đó, bạn chỉ cần nhấp vào Quét (nếu bắt đầu quét thủ công) và chờ kết quả.
Hình 2 3 Bảng báo cáo kết quả dò quét của Invicti
Ta thấy hình ảnh kết quả báo cáo khá trực quan, các màu sắc thể hiện phân loại các lỗ hổng và kèm theo biểu đồ Các vấn đề được tự động phân loại theo mức độ tác động của lỗ hổng Các lỗ hổng sau khi được xác nhận bởi Invicti bao gồm thông tin như: cách lỗ hổng được khai thác trong quá trình thử nghiệm để nhằm xác định nguyên nhân và ngoài ra nó còn đưa ra các hướng dẫn khắc phục rõ ràng.Dưới đây là 1 kết quả lỗ hổng chi tiết
Hình 2 4 Kết quả dò quét phát hiện XSS
Nhìn vào kết quả quét XSS, bạn sẽ nhận được thông tin chi tiết về lỗ hổng, JavaScript đã được đưa thành công vào ứng dụng trong quá trình thử nghiệm để kiểm thử XSS và biến đoạn URL thực thi ban đầu thành URL với XSS, Bằng cách lần theo dấu vết trở lại trang và tham số có liên quan, ta có thể nhanh chóng xác định vị trí mã dễ bị tấn công
Là một công cụ kiểm tra tính bảo mật của tập tin trung tâm để kiểm tra ứng dụng Web, nhưng cũng có thể được sử dụng để kiểm tra các dịch vụ API và microservice.
2.3.2 Kịch bản kiểm thử tấn công sql injection với SQLi
Các lỗ hổng SQL injection phát sinh khi dữ liệu do người dùng kiểm soát được kết hợp vào các truy vấn SQL của cơ sở dữ liệu theo cách không an toàn Kẻ tấn công có thể cung cấp đầu vào được tạo thủ công để thoát ra khỏi ngữ cảnh dữ liệu mà đầu vào của chúng xuất hiện và can thiệp vào cấu trúc của truy vấn xung quanh Một loạt các cuộc tấn công gây hại thường có thể được thực hiện thông qua SQL injection, bao gồm đọc hoặc sửa đổi dữ liệu ứng dụng quan trọng, can thiệp vào logic ứng dụng, leo thang đặc quyền trong cơ sở dữ liệu và kiểm soát máy chủ cơ sở dữ liệu. Để kiểm thử tấn công SQL Injection bằng SQLi, bạn có thể làm theo các bước sau:
Bước 1: Tìm một trang web có chức năng truy vấn cơ sở dữ liệu Để kiểm thử tấn công SQL Injection, bạn cần tìm một trang web có chức năng truy vấn cơ sở dữ liệu Các trang web này thường có một trường tìm kiếm hoặc một biểu mẫu để người dùng có thể nhập thông tin vào.
Bước 2: Sử dụng SQLi để thực hiện tấn công
Sau khi tìm được trang web cần kiểm thử tấn công, bạn có thể sử dụng SQLi để thực hiện tấn công SQLi là một kỹ thuật tấn công bằng cách chèn câu lệnh SQL độc hại vào các trường nhập liệu Khi được thực thi, câu lệnh SQL độc hại này sẽ cho phép kẻ tấn công truy cập và thao túng cơ sở dữ liệu.
Ví dụ, nếu trang web có một trường tìm kiếm với URL như sau: http://example.com/search.php?q=search_term
Bạn có thể sử dụng SQLi để thực hiện tấn công bằng cách thêm các câu lệnh SQL độc hại vào tham số "search_term" Ví dụ: http://example.com/search.php?q=' or 1=1
Trong ví dụ trên, bạn đã chèn một đoạn mã SQL độc hại vào tham số
"search_term" Cụ thể, đoạn mã này là "' or 1=1 " Đoạn mã này sẽ cho phép kẻ tấn công truy cập tất cả các dữ liệu trong cơ sở dữ liệu bởi vì điều kiện "1=1" luôn đúng. Bước 3: Xác nhận việc tấn công thành công
Sau khi thực hiện tấn công, bạn cần xác nhận xem việc tấn công đã thành công hay chưa Bạn có thể kiểm tra các bản ghi trả về từ cơ sở dữ liệu để xem liệu kẻ tấn công đã có thể truy cập được thông tin không Tuy nhiên, bạn không nên sử dụng SQLi để tấn công các trang web khác mà không được phép, bởi vì đây là hành vi bất hợp pháp và có thể gây ra hậu quả nghiêm trọng Nếu bạn muốn tìm hiểu thêm về SQLi, bạn nên tìm các tài liệu và nguồn tham khảo từ các nguồn đáng tin cậy. 2.3.3 Nghiên cứu công cụ Burpsuite trong kiểm thử service
Burp Scanner có khả năng phân tích cú pháp các định nghĩa API - nghĩa là nó có thể tìm và kiểm tra các API bị ẩn đối với nhiều trình quét lỗ hổng Điều này cải thiện khả năng hiển thị tình trạng bảo mật của bạn và tiết kiệm thời gian cho người kiểm tra.
Kết luận chương 2
Chương 2 của đồ án đã trình bày về các kỹ thuật kiểm thử an toàn và các công cụ kiểm thử bảo mật trên microservices Đây là cơ sở lý thuyết để tiến hành tìm hiểu và triển khai thực nghiệm kiểm thử an toàn được trình bày ở chương 3 dưới đây.
THỰC NGHIỆM VỚI MỘT HỆ THỐNG MICROSERVICES
3.1 Giới thiệu hệ thống tìm việc làm
3.1.1 Khái quát về hệ thống tìm việc làm
Ngày nay trên thị trường các ngành nghề việt nam việt nam phải nói rằng ngành công nghệ thông tin luôn có xu hướng dẫn đầu Việc phát triển các hệ thống phần mềm lớn nhỏ hay từ các website các App moblie cho đến Desktop với những mục đích sử dụng khác nhau Từ thành thị đến nông thôn, từ miền sông đến miền núi mạng máy tính đã kết nối cho chúng ta dẫn đến những tiện nghi Trước kia chúng ta có thể đăng ký tìm việc làm hay các tạp chí báo, các tờ rơi, nhưng bây giờ xu thể thay đổi có thể tìm việc làm qua thông tin internet, qua các trang mạng xã hội như dựa vào các bài đăng trên facebook Và dần dần để chuyên nghiệp hơn gần đây những hệ thống đăng ký việc làm đang phát triển dẫn đến cho chúng ta những điều thuận tiện Hệ thống tìm việc làm sẽ có các tính năng tạo ra các CV đẹp mắt hơn. Chúng ta có thể thuận tiện tìm kiếm công việc có thể dựa theo mức lương, dựa vào địa điểm hoặc dựa vào kinh nghiệp Hệ thống luông update những công việc thịnh hành có nhu cầu tuyển dụng cao, những top công việc dẫn dầu có xu thể nắm bắt chung Để làm được điều đó thống được triển khai kết nối dữ liệu linh hoạt với phía nhà tuyển dụng và phía người dùng Người sử dụng có thể tạo CV đăng ký việc làm, tham khảo về thông tin về công ty, để từ đó đăng ký lựa chọn công việc Tuy mỗi công ty đều có các website riêng để quảng cáo thương hiệu của nó, cũng từ đó các ứng viên người tìm việc dựa vào mục tuyển dụng để tìm hiểu đăng ký nhưng việc tạo 1 website riêng sẽ là 1 kênh truy cập chung Tuy việc này có thể gây ra sự thiếu minh bạch đồng bộ giữa các bài đăng tuyển dụng giữa phía hệ thống tìm việc và website công ty, nhưng nó cũng phần nào thuận tiện cho các ứng viên.
3.1.2 Khảo sát các vấn đề an toàn trong hệ thống tìm việc làm
Trong vấn đề tạo lập website thì sẽ không tránh khỏi việc thiết sót trong lập trình Vì vậy vấn đề kiểm thử website là điều vô cùng quan trọng để phát hiện các lỗ hổng bảo mật theo kiến trúc microservice Vì đây là việc tạo lập website theo microserive sẽ có đặc điểm khác so với kiến trúc truyền thống hay các kiến trúc khác
Hệ thống tìm việc làm gồm một số các vấn đề về bảo mật chung như:
- Bảo mật thông tin cá nhân, nguy cơ rò rỉ dữ liệu
- Nguy cơ bị tấn công mạng và các lỗ hổng
- Các yếu tố bảo mật trong thanh toán
- Vấn đề trong kiến trúc thiết kế ví dụ như việc phát triển thêm các service cho hệ thống cần cân nhắc kiểm thử trước muốn tích hợp vào hệ thống.
3.1.3 Bài toán kiểm thử hệ thống tìm việc làm
Bài toán kiểm thử bảo mật hệ thống tìm việc làm có thể được thực hiện để đảm bảo rằng hệ thống đó đáp ứng các yêu cầu bảo mật cần thiết và không chứa lỗ hổng nào có thể bị khai thác để xâm nhập hoặc tấn công.
Dưới đây là một số bước cơ bản trong quá trình kiểm thử bảo mật hệ thống tìm việc làm:
Xác định các yêu cầu bảo mật: Đầu tiên, xác định các yêu cầu bảo mật cụ thể cho hệ thống tìm việc làm Điều này có thể bao gồm quản lý truy cập, xác thực người dùng, bảo vệ thông tin cá nhân, bảo mật giao tiếp và các vấn đề khác.
Thiết kế kiểm thử: Xác định các kịch bản kiểm thử bảo mật dựa trên các yêu cầu đã xác định Các kịch bản này có thể bao gồm việc kiểm tra tính bảo mật của hệ thống đối với các hành vi xâm nhập, tấn công bằng cách sử dụng các phương pháp phá hoại như SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), hoặc kiểm tra sự bảo mật của việc xác thực và quản lý phiên.
Thực hiện kiểm thử: Thực hiện các kịch bản kiểm thử bảo mật Đảm bảo việc kiểm thử được thực hiện trong một môi trường cô lập để tránh gây hại cho hệ thống thực tế hoặc dữ liệu người dùng.
Phân tích kết quả: Xem xét kết quả kiểm thử và xác định các lỗ hổng bảo mật và vấn đề khác mà hệ thống có thể gặp phải Bao gồm cả việc kiểm tra tính bảo mật của dữ liệu người dùng và khả năng bảo mật của cơ sở dữ liệu.
Công cụ sử dụng: Burpsuite, Apache Jmeter
Client kiểm thử->KongGateway-> System WebServer
Hình 3 1 Sơ đồ mô tả hệ thống kiểm thử Địa chỉ IP của Kong Gateway:
- Kong service: http://192.168.136.200:8001 Địa chỉ IP của Web Server: http://192.168.136.199:8080
Bảng 3 1 Kịch bản kiểm thử
STT Tên Yêu cầu Thực hiện Kết quả thu được
1 Kiểm thử hiệu năng Sử dụng Jmeter
Kiểm tra khả năng kiểm soát số lượng truy cập vào hệ thống
Kong Gateway giới hạn số lượng http request
Kiểm thử dữ liệu đầu vào
Sử dụng Burp Suite Professional
Tồn tại lỗi SQL Injection trong 1 số service có thể bypass thông tin
-Xác thực dùng mật khẩu
Kiểm tra cơ chế phòng chống tấn công brute force Ứng dụng không có chức năng xác thực 2 bước hoặc hạn chế khi cố gắng đăng nhập
-Xác thực dùng khoá sai nhiều lần
Kiểm tra chặn bắt đường truyền khi dữ liệu gửi đi
Khi đăng khi tài khoản gói tin được gửi đi dạng rõ
Cơ chế cung cấp tài nguyên API từ hệ thống
Sử dụng Burpsuite phát hiện respone trả về Access- Control-Request Method và Header từ đó các trang khác có thể tạo nên để lấy tài nguyên API từ hệ thống
Kong gateway đang ngăn chặn 1 số IP truy cập
Kiểm tra cơ chế ngăn chặn truy cập theo IP của Kong
Hình 3 2 Kong Gateway được khởi động
3.5 Thực hiện kiểm thử hệ thống tìm việc làm
3.5.1 Kiểm thử hiệu năng a Kiểm thử API endpoint tích hợp vào Kong Gateway http://192.168.136.199:8080/users: Endpoint API
Hình 3 3 Điền các thông số kiểm thử Kong Gateway
Hình 3 4 Điều chỉnh thông số Đặt số thread là 5000 và thời gian mà một loạt các thread (hoặc người dùng ảo) sẽ được khởi động và phân phối là 10 giây.
Hình 3 5 Quan sát phản hồi
Quan sát các phản hồi của http request, có những request lỗi
Hình 3 6 Bảng thông báo thông số
=> Quan sát kết quả tỷ lệ lỗi 52.15%
Hình 3 7 Kiểm tra Respone Body của Http Request bị lỗi
Hình 3 8 Service đã được giới hạn http request bởi Kong gateway
=> Điều này hạn chế được số lượng truy cập trong 1 khoảng thời gian phòng chống tấn công từ chối dịch vụ, lưu lượng truy cập quá mức. b Kiểm thử Kong Gateway
Hình 3 9 Cấu hình các thuộc tính Jmeter cho kiểm thử Kong Gateway
Với các thuộc tính của bảng là: Số lượng luồng, Số lần lặp, Số yêu cầu hoàn thành mỗi giây.
Kiểm thử hiệu năng của Kong Gateway:
Bảng 3 2 Bảng báo cáo thông số kiểm thử hiệu năng Kong Gateway
Number Thread Loop Count Through Output
2000 7 Không phản hồi, ngừng chạy
Hình 3 10.Bảng báo cáo tại lần kiểm thử hiệu năng thứ 6 vào Kong gateway
Theo bảng kết quả thu được tại lần test thứ 6 ta có thể thấy hiệu năng của Kong Gateway có thể nhận tới ~116 request/1 giây
Hình 3 11 Gửi phương thức GET lên API, Respone trả về 1 user
Hình 3 12 Dò quét endpoint API phát hiện ra lỗ hổng SQL injection
Hình 3 13 Thực hiện tấn công, load lên proxy và gửi tới intruder
Hình 3 14 Đặt payload marker (tham số lựa chọn để tấn công)
Hình 3 15 Chọn các dữ liệu lệnh sqli vào payload
Hình 3 16 Kết quả tấn công Status trả về gồm mã thông báo http
Hình 3 17 API trả về toàn bộ danh sách user
=> Với đầu vào là một lệnh SQLi: ' or 'x'='x có thể lấy được toàn bộ danh sách user có thể thấy Service gặp vấn đề lỗ hổng SQL injection, chưa thể tương thích với API Gateway để có thể tích hợp vào nó.
3.5.2.2 Xác thực http://192.168.136.199:8080/companys: Endpoint API
Hình 3 18 Kong Gateway Yêu cầu xác thực với Key để lấy API danh sách toàn bộ
Hình 3 19 Thực hiện thêm Name và Value cho khóa xác thực
Hình 3 20 Phần Header thêm Key và Value thì xác thực sẽ thành công
Hình 3 21 Tại Positon đặt Payload markers là value của khoá
Chọn tham số đầu value của key để tiến hành thử tấn công brute force, quan sát cấu hình tại request của Kong đang có lỗ hổng Paramenter Pollution, có thể thay đổi giá trị value KMA thành các giá trị khác, tạo ra các bộ request.
Hình 3 22 Tại request thứ 976, kết quả respone 200 tìm được khoá
Như vậy tại việc triển khai tích hợp API vào Kong Gateway trên, với Kong đang sử dụng xác thực bằng khoá (Key Authentication) đang không hạn chế số lần xác thực trong khoảng thời gian nên sẽ có nguy cơ tấn công brute force dò khoá của Kong để từ đó truy cập được vào API Cần nên có những cơ chế xác thực mạnh hơn.
Kịch bản dưới đây sẽ tiến hành kiểm thử vào trang login của website
Hình 3 23 Giao diện đăng nhập tài khoản, đăng nhập thử 1 tài khoản ngẫu nhiên
Sử dụng burpsuite để quan sát các thông số http request xem các thông số trong các trường được gửi đi gồm username và password Có thể thấy hệ thống đang không sử dụng cơ chế
Hình 3 24 Mật khẩu khi request login với phương thức POST gửi đi chuỗi JSON
Hình 3 25 Đặt host và port để kiểm thử
Tiếp tục lựa chọn các value của name và password từ lỗ hổng parameter pollution để tạo ra các bộ request nhằm dò đoán mật khẩu
Hình 3 26 Đặt payload marker là username và password, để tiến hành tấn công brute force
Hình 3 27 Cho vào danh sách Payload Option cho Payload set 1 và Payload set 2
Việc kết thúc tấn công thì tạo ra một số mã http respone ta chỉ lọc ra http respone
200 là xác thực thành công
Hình 3 28 Filter được 1 respone 200 trả về tài khoản và mật khẩu đăng nhập hợp lệ
