Luận văn tốt nghiệp Khoa học máy tính: Tìm hiểu về một số giải pháp bảo mật xác thực cho ứng dụng trên thiết bị di động

Những ưu điểm chính của LVTN:- Nhận thức được bối cảnh thực tế của những vấn đề liên quan đến bảomật và xác thực người dùng trên thiết bị di động, từ đó xác định rõ độnglực, mục tiêu khi

Động lực

Ngày nay, điện thoại thông minh đóng một vai trò quan trọng trong cuộc sống. Không chỉ dừng lại ở việc sử dụng những chức năng cơ bản như nghe gọi, gửi tin nhắn , điện thoại thông minh còn được sử dụng như một phương tiện để giải trí, mua sắm online và công cụ hữu hiệu để làm việc Theo thống kê từ trang IDC [1],

Androidvà iOSlà hai hệ điều hành dành cho thiết bị di động phổ biến nhất hiện nay, chiếm lĩnh gần như 100% tổng số các thiết bị hiện tại.

Với số lượng thiết bị và người sử dụng nhiều như vậy, vấn đề bảo mật dữ liệu cũng như thông tin người dùng trở thành vấn đề cấp thiết và luôn được quan tâm bởi những nhà nghiên cứu, phát triển Tuy nhiên, trong một báo cáo năm 2019 [2], có đến38%ứng dụng trên iOS và43%ứng dụng trên Android đối mặt với những lỗ hổng nghiêm trọng Nguyên nhân phổ biến nhất gây ra tình trạng này là do cơ chế bảo mật yếu kém với tỷ lệ lần lượt là74%,57%và42%tương ứng với ứng dụng trên iOS, Android, và máy chủ cung cấp dịch vụ Tuy vấn đề bảo mật luôn được quan tâm cải tiến và nâng cấp, nhưng vẫn luôn tồn tại những cơ chế bảo mật yếu kém, mà nguyên nhân có thể đến từ việc chủ quan của những người quản trị hoặc sự hạn chế kiến thức chuyên sâu trong lĩnh vực bảo mật của những người phân tích, thiết kế dẫn đến việc đánh giá chưa đầy đủ làm cho một số lỗ hổng bị khai thác, và hậu quả là hàng triệu record dữ liệu của người dùng bị rò rỉ ra ngoài Yếu tố bảo mật trong việc quản lý thông tin người dùng nói riêng và trong việc phát triển ứng dụng đang được quan tâm và trở thành yếu tố cốt lõi cho việc khẳng định giá trị của sản phẩm.

Khác với trình duyệt web, ứng dụng di động thường không phản hồi một cách

1 tường minh về phương thức mà dữ liệu người dùng được trao đổi trong quá trình sử dụng Vì vậy việc trao đổi dữ liệu riêng tư có được an toàn hay không đều phải phụ thuộc hoàn toàn vào nhà phát triển Bên cạnh đó số lượng các điểm truy cập WiFi công cộng không ngừng tăng lên, tính đến năm 2020, có tới 454 triệu điểm trên toàn cầu [3] Việc đảm bảo an toàn trong quá trình gửi nhận thông tin của người dùng trong môi trường như vậy càng trở nên thách thức hơn bởi vì dữ liệu của họ có thể bị đọc bởi bất kỳ một người nào đó đang cùng tham gia vào trong mạng WiFi công cộng.

Qua đó cũng thấy được rằng việc tìm hiểu các giải pháp về bảo mật và xác thực cho ứng dụng trên thiết bị di động tuy không mới nhưng vẫn còn là vấn đề cấp thiết trong bối cảnh ngày nay Và cũng vì vậy mà nó trở thành động lực chính của luận văn này.

Mục tiêu đề tài

Trong đề tài này, các mục tiêu sau đây được đề ra và tập trung để hoàn tất :

• Tìm hiểu, phân tích, và đánh giá những mô hình bảo mật và xác thực cho ứng dụng trên thiết bị di động hiện có.

• Đề xuất giải pháp cho mô hình bảo mật trong xác thực người dùng cho các ứng dụng trên thiết bị di động.

• Xây dựng một số mô hình xác thực phổ biến trên thiết bị di động đảm bảo được các tiêu chuẩn an toàn trong quá trình xác thực người dùng.

• Hiện thực và triển khai thí điểm phương thức để xác thực người dùng choHệ thống hỗ trợ theo dõi và điều phối giao nhận hàng [4].

• Xây dựng mô hình thực nghiệm, thực hiện việc kiểm thử, đo đạc và đánh giá kết quả của các giải pháp đề xuất.

Phạm vi đề tài

Trong đề tài này, việc nghiên cứu sẽ được giới hạn trong phạm vi tìm hiểu, phân tích và đánh giá các phương thức xác thực đang được sử dụng phổ biến dành cho các ứng dụng trên thiết bị di động Về mặt giải pháp, việc thiết kế, xây dựng và triển khai thí điểm máy chủ xác thực cho ứng dụng hỗ trợ theo dõi và điều phối giao nhận hàng sẽ được thực hiện với mục tiêu đảm bảo sự an toàn và tin cậy trong quá trình xác thực người dùng theo điều kiện thực tế.

Cấu trúc báo cáo

Báo cáo được chia thành 8 chương với nội dung cụ thể như sau:

Chương 1 giới thiệu về đề tài luận văn, nêu lên động lực và phạm vi thực hiện của đề tài.

Chương 2 trình bày các khác niệm cơ bản, kiến thức nền tảng liên quan đến những vấn đề bảo mật cho hệ thống công nghệ thông tin nói chung và trong ứng dụng trên thiết bị di động nói riêng.

Chương 3 phân tích, đánh giá các giải pháp, công trình nghiên cứu liên quan phổ biến hiện nay, từ đó áp dụng vào việc thiết kế, xây dựng và thực hiện đề tài này. Chương 4 phân tích một số rủi ro xảy ra trong thực tế liên quan đến vấn đề bảo mật và xác thực người dùng trên ứng dụng di động, từ đó đề các giải pháp để khắc phục.

Chương 5 đưa ra giải pháp thí điểm cho việc xác thực người dùng cho một bài toán cụ thể trong thực tế Đồng thời áp dụng những phân tích, đánh giá ở Chương

3, 4 để xây dựng các mục tiêu và tiêu chí trong mô hình bảo mật của giải pháp. Chương 6 đánh giá và phân tích giải pháp thí điểm trên các khía cạnh bảo mật cũng như đề ra hướng giải quyết cho các vấn đề tồn đọng mà mô hình gặp phải. Chương 7 xây dựng và triển khai thử nghiệm giải pháp đã đề xuất trong điều kiện thực tế dựa trên những kịch bản được thiết kế nhằm đánh giá mức độ thỏa mãn các mục tiêu đề ra ở Chương 5.

Chương 8 tổng kết lại những kết quả đã đạt được trong quá trình nghiên cứu,phân tích, đánh giá và đề ra giải pháp Nêu lên những mặt hạn chế, đồng thời đề ra hướng phát triển cho đề tài trong tương lai.

Các nguyên tắc trong bảo mật thông tin

Tính bí mật dữ liệu

Dữ liệu phải được bảo đảm an toàn để bảo vệ sự riêng tư của người sở hữu dữ liệu đó Điều này đồng nghĩa với việc ngăn chặn dữ liệu bị tiết lộ trong suốt quá trình truyền tải giữa các bên liên quan Tính bí mật có thể đạt được nhờ vào cơ chế mã hóa thông tin, đảm bảo dữ liệu chỉ có thể được truy xuất bởi người gửi và người nhận Một khi nguyên tắc này bị phá hủy, các thông tin nhạy cảm của người dùng

2.1.CÁC NGUYÊN TẮC TRONG BẢO MẬT THÔNG TIN 5 như mật khẩu, mã xác thực, chứng chỉ, số thẻ tín dụng, có thể bị đánh cắp và sử dụng bất hợp pháp bởi những kẻ tấn công.

Tính toàn vẹn dữ liệu

Tính toàn vẹn dữ liệu đảm bảo rằng thông tin trong quá trình truyền tải, lưu trữ không bị thay đổi so với dữ liệu gốc ban đầu Khi yếu tố này bị vi phạm, dữ liệu gốc và dữ liệu truy xuất không còn nhất quán Sự sai lệch thông tin này có thể xuất phát từ những vấn đề kỹ thuật trong quá trình truyền tải và lưu trữ(như lỗi đường truyền, lỗi phần cứng, ), hoặc nghiêm trọng hơn là do yếu tố con người, khi mà kẻ tấn công sửa đổi dữ lệu có chủ ý nhằm một đích nào đó Để ngăn ngừa việc này,hàm băm (hash function)thường được sử dụng bởi tính chất một chiều của nó, đó là ứng với một dữ liệu đầu vào bất kỳ làavà hàm bămh(), giá trị đầu ra luôn có chiều dài cố định, và một sự biến đổi nhỏ của giá trị đầu vào cũng làm giá trị đầu ra thay đổi rất khác biệt (không thể đoán trước được) Do đó, khi có một giá trị của hàm băm, gần như không thể xác định được giá trị đầu vào của hàm.

Tính sẵn sàng dữ liệu

Tính chất này đảm bảo rằng người dùng hợp lệ có thể truy cập và sử dụng dữ liệu của họ bất kỳ lúc nào Yếu tố này nghe qua có vẻ mâu thuẩn với tiêu chí bí mật của dữ liệu, đó là một yếu tố đòi hỏi dữ liệu phải được lưu trữ và bảo vệ nghiêm ngặt, một yếu tố đòi hỏi dữ liệu phải luôn sẵn sàng để được truy xuất Đây chính là lý do đòi hỏi tam giác CIA phải cân bằng Tính sẵn sàng của dữ liệu có thể bị ảnh hưởng bởi những tác nhân bên trong hệ thống như phần mềm bị gián đoạn ngoài ý muốn, phần cứng ngưng hoạt động do hỏng hóc, hoặc đến từ bên ngoài như việc hệ thống đối mặt với các cuộc tấn công từ chối dịch vụ.

Một ví dụ minh họa cho thấy 3 yếu tố C-I-A luôn cần phải được bảo đảm trong tất cả những giải pháp liên quan đến bảo mật, điển hình là trong một hệ thống e-Commerce Trong hệ thống này, 3 yếu tố C-I-A bộc lộ vai trò của nó như sau:

• Tính bí mật: thông tin thẻ tín dụng(credit card) phải được bảo vệ để chống lại việc bị đánh cắp để thực hiện những giao dịch gian dối.

• Tính toàn vẹn: khi khách hàng mua món hàng A như mô tả trên hệ thống, họ cần phải nhận được đúng món hàng họ đã đặt Không thể để xảy ra trường hợp mô tả về món hàng A đã bị thay đổi so với mô tả ban đầu.

• Tính sẵn sàng: hệ thống vận hành liên tục 24 giờ/ngày, 7 ngày/tuần và khách hàng hợp lệ có thể mua hàng bất kỳ khi nào họ muốn.

Tính xác thực

Tính xác thực [6] được thực hiện thông qua quy trình xác minh người dùng bằng nhiều hình thức khác nhau nhằm ngăn chặn việc giả mạo danh tính trong quá trình tiếp cận, trao đổi thông tin với hệ thống Việc này đòi hỏi người dùng hợp lệ phải cung cấp những minh chứng để chứng nhận rằng anh ta đúng là anh ta và là một người dùng hợp lệ.

Tính chống thoái thác

Chống thoái thác dữ liệu là một cơ chế loại trừ việc một người đã gửi thông điệp hợp lệ nhưng sau đó lại chối bỏ chúng Trong ví dụ trên, một người chủ sở hữu thẻ tín dụng, thực hiện việc mua sắm trên hệ thốnge-Commerce, giao dịch thực hiện thành công nhưng lại từ chối thanh toán và cho là giao dịch đó không phải do anh ta thực hiện Điều này được thực hiện thông qua chữ ký số, trong đó hệ thống sử dụng cơ chếkhóa riêng tư - khóa công khai Người gửi"ký" vào thông điệp cần gửi bằng khóa riêng tư và người nhận có thể kiểm chứng thông điệp có phải đúng là của người gửi hay không thông qua khóa công khai của người đó.

Xác thực người dùng

Authentication

Xác thực [7] là quá trình xác minh danh tính của người dùng là chính xác so với những gì họ đang tuyên bố Mục đích của việc này nhằm ngăn chặn những truy cập bất hợp lệ vào hệ thống Điển hình là việc cố tình sử dụng sai danh tính hay dùng thông tin đăng nhập của người khác để thực hiện những truy cập trái phép. Thông thường ba yếu tố sau được sử dụng nhằm xác định người dùng có phải chính là người mà họ đang tuyên bố hay không:

• Dựa trên những gìngười dùng biết.

• Dựa trên những gìngười dùng sở hữu.

• Dựa trênđặc trưng duy nhất của người dùng.

Yếu tố thứ nhất rất dễ dàng để áp dụng cho các hệ thống bảo mật bởi sự thuận tiện trong việc hiện thực và triển khai nên nó được sử dụng trong hầu hết các hệ thống thông dụng Thông thường, yếu tố này được hiện thực dưới hình thức tên đăng nhập / mật khẩu (username / password) Tuy nhiên khuyết điểm của nó là sự phụ thuộc vào khả năng ghi nhớ của người dùng Thay vì nhớ nhiều mật khẩu phức tạp thỏa mãn các tiêu chuẩn mật khẩu mạnh, người dùng lại chọn những

2.2.XÁC THỰC NGƯỜI DÙNG 7 mật khẩu đơn giản và sử dụng đồng thời cho nhiều hệ thống khác nhau Theo số liệu của NordPass vào năm 2020 [8], có tới2, 543, 285người sử dụng mật khẩu phổ biến và vô cùng đơn giản là"123456" Điểm yếu này tạo sự thuận lợi cho các loại hình tấn công như tấn công vét cạn hoặc tấn công thông qua từ điển bằng việc khai thác tính đơn giản và phổ biến của chúng.

Yếu tố thứ hai đã khắc phục được hạn chế của yếu tố thứ nhất, đó là người dùng hệ thống hỗ trợ xác thực người dùng bằng những gì người dùng có không phải nhớ gì về thông tin dùng để xác thực, ví dụ không cần phải nhớ tên đăng nhập, không cần phải nhớ mật khẩu Tuy nhiên, hạn chế của mô hình này là để bảo đảm tính sẵn sàng thì người dùng phải luôn mang theo bên mình các thiết bị vật lý để hỗ trợ xác thực như các loại thẻ từ, thẻ thông minh, thiết bị di động Ngoài ra, trong trường hợp các thiết bị hỗ trợ xác thực bị thất lạc, nếu hệ thống không được cập nhật kịp thời để hủy tính hợp lệ của thiết bị thì nó không thể nào xác định được người đang thực hiện hành vi xác thực có đúng là chủ sở hữu của thiết bị đó hay không Bên cạnh đó, chi phí triển khai cũng là một vấn đề cần cân nhắc khi áp dụng yếu tố xác thực này do phải sử dụng thêm phần cứng hỗ trợ làm chi phí đầu tư cao hơn so với yếu tố đầu tiên.

Cuối cùng, yếu tố dựa vàođặc trưng duy nhất tận dụng những thuộc tính riêng mà chỉ người dùng mới có để khắc phục nhược điểm của 2 yếu tố trên, đó là người dùng không phải nhớ và cũng không phải bảo quản thiết bị hỗ trợ đăng nhập Tuy nhiên phương án này cũng tồn tại nhiều mặt hạn chế Đầu tiên chính là sự ảnh hưởng của yếu tố môi trường trong quá trình xác thực như ánh sáng, độ chói, làm giảm độ chính xác Ví dụ, một hệ thống xác thực người dùng sử dụng công nghệ nhận diện khuôn mặt thì độ chính xác phụ thuộc rất nhiều vào chất lượng hình ảnh, đặc biệt là điều kiện ánh sáng [9] Ngoài ra, còn có những kỹ thuật giả dạng, tấn công phát lại cũng có thể được sử dụng để qua hệ thống này [10].

Bảng2.1[11] liệt kê ngắn ngọn những hình thức thường được sử dụng trong quá trình xác thực bằng 3 yếu tố nêu trên, đồng thời cũng đề cập đến những hạn chế đối với từng yếu tố trong việc hiện thực những hệ thống xác thực dựa trên những yếu tố này.

Qua đó cũng thấy rằng việc sử dụng chỉ một phương pháp để xác thực sẽ gặp nhiều vấn đề trong việc xác minh người dùng Để khắc phục điều đó, xác thực nhiều bước là một giải pháp trong việc tăng độ tin cậy trong quá trình này bởi việc kết hợp nhiều phương thức xác thực với nhau Một trong những hình thức phổ biến của loại hình này là việc sử dụng thêm các câu hỏi bảo mật (đã được người lựa chọn và trả lời trong quá trình đăng ký) để tái khẳng định danh tính người dùng thêm một lần nữa sau khi quá trình xác thực bằng mật khẩu diễn ra thành công.

Tuy nhiên, giải pháp này tựu chung lại gồm các bước nằm trong một yếu tố xác thực, dẫn đến các mối đe dọa, hạn chế vẫn không được cải thiện đáng kể Như ví dụ trên, hai bước xác thực này đều thuộc yếu tố xác thực"Dựa trên những gì người dùng biết" nên vẫn gặp phải tình trạng xem trộm thông tin, và kẻ tấn công vẫn có thể truy cập vào tài khoản của nạn nhân một cách dễ dàng.

Người dùng biết Người dùng sở hữu Đặc trưng duy nhất

Hình thức Định danh/mật khẩu

Chìa khóa vật lý Thẻ thông minh

Mã phần cứng Thiết bị thông minh NFC, RFID

Vân tay Gương mặt Giọng nói Võng mạc

Tính sử dụng thực tế Chi phí cao Đòi hỏi phần cứng riêng Tấn công MITM

Phương pháp giả mạo Chi phí cao Độ chính xác Tấn công phát lại Thay đổi do sẹo

Bảng 2.1: Hình thức, rủi ro và hạn chế của các yếu tố xác thực

Nhằm khắc phục các hạn chế mà xác thực nhiều bước gặp phải, xác thựcđa yếu tốlà các tiếp cận mà ở đó có ít nhất hai yếu tố được sử dụng trong cùng một quy trình xác thực người dùng, từ đó giảm thiểu được các rủi ro và hạn chế mà mỗi yếu tố xác thực còn tồn đọng Một phương án điển hình cho loại hình xác thực đa yếu tố là xác thực sử dụng mãOTP - One Time Password, được gửi đến số điện thoại của người dùng dưới hình thức tin nhắn SMS sau khi người dùng đăng nhập thành công thông qua mật khẩu Phương pháp này sử dụng kết hợp hai yếu tốDựa trên những gì người dùng biết vàDựa trên những gì người dùng sở hữu tương ứng với mật khẩu và mã OTP được gửi đến điện thoại của người dùng Việc sử dụng thêm yếu tố thứ hai bên cạnh yếu tố đầu tiên đã giúp giảm thiểu được các hạn chế của yếu tố thứ nhất bởi vì dù cho kẻ tấn công biết được mật khẩu của nạn nhân, việc đăng nhập vẫn thất bại vì không có được được mã OTP được gửi đến điện thoại nạn nhân để tiếp tục bước thứ 2 của quá trình xác thực.

Authorization

Authorizationlà quá trình cấp quyền hạn cho các đối tượng trong hệ thống như là: quy trình(process)hoặc người dùng Quá trình này khác với quá trình authentication - quá trình xác định danh tính của người dùng, authorization được dùng để xác định các đặc quyền(privileges), quyền lợi(rights), tài sản sở hữu(property), và các tập hợp hành động được phép thực hiện(permissible actions)của người dùng sau khi trải qua quá trình xác thực [12] thành công Hình2.1trình bày một ví dụ

2.3.OTP (ONE-TIME-PASSWORD) 9 đơn giản mô tả việc phân quyền cho cho nhân viên trong một hệ thống quản lý tài khoản người dùng Trong đó, nếu một người có vai trò làquản lýthì được phép thực hiện nhiều hành động hơn đối với người dùng chỉ có vai trò lànhân viên.

Quản lý Xem thông tin bản thân Xem thông tin quản lý Chỉnh sửa thông tin quản lý

Nhân viên Xem thông tin bản thân Xem thông tin quản lý Chỉnh sửa thông tin quản lý

Hình 2.1: Ví dụ về phân quyền trong hệ thống

So sánh Authentication và Authorization

Như đã đề cập ở trên, quá trình Authenticationdựa trên những yếu tố liên quan đến người dùng nhằm xác định xem người đang chờ xác thực có đúng với những thông tin mà anh ta đang cung cấp hay không Trong khi đó, quá trìnhAuthoriza- tionxác định xem một người đã được xác thực thành công thì anh ta được phép tiếp cận với những thông tin gì, sở hữu những quyền hạn gì, và được quyền thực hiện tập hợp những hành động được định nghĩa nào Bảng2.2[13] tóm tắt lại chức năng và chỉ ra sự khác biệt cơ bản của 2 quá trình này.

Vai trò Xác minh danh tính người dùng so với những gì họ tuyên bố

Quản lý truy cập (cung cấp hoặc từ chối các quyền hạn)

Phương thức Sử dụng mật khẩu, sinh trắc học, Thông qua đội ngũ bảo mật ứng dụng

Trong suốt với người dùng Không Có

Bảng 2.2: So sánh giữa authentication và authorization

OTP (One-time-password)

HOTP (HMAC-based One-time Password)

Giải thuật để sinh mã của HOTP được dựa trên hai yếu tố là giá trị của một bộ đếm lũy tiến và một khóa đối xứng (khóa này chỉ được cấp cho bên tạo mã và dịch vụ xác thực) Để tạo được giá trị của HTOP, giải thuật HMAC-SHA-1 sẽ được sử dụng, tạo ra giá trị hàm băm với độ dài 160 bits và sau đó được thu gọn thành độ dài nhất định (tối thiểu từ 6 đến 8 ký tự, phụ thuộc vào mức độ bảo mật của ứng dụng) để người dùng có thể sử dụng dễ dàng Quá trình sinh mã trên có thể được biểu diễn như sau:

HOT P(K,C)=Tr unc at e(H mac(K,C)) Trong đó:

• C là giá trị bộ đếm lũy tiến.

• H mac()là hàm tính của giải thuật HMAC-SHA-1.

• Tr unc at e()là hàm thu gọn giá trị trả về từH mac()(từ 160 bits thành độ dài nhất định).

TOTP (Time-Based One-Time Password)

TOTP là một phiên bản của HTOP, dựa vào số bước thời gian đã trôi qua (T) thay thế cho bộ đếm lũy tiến (C) [16] Số bước thời gian này được tính dựa vào công thức sau:

• t là thời gian hiện tại của thời gian Unix (số giây đã trôi qua tính từ 0 giờ ngày 1/1/1970).

• t 0 là thời gian điểm bắt đầu.

• ∆T là độ dài mỗi bước, dao động từ 30 đến 60 giây.

Mã hóa

Mã hóa đối xứng

Mã hóa đối xứng(symmetric encryption)là loại mã hóa chỉ duy nhất một khóa bí mật được sử dụng trong cả hai quá trình mã hóa và giải mã dữ liệu Hình2.2mô tả quá trình trên thông qua sử dụng một khóa duy nhất.

Văn bản đã được mã hóa

Khóa đối xứng Khóa đối xứng

Hình 2.2: Quá trình mã hóa và giải mã trong mã hóa đối xứng

Mã hóa đối được chia thành 2 loại [17]:Block ciphers, vàStream ciphers, trong đó:

• Block ciphers: mỗi khối được mã hóa tại một thời điểm và được kết nối lại với nhau để tạo ra kết quả mã hóa, với các chế độ ECB, CBC, CFB, OFB.

• Stream ciphers: Sử dụng một khóa dài (được tạo từ khóa ngắn hơn) để tiến hành XOR với dữ liệu thô, từ đó tạo ra dữ liệu đã được mã hóa.

Block ciphers được phân loại dựa trên cách thức thực hiện mã hóa như sau:

• Electronic Code Book (ECB): dữ liệu được chia thành các khối nhỏP 1 ,P 2 , ,

P n sau đó được tính các giá trị mã hóa tương ứngC 1 ,C 2 , ,C n sử dụngc i E k (P i )vớiE k là giải thuật mã hóa cùng khóa được dùng Cách thức này gặp lỗ hổng với splicing attacks, trong đó các khối được mã hóa từ một tin nhắn có thể bị thay thế bằng các khối được mã hóa từ một tin nhắn khác.

• Cipher Block Chaining (CBC): CBC sử dụng một initialization vector (IV) để khắc phục hạn chế của ECB IV sẽ được sử dụng để XOR với đầu vào của dữ liệu trước khi được tiến hành mã hóa, do vậy tạo sự phụ thuộc giữa các khối trong quá trình mã hóa Có thể được biểu diễnC i =E k (C i−1 ⊕P i )vớiC 0 =I V.

Hình 2.3: Mã hóa và giải mã khối sử dụng ECB

Hình 2.4: Mã hóa và giải mã khối sử dụng CCB

• Cipher Feed-Back (CFB): CFB sử dụng việc XOR ở đầu ra kết quả của hàm mã hóa của IV, biểu diễn bởiC i =E k (C i−1 )⊕P i vớiC 0 =I V.

Hình 2.5: Mã hóa và giải mã khối sử dụng CFB

• Output Feed-Back (OFB): tương tự như CFB nhưng đầu vào của khốii tiếp theo được sử dụng là kết quả của hàmE k của khối trước đó (i−1) thay cho

Hình 2.6: Mã hóa và giải mã khối sử dụng OFB

Khác với block ciphers, stream ciphers xây dựng một chuỗi các bit ngẫu nhiên(pseudo-random) và sau đó kết hợp với dữ liệu đầu vào để thực hiện quá trình mã hóa Stream ciphers gồm 2 loại:

• Synchronous: Khóa dùng trong quá trình mã hóa độc lập với dữ liệu được mã hóa (sinh ra sử dụng yếu tố bên ngoài) [18].

• Self-synchronous: Khóa dùng trong quá trình mã hóa phụ thuộc vào dữ liệu được mã hóa [18].

Hình 2.8: Self-synchronous stream ciphers

Với một dãy dữ liệu đầu vào101000101và khóa100101110, kết quả mã hóa thu được sẽ là101000101⊕1001011101101011 Việc giải mã sẽ được thực hiện thông qua áp dụng XOR giữa dữ liệu được mã hóa và khóa đối xứng:001101011⊕100101110101000101.

G IẢI THUẬT MÃ HÓA ĐỐI XỨNG

Một vài ví dụ cho giải thuật mã hóa đang được sử dụng có thể nhắc đến như:

• DES: sử dụng khóa có chiều dài 56 bits, thực hiện qua việc lặp lại 16 lần quá trình mã hóa khối trên dữ liệu đầu vào 64 bits Tuy nhiên, DES được chứng minh là không còn an toàn khi được giải mã thành công trong 56 tiếng sử dụng EFF DES cracker vào năm 1998 3DES được ra mắt nhằm khắc phục việc tấn công vét cạn không gian khóa của DES với việc lặp lại quá trình mã hóa này 3 lần sử dụng các khóa khác nhau:3DE S k 1 ,k 2 ,k 3 =DE S k 1 (DE S k 2 (DE S k 3 (P))).

• AES: là giải thuật mã hóa khối sử dụng khóa có chiều dài 128, 192 hoặc 256 bits, với 10, 12 và 14 vòng lặp tương ứng Mỗi vòng lặp sẽ bao gồm việc tính toán, thay thế và hoán vị dữ liệu đầu vào để tạo thành kết quả mã hóa.

2.4.MÃ HÓA 15 Ưu điểm của hình thức mã hóa này là thời gian mã hóa và giải mã nhanh, ít tiêu tốn tài nguyên xử lý, nhưng lại có nhược điểm là bên mã hóa và bên giải mã phải thống nhất được khóa trước khi trao đổi dữ liệu Đòi hỏi này dẫn đến một số khó khăn trong việc phân phối khóa giữa các bên khi cần trao đổi dữ liệu với nhau.Cũng vì nguyên nhân này mà một hình thức mã hóa khác được đề xuất, đó là mã hóa bất đối xứng.

Mã hóa bất đối xứng

Mã hóa bất đối xứng (asymmetric cryptography hoặc public-key cryptography) là loại hình mã hóa trong đó sử dụng hai khóa: bí mật và công khai Hai khóa này được liên hệ với nhau về mặt toán học nhưng không khả thi về mặt tính toán trong việc tìm ra khóa bí mật dựa vào khóa công khai [19] Trong quá trình này, dữ liệu được mã hóa bới khóa công khai chỉ có thể được giải mã sử dụng khóa bí mật và ngược lại, được thể hiện qua hình2.11 Mã hóa bất đối xứng có thể được sử dụng

Văn bản đã được mã hóa

Khóa công khai Khóa bí mật

Hình 2.9: Quá trình mã hóa và giải mã trong mã hóa bất đối xứng trong nhiều lĩnh vực khác nhau như trao đổi thông tin một cách an toàn mà không cần chia sẻ trước khóa chung hoặc sử dụng trong chữ ký số RSA là giải thuật điển hình cho hình thức mã hóa bất đối xứng, gồm tạo khóa và thực hiện việc mã hóa giải mã Việc tạo khóa trong RSA được thực hiện như sau:

• Chọn 2 số nguyên tố lớn p và q (có chiều dài từ 1024 đến 2048 bits) và tính tích chung của chúngn=pq.

• Tìm số đồng nguyên tốecủa(p−1)(q−1), đây sẽ là thành phần mũ trong khóa công khai.

0 https://www.tutorialspoint.com/cryptography/public_key_encryption.htm

• Tìm số nguyên d thỏa mã công thứcd =(1+x(p−1)(q−1))/e vớix là số tự nhiên bất kỳ.

Sau quá trình tính toán trên, khóa công khai và khóa bí mật thu được lần lượt sẽ là (n,e)và(n,d) Để thực hiện việc mã hóa, dữ liệu phải được biểu diễn ở dạng số, có giá trị nhỏ hơn n sử dụng padding scheme, sau đó được tính toán như sau:

• Trong trường hợp mã khóa dùng khóa công khai:C =P e mod n, được giải mã sử dụngP=C d mod n.

• Trong trường hợp mã khóa dùng khóa bí mật:C=P d mod n, được giải mã sử dụngP=C e mod n.

Hàm băm

Hàm băm mật mã học là một giải thuật được sử dụng để ánh xạ dữ liệu có kích thước bất kỳ về một mảng các bit có kích thước cố định Về mặt bảo mật, các tính chất sau cần phải được đảm bảo [20]:

• Collision-Resistance: bất khả thi trong việc tính toán để tìm ra hai dữ liệu đầu vào khác nhau mà cho ra cùng một giá trị băm.

• Pre-image Resistance: thể hiện tính chất một chiều, không thể đảo ngược việc tính toán của thuật toán Với một giá trịhtừ hàm bămhash(), việc tìm ra dữ liệu đầu vàoP sao choh=hash(P)là không khả thi trong việc tính toán.

• 2nd Pre-image Resistance: với một dữ liệuP, không thể tìm raP 0 (P 0 6=P)sao cho hash(P 0 )=hash(P)

Hàm băm thường được sử dụng trong việc kiểm tra tính toàn vẹn dữ liệu và lưu trữ mật khẩu Trong hai quá trình này, giá trị băm sẽ tính toán và lưu trữ, sử dụng để so sánh với giá trị băm của dữ liệu cần được kiểm tra tính toàn vẹn.

Chữ ký số

Chữ ký số (digital signature) là một kỹ thuật toán học được sử dụng để xác nhận tính xác thực và tính toàn vẹn của một thông điệp, phần mềm hoặc tài liệu kỹ thuật số [21] Cơ chế này được sử dụng nhằm giải quyết vấn đề giả mạo và mạo danh trong quá trình trao đổi dữ liệu, thông qua việc sử dụng mã hóa bất đối xứng và hàm băm mật mã học Quá trình ký tên và kiểm tra chữ ký trên dữ liệu được mô tả như sau:

Hình 2.10: Sử dụng hàm băm để kiểm tra tính toàn vẹn dữ liệu

1 Người gửi sử dụng hàm băm để lấy unique figerprint của dữ liệu.

2 Người gửi thực hiện quá trình ký sử dụng giải thuật mã hóa bát đối xứng, sử dụng khóa bí mật của họ Chữ ký số được sinh ra trong quá trình này sẽ được đính kèm trong dữ liệu được gửi đến người nhận.

Dữ liệu đã được ký

Khóa bí mật người gửi

Hình 2.11: Quá trình ký dữ liệu khi gửi (mã hóa bất đối xứng)

1 Người nhận sử dụng hàm băm để lấy unique figerprint của dữ liệu nhận được.

2 Người gửi thực hiện quá trình giải mã chữ ký số, sử dụng khóa công khai của người gửi và thu được unique figerprint của dữ liệu được gửi đi.

3 Người nhận so sánh hai giá trị unique figerprint này đề kiểm tra tính toàn vẹn của dữ liệu Nếu hai giá trị này không trùng khớp, dữ liệu có thể đã bị thay đổi.

Ngoài ra, tính bảo mật của quá trình xác minh còn cần phải có cơ chế để người nhận biết chắc chắn rằng khóa công khai mà người nhận đang giữ thực sự thuộc

Khóa công khai người gửi

Hình 2.12: Quá trình xác thực dữ liệu khi nhận (mã hóa bất đối xứng) về người gửi chứ không phải do ai đó mạo danh họ [22] Để giải quyết vấn đề này, tổ chức Certificate Authority (CA) cung cấp dịch vụ để cung cấp cácdigital certificate và thực hiện việc liên kết khóa công khai với danh tính của người sở hữu Các CA hoạt động như một bên thứ ba đáng tin cậy và được tin tưởng bởi người gửi và người nhận trong các quá trình trao đổi dữ liệu.

Ngoài ra, chữ ký số còn được thực hiện thông qua việc sử dụng khóa bí mật được chia sẻ chung giữa người gửi và người nhận bằng giải thuật HMAC (hash- based message authentication code) Quá trình tính toán HMAC biểu diễn bởi công thức sau [23]:

H(K) K lớn hơn kích thước của khối

K trong các trường hợp còn lại Trong đó:

• H là hàm băm mật mã học.

• m là dữ liệu cần được xác thực.

• K’ là khóa có kích thước bằng kích thước khối, được tính từ K qua 2 cách– Đệm thêm các giá trị 0 vào bên phải (K có kích thước nhỏ hơn kích thước khối).

RESTful API

– Trong trường hợp lớn hơn, K được băm xuống để có kích thước nhỏ hơn hoặc bằng khổi đầu tiên, sau đó tiến hành việc đệm thêm các giá trị 0 vào bên phải.

• opad là outer padding, độ dài bằng kích thước của khối, chứa các giá trị 0x5c được lặp lại.

• ipad là inner padding, độ dài bằng kích thước của khối, chứa các giá trị 0x36 được lặp lại.

Quá trình ký và kiểm tra này diễn ra tương tự so với việc sử dụng mã hóa bất đối xứng (Hình2.13và2.14).

Dữ liệu đã được ký

Hình 2.13: Quá trình ký dữ liệu khi gửi (mã hóa đối xứng)

REST (Representational state transfer) là một phong cách kiến trúc để phát triển dịch vụ với các nguyên tắc sau [24]:

• Kiến trúc client - server: kiến trúc này được sử dụng nhằm tạo sự tách biệt giữa ứng dụng người dùng (client) và máy chủ dịch vụ (server), từ đó có thể phát triển các thành phần trên một cách độc lập miễn là giao diện tương tác giữa chúng được thống nhất với nhau.

Hình 2.14: Quá trình xác thực dữ liệu khi nhận (mã hóa đối xứng)

• Không trạng thái (stateless): các yêu cầu từ ứng dụng người dùng (client) đến máy chủ (server) chỉ chứa các thông tin cần thiết để thực hiện Các dữ liệu về phiên làm việc sẽ được lưu trữ ở phía ứng dụng người dùng thay cho máy chủ.

• Cacheable: dữ liệu được trả về từ các yêu cầu đến máy chủ phải được đánh dấu là cacheable hoặc non-cacheable Với dữ liệu cacheable, chúng có thể được sử dụng lại nhằm tăng hiệu suất cho hệ thống.

• Uniform interface: ràng buộc sự thống nhất về giao diện tương tác giữa các thành phần trong hệ thống Điều này giúp cho dữ liệu trong quá trình trao đổi luôn tuân theo một quy ước, từ đó đơn giản hóa kiến trúc cũng như tách rời quá trình phát triển của mỗi thành phần trong hệ thống.

• Phân lớp trong hệ thống (layered system): nguyên tắc này ràng buộc về sự hữu hình giữa các thành phần với nhau trong hệ thống Các thành phần không thể nhìn thấy các thành phần nằm bên ngoài lớp mà chúng đang tương tác.

• Code on demand: nguyên tắc tùy chọn này cho phép ứng dụng người dùng có thể mở rộng các tính năng thông qua việc tải về các đoạn mã từ phía máy chủ.

Một hệ thống được xem là RESTful [24] khi đáp ứng đủ các ràng buộc đã nêu trên.

OWASP Top 10

Injection

Các lỗi như SQL, NoSQL, OS, and LDAP injection có thể được lợi dụng thông qua việc dữ liệu không đáng tin cậy được gửi đến bộ biên dịch như một phần của lệnh hoặc truy vấn Các dữ liệu nguy hại này có thể đánh lừa trình biên dịch thực thiện các lệnh ngoài ý muốn hoặc cho phép kẻ tấn công truy cập vào dữ liệu mà không cần được cấp quyền.

Kẻ tấn công có thể sử dụng loại hình tấn công này để phục vụ các mục tiêu như [27]:

• Phân tích lược đồ trong cơ sở dữ liệu: khai thác các thông tin liên quan nhằm phục vụ cho các lần tấn công kế tiếp.

• Khai thác dữ liệu: thu thập các dữ liệu quan trọng hoặc bí mật như dữ liệu người dùng.

• Thay đổi dữ liệu: thay đổi các thông tin trong hệ cơ sở dữ liệu, có thể được dùng để tạo các cuộc tấn côngCross-Site-Scripting.

• Từ chối dịch vụ: ngăn ngừa quá trình hoạt động thông qua việc tắt hệ cơ sở dữ liệu hoặc xóa thông tin các lược đồ.

• Bỏ qua quá trình xác thực: bỏ qua các cơ chế xác thực của máy chủ, dẫn đến các tài khoản có thể được đăng nhập trái phép.

• Kiểm tra các dữ liệu đầu vào ở phía máy chủ.

• Thoát các ký tự đặc biệt trong các câu truy vấn động.

Broken Authentication

Kẻ tấn công lợi dụng việc các chức năng ứng dụng liên quan đến xác thực và quản lý phiên không được thực hiện một cách hiệu quả, qua đó cho phép chúng dễ xâm phạm mật khẩu, khóa bí mật hoặc session tokens nhằm giả định danh tính của người dùng khác tạm thời hoặc vĩnh viễn Các công cụ tấn công vét cạn, tấn công từ điển (dựa trên danh sách các tên đăng nhập và mật khẩu bị lộ) tự động có thể được sử dụng để đạt được mục tiêu này.

Loại hình tấn công này được thực hiện nhằm có quyền truy cập một tài khoản trong hệ thống Khi đó, một số rủi ro có thể xảy ra như mạo danh, tiết lộ các thông tin có tính bảo mật cao.

• Sử dụng xác thực đa yếu tố nhằm ngăn ngừa các cuộc tấn công tự động, vét cạn, từ điển.

• Ngăn ngừa việc sử dụng các chứng chỉ mặc định cho các tài khoản quản trị viên.

• Đặt ra các tiêu chuẩn cho mật khẩu và kiểm tra các mật khẩu yếu.

Lộ thông tin nhạy cảm người dùng

Lợi dụng các ứng dụng web và API không bảo vệ đúng cách các dữ liệu nhạy cảm(như thẻ tín dụng, thông tin cá nhân), kẻ tấn công có thể đánh cắp hoặc sửa đổi dữ liệu trên đó để thực hiện các hành vi gian lận tín dụng, đánh cắp danh tính hoặc thực hiện các loại tội phạm khác Dữ liệu nhạy cảm này có thể bị xâm phạm nếu không có biện pháp bảo vệ bổ sung, như mã hóa khi lưu trữ hoặc trong quá trình truyền tải Một vài cách thức sau có thể được dùng để thực hiện nhằm vào lỗ hổng bảo mật này:

• Đánh cắp các khóa để giải mã dữ liệu được mã hóa (có thể đã được đánh cắp từ máy chủ bằng hình thức khác như SQL Injection).

• Thực hiện tấn công MITM nhằm lấy được thông tin trong quá trình vận chuyển trên giao thức không an toàn.

Với hình thức này, các dữ liệu cần được bảo vệ sẽ bị thỏa hiệp, dẫn đến các rủi ro như thông tin cá nhân được sử dụng để mạo danh, thẻ tín dụng được sử dụng để giao dịch gây nên các tổn thất tài chính.

• Sử dụng giao thức truyền tải an toàn như HTTPS.

• Không lưu trữ thông tin nhạy cảm khi không cần thiết.

• Mã hóa các dữ liệu được lưu trữ.

• Lưu trữ mật khẩu sử dụng các hàm băm chậm có sử dụng muối như Argon2,scrypt, bcrypt, PBKDF2.

XML External Entities

Kẻ tấn công có thể lợi dụng việc cho phép tham chiếu đến các thực thể bên ngoài trong quá trình xử lý XML của các bộ xử lý cũ nhằm chèn vào đó các đoạn mã độc hại, từ đó có thể tiết lộ các thông tin bên trong hệ thống.

Với phương pháp này, các hậu quả có thể được kể đến như:

• Thực thi mã từ xa.

• Tấn công từ chối dịch vụ.

• Sử dụng định dạng dữ liệu đơn giản hơn như JSON khi có thể.

• Nâng cấp hoặc cài đặt bản vá các thư viện, bộ xử lý XML được sử dụng.

• Kiểm tra các dữ liệu XML được tải lên từ người dùng.

• Vô hiệu hóa tính năng tham chiếu đến thực thể ngoài trong bộ xử lý XML.

Broken Access Control

Việc quản lý yếu kém trong phân quyền người dùng có thể được lợi dụng bởi kẻ tấn công nhằm thực thi các hành động ngoài quyền hạn được cho phép như truy cập tài khoản của người dùng khác, xem các tệp nhạy cảm, sửa đổi dữ liệu hoặc thay đổi quyền truy cập.

Việc thiếu sót trong quản lý quyền hạn truy cập có thể dẫn đến những hậu quả như: Việc kẻ tấn công có thể thao tác dưới quyền quản trị viên khi ở vai trò người dùng có thể gây nên nhiều hậu quả như:

• Sử dụng các chức năng của quản trị viên.

• Truy cập vào các thông tin nhạy cảm.

• Chỉnh sửa, thao tác trên dữ liệu người dùng.

• Mặc định ngăn chặn việc truy cập vào các tài nguyên không công khai.

• Giới hạn số lượng yêu cầu đến API nhằm giảm tác hại của các công cụ tấn công tự động.

• Các mã JWT nên được vô hiệu hóa khi người dùng đăng xuất.

Cấu hình sai các cài đặt bảo mật

Với rủi ro bảo mật này, kẻ tấn công có thể dễ dàng truy cập vào hệ thống thông qua các hình thức sau:

• Sử dụng các tài khoản, cấu hình mặc định của hệ thống.

• Truy cập các trang không được sử dụng, các tài nguyên lưu trữ không được bảo vệ.

• Quan sát các lỗi trả về từ phía máy chủ cho người sử dụng.

• Khai thác các lỗi chưa được vá / cập nhật.

Với các sai sót này, kẻ tấn công có thể truy cập trái phép vào một phần hoặc toàn bộ hệ thống, dẫn đến các dữ liệu của ứng dụng có thể bị đánh cắp hoặc sửa đổi.

• Loại bỏ các chức năng, thư viện không được sử dụng.

• Cập nhật các bản vá lỗi cho thư viện, hệ điều hành và hệ thống.

• Cập nhật cấu hình phù hợp với các tiêu chí trong bảo mật.

Cross-Site Scripting (XSS)

Lỗi này được xảy ra khi dữ liệu không đáng tin cậy được đính kèm theo trong quá trình mở ra một trang web mới Hiện nay, các công cụ tự động có thể phát hiện và khai thác các dạng XSS [26] sau:

• Reflected XSS: kẻ tấn công lợi dụng các API không kiểm tra và thoát các ký tự đặc biệt được nhập vào từ người dùng trong quá trình sử dụng chúng để hiển thị lên trang web Do đó, điều này được lợi dụng để kẻ tấn công thực thi HTML hoặc các lệnh JavaScript tùy ý trên trình duyệt của nạn nhân.

• Stored XSS: các dữ liệu nhập từ người dùng không được kiểm tra và xử lý trước khi lưu trữ có thể tạo nên những rủi ro nguy hiểm khi quản trị viên hiển thị để kiểm tra hoặc sử dụng chúng.

• DOM XSS: đây là loại hình tấn công thay đổi môi trường DOM trên trình duyệt người dùng Trong đó, kẻ tấn công sẽ thêm vào một đoạn dữ liệu độc hại vào đường dẫn đến một trang web dễ bị tấn công bởi DOM XSS Dữ liệu này không được gửi đến máy chủ và được thực thi sau khi có kết quả trả về, dẫn đến nội dung trong trang web bị thay đổi so với thực tế [28].

Với việc có thể thực thi bất cứ lệnh nào trên trình duyệt nạn nhân, kẻ tấn công có thể thực hiện cách hành vi như:

• Đánh cắp các chứng chỉ, phiên làm việc hoặc chiếm quyền tài khoản.

• Tải về và cài đặt các phần mềm độc hại.

• Thoát các ký tự đặc biệt trong đầu ra của các trang HTML sử dụng dữ liệu nhập bởi người dùng.

Giải mã dữ liệu không an toàn

Dữ liệu được gửi đi ở dạng tuần tự hóa có thể bị sửa đổi bởi các kẻ tấn công, làm thay đổi nội dung của chúng Ngoài ra, chúng còn có thể được sử dụng để tiến hành các loại tấn công như phát lại, injection và privilege escalation (tăng quyền hạn) [29]

Với hình thức trên, kẻ tấn công có thể mạo danh người dùng hoặc quản trị viên, dẫn đến các dữ liệu có thể bị thay đổi, chỉnh sửa và tiết độ.

• Hiện thực phương thức kiểm tra chữ ký số trên các dữ liệu được tuần tự hóa trong quá trình gửi đi, ngăn chặn chúng bị sửa đổi hoặc giả mạo.

Sử dụng các công cụ với các lỗ hổng bảo mật đã được biết

Các công cụ được sử dụng trong hệ thống như thư viện, framework và các module phần mềm khác thường được chạy cùng một đặc quyền với ứng dụng Vì vậy, kẻ tấn công có thể khai thác các lỗ hổng bảo mật của công cụ được sử dụng để tiến hành các cuộc tấn công vào hệ thống [29].

Việc sử dụng các thành phần có lỗ hổng bảo mật đã được biết sẽ làm suy yếu khả năng bảo bệ của ứng dụng trước các cuộc tấn công, gây ra các rủi ro khác nhau tùy phụ thuộc vào mức độ nghiêm trọng của lỗ hổng bảo mật, có thể gây từ các tổn hại nhỏ cho đến việc dữ liệu bị thỏa hiệp hoặc chiếm toàn quyền hệ thống [30].

• Gỡ bỏ các thư viện, tính năng và các tài nguyên không được sử dụng đến.

• Liên tục kiểm tra và cập nhật các phiên bản cho ứng dụng ở phía người dùng và phía máy chủ.

• Chỉ sử dụng thư viện từ các nguồn tin cậy, nhằm hạn chế các thành phần độc hại trong hệ thống.

• Triển khai bản vá ảo cho các thư viện không còn được hỗ trợ nhằm đối phó với các lỗ hổng mới.

Giám sát hệ thống không đầy đủ

Qua lợi dụng việc thiếu sót trong giám sát và ghi log, kẻ tấn công có thể thực hiện nhiều cuộc tấn công liên tiếp vào hệ thống mà không bị phát hiện Từ đó cho phép chúng thực hiện việc thăm dò lỗ hổng bảo mật của hệ thống, nâng cao khả năng tấn công thành công lên gần 100% [31].

• Không thể phát hiện, cảnh báo các bất thường mà máy chủ đang gặp phải.

• Tạo điều kiện cho các cuộc tấn công bằng phương pháp thăm dò lỗ hổng.

• Các dữ liệu bí mật từ các cuộc tấn công bị tiết lộ và gây tổn thất trước khi bị phát hiện trong hệ thống.

• Đảm bảo tất cả mọi hoạt động máy chủ đều được ghi ghép.

• Kiểm soát tính toàn vẹn của các thông tin giám sát.

C ÁC CÔNG TRÌNH NGHIÊN CỨU

Các mô hình xác thực người dùng

Basic Authentication

Trong mô hình xác thực này, phía người dùng (client) sẽ gửi thông tin xác thực (tên đăng nhập và mật khẩu) trong header khi thực hiện yêu cầu đến tài nguyên được bảo vệ với định dạngAuthorization: Basic Trong đó, là tên đăng nhập và mật khẩu được kết hợp với nhau thông qua dấu ":", sau đó được biểu diễn dưới dạng Base64 [32] Ví dụ với tên đăng nhập là "Aladdin" và mật khẩu "open sesame", giá trị của trường trong header sẽ là:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=Basic Authentication được thực hiện gồm các bước cơ bản sau:

1 Người dùng thực hiện yêu cầu truy cập vào tài nguyên được bảo vệ.

2 Máy chủ trả về yêu cầu cung cấp thông tin xác thực (tên đăng nhập và mật khẩu).

3 Người dùng gửi thông tin xác thực đến máy chủ.

4 Máy chủ kiểm tra và trả về tài nguyên được yêu cầu.

3.1.CÁC MÔ HÌNH XÁC THỰC NGƯỜI DÙNG 29

1 Yêu cầu vào tài nguyên được bảo vệ

2 Yêu cầu tên đăng nhập:mật khẩu

3 Gửi tên đăng nhập:mật khẩu

4 Trả về tài nguyên được bảo vệ

Hình 3.1: Quá trình của Basic Authentication

Ngoài ra, giao thức HTTPS nên được sử dụng trong việc thực hiện quá trình xác thực này vì các thông tin đăng nhập trên có thể dễ dàng bị đọc được bởi bất kỳ ai trong quá trình truyền tải khi sử dụng giao thức HTTP.

Bearer Authentication

Đây là một hình thức xác thực sử dụng mã bảo mật thay cho chứng chỉ so với mô hình xác thực cơ bản Mã bảo mật này được cấp khi người dùng đăng nhập vào hệ thống bởi máy chủ và được sử dụng để truy cập vào các tài nguyên được bảo vệ Mã này được gửi trong header với định dạng Authorization: Basic . Tương tự như xác thực cơ bản, các yêu cầu này nên được thực hiện sử dụng thông qua HTTPS Quá trình của Bearer Authentication diễn ra như sau:

1 Người dùng thực hiện việc xác thực với máy chủ thông qua tên đăng nhập và mật khẩu.

2 Máy chủ kiểm tra các thông tin trên và trả về Bearer Token.

3 Người dùng thực hiện yêu cầu truy cập vào tài nguyên được bảo vệ với Bearer Token vừa được cung cấp.

4 Máy chủ kiểm tra Bearer Token và trả về tài nguyên được yêu cầu.

1 Xác thực (tên đăng nhập:mật khẩu)

3 Yêu cầu tài nguyên được bảo vệ kèm theo Bearer Token

4 Trả về tài nguyên được bảo vệ

Hình 3.2: Quá trình của Bearer Authentication

API Key Authentication

API key là một bí mật được chia sẻ giữa phía người dùng và máy chủ, được sử dụng để xác thực phía người dùng trong quá trình sử dụng các API của máy chủ [33] Mã này có thể được gửi kèm trong chuỗi truy vấn (query string), header hoặc tham số (parameter) của yêu cầu Tương tự như hai phương pháp trên, phương thức HTTPS nên được yêu cầu sử dụng để đảm bảo an toàn Xác thực sử dụng API Key được tiến hành với các bước sau:

1 Người dùng thực hiện việc xác thực với máy chủ thông qua tên đăng nhập và mật khẩu.

2 Máy chủ xác thực kiểm tra các thông tin trên và trả về API key.

3 Người dùng thực hiện yêu cầu API kèm theo API key.

4 Máy chủ kiểm tra API key và trả về dịch vụ được yêu cầu thực hiện.

Người dùng Máy chủ xác thực

1 Xác thực (tên đăng nhập:mật khẩu)

3 Yêu cầu kèm theo API key

4 Trả về dịch vụ được yêu cầu Máy chủ API

Hình 3.3: Quá trình xác thực sử dụng API Key

OAuth 2.0

OAuth là một phương thức cung cấp cho người dùng khả năng ủy quyền cho một ứng dụng hoặc trang web truy cập cập vào tài nguyên thay cho họ mà không cần chia sẻ các yếu tố dùng để xác thực (thường là tên đăng nhập và mật khẩu) [34]. Phiên bản 1.0 được ra mắt vào tháng 12/2007 [35] và phiên bản 2.0 được công bố vào tháng 10/2012 [36] nhằm thay thế các phiên bản trước đó Đây là một kiến trúc theo hướng client - server mà ở đó người dùng (client) truy cập vào dịch vụ được bảo vệ sử dụng chứng chỉ truy cập của họ Chứng chỉ này trong mô hình OAuth được cấp bởi máy chủ xác thực cho những ai có nhu cầu truy cập vào dịch vụ được bảo vệ ấy [37].

Các thực thể tham gia vào quá trình xác thực này bao gồm [36]:

3.1.CÁC MÔ HÌNH XÁC THỰC NGƯỜI DÙNG 31

• Client: ứng dụng mà người dùng sử dụng để truy cập vào dịch vụ hay dữ liệu được bảo vệ.

• Resource Owner (RO): người dùng hoặc máy chủ với khả năng yêu cầu để truy cập vào các tài nguyên được bảo vệ.

• Authorization Server: nhà cung cấp định danh (Identity Provider - IdP) hoặc máy chủ xác thực có vai trò cung cấp các mã truy cập (access token) vào tài nguyên được bảo vệ và đảm bảo tính xác thực của người sở hữu chúng.

• Resource Server: máy chủ của dữ liệu, dịch vụ được bảo vệ.

Quá trình xác thực và truy cập vào tài nguyên được bảo vệ diễn ra với các bước chính sau (Hình3.4[36]):

1 Client gửi yêu cầu cần được ủy quyền cho RO, nhằm truy cập vào các tài nguyên được bảo vệ.

2 RO cung cấp cho Client các chứng thực cần thiết.

3 RO gửi các chứng thực cho Authorization Server, yêu cầu mã truy cập đến tài nguyên được bảo vệ.

4 Authorization Server kiểm tra các chứng thực và trả về mã truy cập, đại diện cho việc người dùng này đã được xác thực và có quyền truy cập.

5 RO gửi yêu cầu truy cập dịch vụ, dữ liệu được bảo vệ đến Resource Server kèm theo mã truy cập.

6 Resource Server xác thực mã được gửi đến và trả về thông tin được yêu cầu.

OAuth hoạt động dựa trên cơ chế bằng chứng sở hữu (proof-of-possession), yêu cầu Client phải có các mã để truy cập đến các tài nguyên được bảo vệ Các mã này được cấp khi Client xác thực thành công (ở bước 4) với 2 loại:

• Access Token: mã truy cập dùng để truy cập vào tài nguyên được bảo vệ, thường có hiệu lực trong một thời gian nhất định.

• Refresh Token: mã làm mới, được sử dụng để lấy mã truy cập mới trong trường hợp các mã này hết hạn hoặc trở nên không hợp lệ.

Mô hình OAuth cũng dễ tổn thương trước một số loại tấn công và đã được phân tích trong bài báo hội nghị "Security Flows in OAuth 2.0 Framework: A Case Study" [37] bao gồm:

6 Tài nguyên được bảo vệ

Hình 3.4: Quá trình xác thực đơn giản của OAuth

• HTTP 307 Redirect Attack: hình thức này dựa vào việc Authorization Server sử dụng mã trạng thái (status code) 307 thay cho 303 trong quá trình chuyển hướng người dùng, dẫn đến việc các chứng thực người dùng cũng được gửi theo trong quá trình này [37][38].

• Cross Site Request Forgery (CSRF): trong loại hình này, kẻ tấn công sẽ dụ người dùng truy cập vào đường dẫn nguy hiểm nhằm sử dụng trình duyệt họ để gửi các yêu cầu đến RO, thực hiện việc xác thực mà người dùng không hay biết [37][38].

• Mixing IdP Redirect End-Point: loại tấn công này nhằm mục đích lấy được mã xác thực (authorization token) và từ đó giả mạo người dùng dựa vào việc thay đổi địa chỉ IdP thành địa chỉ giả mạo khi thực hiện yêu cầu đến RO [37].

Các dịch vụ xác thực người dùng

Single Sign-On (SSO)

SSO là dịch vụ xác thực cho phép người dùng sử dụng một bộ thông tin xác thực (như tên và mật khẩu) duy nhất để thực hiện việc truy cập vào các ứng dụng, trang web khác nhau SSO hoạt động dựa trên sự tin tưởng giữa nhà cung cấp dịch (service provider - SP) và nhà cung cấp danh tính (identity provider - IdP), thông qua các chứng chỉ được trao đổi giữa hai thành phần này SSO được thực hiện với quá trình như sau [39]:

• Ứng dụng người dùng truy cập vào dịch vụ của SP.

• SP gửi yêu cầu cung cấp token đến ứng dụng người dùng.

3.2.CÁC DỊCH VỤ XÁC THỰC NGƯỜI DÙNG 33

• IdP kiểm tra xem ứng dụng người dùng đã được đăng nhập chưa, nếu đã được đăng nhập, quá trình sẽ tiếp tục ở bước 5.

• Nếu ứng dụng người dùng chưa đăng nhập, quá trình này sẽ diễn ra thông qua việc người dùng cung cấp các chứng chỉ đăng nhập được yêu cầu bởi IdP.

• IdP trả về token xác nhận quá trình xác thực thành công.

• Token được gửi đến SP.

• Token được kiểm tra dựa trên các chứng chỉ được trao đổi trước đó giữa SP và IdP item Ứng dụng người dùng được cấp quyền truy cập vào dịch vụ của SP.

1 Người dùng truy cập dịch vụ

3 Kiểm tra quyền truy cập

8 Dịch vụ được yêu cầu

4 Thực hiện xác thực người dùng nếu cần thiết

Một vài dịch vụ SSO đang được sử dụng hiện nay được thể hiện qua bảng3.1.

Auth0

Auth0 cung cấp một nền tảng để xác thực, ủy quyền và truy cập an toàn cho các ứng dụng, thiết bị và người dùng Nguyên lý hoạt động trong việc ủy quyền người dùng trong Auth0 được thực hiện dựa trên tiêu chuẩn RFC 6749 - mục 4.1, trong đó trao đổi Authorization Code để lấy token Quá trình trên thực hiện thông qua các bước sau (Hình3.6[40]):

1 Người dùng ấn Đăng nhập trên ứng dụng.

Nhà cung cấp Active Directory Federation Services Microsoft

CAS / Central Authentication Service Apereo

CoSign single sign on University of Michigan

IceWall SSO Hewlett-Packard Enterprise

IBM Enterprise Identity Mapping IBM

Keycloak (Red Hat Single Sign-On) Red Hat

Microsoft account Microsoft myOneLogin VMware

Numina Application Framework Numina Solutions

OpenAM Open Identity Platform Community

Oracle Identity Management Oracle Corporation

Ubuntu Single Sign On Canonical Ltd.

Bảng 3.1: Một số dịch vụ SSO

3.2.CÁC DỊCH VỤ XÁC THỰC NGƯỜI DÙNG 35

2 SDK của Auth0 chuyển hướng người dùng đến Auth0 Authorization Server.

3 Auth0 Authorization Server chuyển hướng người dùng đến hộp thoại đăng nhập và ủy quyền.

4 Người dùng xác thực và chọn các quyền mà Auth0 sẽ cấp cho ứng dụng.

5 Auth0 Authorization Server chuyển hướng người dùng trở lại ứng dụng với authorization code, được sử dụng một lần.

6 SDK của Auth0 gửi mã này đến Auth0 Authorization cùng với ID và mã bí mật của ứng dụng.

7 Auth0 Authorization Server xác minh các mã này.

8 Auth0 Authorization Server trả về một ID Token và Access Token.

9 Ứng dụng có thể sử dụng Access Token để các API.

10 API trả về kết quả được yêu cầu.

Hình 3.6: Quá trình xác thực và ủy quyền của Auth0

Google Sign In

Google Sign In là một hệ thống xác thực an toàn giúp giảm gánh nặng đăng nhập cho người dùng bằng cách cho phép họ đăng nhập bằng tài khoản Google của họ (Hình3.7[41]) Nguyên lý hoạt động của quá trình này diễn ra tương tự như Auth0

- sử dụng Authorization Code (one-time code) sau khi đăng nhập để lấy token truy cập vào hệ thống.

Hình 3.7: Quá trình xác thực và ủy quyền của Google Sign In

Các nghiên cứu tăng cường bảo mật

Bài báo "Two-Factor Authentication: Too Little, Too Late"

Bài báo [42] này đã nêu ra những vấn đề mà xác thực hai yếu tố có thể giải quyết cũng như những các nêu ra hạn chế mà phương pháp này còn gặp phải, như đối phó đối với các mối đe dọa phishing, Trojan horses và MITM Phương pháp bổ sung này sẽ giải quyết được các vấn đề của việc sử dụng mật khẩu đơn thuần đang gặp phải: dễ bị mất kiểm soát thông qua việc chia sẻ, được ghi chép lại trên giấy và dễ đoán Việc thêm yếu tố thứ hai sử dụng một thành phần được thay đổi theo thời gian sẽ khắc phục được các yếu điểm trên bởi việc ghi chép và đoán được sẽ gần như không thể thực hiện một cách hiệu quả.

3.4.CÁC CÔNG CỤ,THƯ VIỆN KIỂM THỬ VÀ ĐÁNH GIÁ BẢO MẬT 37

Bài báo "A secure method for signing in using quick response

SPONSE CODES WITH MOBILE AUTHENTICATION "

Qua bài báo [43] này, tác giả đã khắc phục được các yếu điểm của phương pháp đăng nhập truyền thống sử dụng dụng mật khẩu bằng việc xác thực sử dụng mã

QR với sự tham gia của thiết bị di động Từ đó đã loại bỏ đi các yếu tố tấn công nguy hiểm đối với mật khẩu người dùng như xem trộm, phần mềm gián điệp (như keylogger), tạo ra phương thức xác thực an toàn trong các môi trường không đáng tin cậy.

Các công cụ, thư viện kiểm thử và đánh giá bảo mật

OWASP ZAP (Zed Attack Proxy)

OWASP ZAP là một phần mềm kiểm tra bảo mật cho ứng dụng ở dạng động (Dy- namic Application Security Testing - DAST) mã nguồn mở, có thể được sử dụng để kiểm thử các lỗi sau trong hệ thống [44][45]:

• Source Code Disclosure (Git, SVN).

Burp Suite

Burp Suite [46] là một trong những công cụ kiểm tra thâm nhập và tìm lỗ hổng web app và API phổ biến Burp Suite là một công cụ dựa trên proxy được sử dụng để đánh giá tính bảo mật của các ứng dụng Được tích hợp các mô đun mạnh mẽ và được đóng gói với các phần mở rộng tùy chọn có thể tăng hiệu quả kiểm tra ứng dụng web Burp Suite là một công cụ pentest hỗ trợ các tác vụ cơ bản cho cho đội ngũ phát triển trong quá trình kiểm thử xâm nhập Giao diện của Burp cũng rất trực quan và thân thiện (Hình3.8) Các request được gửi (Request) cũng như phản hồi từ phía server (Response) được thể hiện một cách trực quan và rõ ràng.

Hình 3.8: Giao diện của Burp Suite

Một số tính năng nổi bật của Burpsuite:

• Interception Proxy: được thiết kế để bắt các request từ đó có thể tùy ý sửa đổi trước khi các request này được gửi lên server.

• Repeater: cho phép sử dụng một request trước đó và tùy sửa đổi nội dung request một cách nhanh chóng nhiều lần khác nhau.

• Intruder: tự động hóa việc gửi hàng loạt các request có chứa các payload tương tự nhau lên server Decoder: decode và encode string theo các format khác nhau (URL, Base64, HTML, ).

• Comparer: chỉ ra sự khác nhau giữa các requests/responses Extender: API để mở rộng chức năng của Burp Suite Người dùng có thể download các exten- sions thông qua Bapp Store Spider & Discover Content: crawl link có trong ứng dụng web.

• Scanner: đây là một mô đun khác mạnh mẽ, nó tự động quét các lỗ hổng trong ứng dụng web (XSS, SQLi, Command Injection, File Inclusion, ).

Công cụ StackHawk

StackHawk là một công cụ kiểm tra bảo mật ứng dụng động tích hợp với các chức năng chính bao gồm:

3.4.CÁC CÔNG CỤ,THƯ VIỆN KIỂM THỬ VÀ ĐÁNH GIÁ BẢO MẬT 39

• Kiểm tra bảo mật tự động ứng dụng.

• Phân tích mã nguồn động để xác định các rủi ro và lỗ hổng bảo mật.

• Tích hợp CI & CD, được sử dụng rộng rãi trong quá trình phát triển phần mềm.

Công cụ DAST này được xây dựng dựa trên ZAP, với mục tiêu đơn giản hóa và tối ưu quá trình tìm kiếm các lỗ hổng bảo mật trong hệ thống [47].

C ÁC LỖ HỔNG , MỐI ĐE DỌA VÀ RỦI RO

TRONG BẢO MẬT VÀ XÁC THỰC

Trong chương này, các lỗ hổng, mối đe dọa và rủi ro của một vài quá trình sau sẽ được đề cập đến, bao gồm:

• Quản lý danh tính (Identity management).

• Quản lý phiên (Session management).

• Kiểm tra đầu vào (Input validation).

Vulnerability, threat và risk

• Vulnerability(lỗ hổng bảo mật): là một lỗ hổng hoặc điểm yếu trong thiết kế, triển khai, vận hành hoặc quản lý hệ thống có thể bị lợi dụng để xâm phạm các mục tiêu bảo mật của hệ thống

• Threat (mối đe dọa): là bất kỳ thứ gì (kẻ tấn công độc hại bên ngoài, người dùng nội bộ, hệ thống không ổn định, ) có thể gây hại cho tài sản do ứng dụng sở hữu (tài nguyên có giá trị, chẳng hạn như dữ liệu trong cơ sở dữ liệu hoặc trong hệ thống tệp) thông qua việc khai thác lỗ hổng bảo mật.

Quản lý danh tính (Identity management)

Đoán và liệt kê các tài khoản

Thông thường, việc ứng dụng web tiết lộ tên người dùng tồn tại trên hệ thống có thể được xuất từ cấu hình sai hoặc do quyết định trong quá trình thiết kế Ví dụ khi một thông tin đăng nhập bị gửi sai, hệ thống sẽ trả về kết quả cho biết liệu người dùng này có tồn tại trong hệ thống hay là mật khẩu cung cấp cho tài khoản bị sai. Thông tin này có thể bị kẻ tấn công sử dụng để lấy danh sách người dùng trên hệ thống Sau đó, thông tin trên có thể được sử dụng để tấn công ứng dụng web thông qua tấn công vét cạn hoặc tấn công sử dụng các tên đăng nhập và mật khẩu mặc định.

K HẮC PHỤC Đảm bảo ứng dụng trả về các thông báo lỗi thống nhất nếu tên tài khoản, mật khẩu không hợp lệ trong quá trình đăng nhập (như "Sai tên đăng nhập hoặc mật khẩu").Ngoài ra, đảm bảo các tài khoản hệ thống mặc định và tài khoản thử nghiệm bị xóa trước khi đưa hệ thống vào sử dụng (hoặc để hệ thống tiếp xúc với môi trường mạng không đáng tin cậy).

Xác thực (Authentication)

Phương thức khóa tài khoản yếu kém

Cơ chế khóa tài khoản được sử dụng để giảm thiểu các cuộc tấn công đoán mật khẩu theo phương hướng brute force Tài khoản thường bị khóa sau 3 đến 5 lần đăng nhập không thành công và chỉ có thể được mở khóa với một trong các điều kiện sau:

• Sau một khoảng thời gian định trước.

• Thông qua cơ chế mở khóa tự phục vụ (self-service unlock).

• Can thiệp của quản trị viên.

Cơ chế khóa tài khoản yêu cầu phải yêu cầu đảm bảo được sự cân bằng giữa việc bảo vệ tài khoản khỏi truy cập trái phép và bảo vệ người dùng khỏi việc bị từ chối truy cập dịch vụ Nếu không có cơ chế khóa hoặc cơ chế không đủ mạnh, ứng dụng có thể dễ dàng bị tấn công brute force Khi đó, các thông sau có thể bị truy cập vào trái phép:

• Thông tin hoặc dữ liệu bí mật: các phần riêng tư của ứng dụng web có thể tiết lộ tài liệu bí mật, dữ liệu hồ sơ của người dùng, thông tin tài chính, chi tiết tài khoản ngân hàng, mối quan hệ của người dùng,

• Bảng điều khiển của quản trị viên: có thể được sử dụng để thay đổi nội dung ứng dụng web, các đặc quyền của người dùng,

• Cơ hội cho các cuộc tấn công tiếp theo: các thành phần ẩn của ứng dụng có thể chứa các lỗ hổng bảo mật hoặc các chức năng nâng cao, cho phép kẻ tấn công khai thác các lỗ hổng này.

Việc áp dụng cơ chế khóa tài khoản được thực hiện dựa trên thang đo về rủi ro,đảm bảo theo thứ tự từ thấp đến cao nhất.

Bypass quá trình xác thực

Mặc dù hầu hết các ứng dụng đều yêu cầu xác thực để có quyền truy cập vào các thông tin bí mật hoặc thực hiện các thao tác Việc sơ suất, thiếu hiểu biết trong nhận thức về các mối đe dọa bảo mật thường dẫn đến việc các trang bên được bảo vệ bên trong (vốn cần được đăng nhập để sử dụng) có thể bị truy cập dễ dàng. Ngoài ra, các biện pháp xác thực này có thể bị bypass bằng cách đánh lừa ứng dụng rằng người dùng đó đã được xác thực Quá trình này có thể được thực hiện qua việc thay đổi các tham số của URL, thao tác với biểu mẫu hoặc chỉnh sửa các sessions.

G IẢI PHÁP Đảm bảo các chứng chỉ xác thực không được lưu trữ ở dạng văn bản thô hoặc có thể dễ dàng giải mã được Ngoài ra, thực hiện các kiểm thử bảo mật trong quá trình này nhằm đảm bảo không tồn tại các lỗ hổng có thể được dùng để tấn công như:

• Truy cập thẳng đến tài được bảo vệ.

• Thay đổi các tham số.

• Tiên đoán các mã session.

Yêu cầu về mật khẩu yếu

Mật khẩu tĩnh là cơ chế xác thực phổ biến nhất dễ quản lý nhất trong việc xác thực người dùng Tuy nhiên chúng thường được đánh giá thấp bởi người dùng trong quá trình sử dụng, với việc các mật khẩu như 123456, password và qwerty vẫn được sử dụng phổ biến nhất.

G IẢI PHÁP Để giảm thiểu nguy cơ mật khẩu có thể dễ dàng bị doán được và tạo điều kiện cho việc truy cập trái pháp được diễn ra, hai giải pháp sau có thể được thực hiện:

• Thêm một biện pháp kiểm soát xác thực (như xác thực đa yếu tố).

• Đưa ra chính sách mật khẩu đảm bảo về độ dài, tính phức tạp và khả năng tái sử dụng.

Điểm yếu trong quá trình thay đổi, khôi phục mật khẩu

Chức năng thay đổi và đặt lại mật khẩu của một ứng dụng cho phép người dùng nhanh chóng thay đổi hoặc đặt lại mật khẩu của mình mà không cần quản trị viên can thiệp Khi mật khẩu được đặt lại, chúng sẽ thường được gửi qua email cho người dùng Điều này cho thấy mật khẩu đã có thể được lưu trữ ở dạng văn bản thô hoặc định dạng có thể giải mã được.

Chức năng thay đổi hoặc đặt lại mật khẩu là một chức năng nhạy cảm và cần yêu cầu một số hình thức bảo vệ, chẳng hạn như yêu cầu người dùng xác thực lại sau quá trình thao tác.

Ủy quyền (Authorization)

Bypass quá trình ủy quyền

Các lỗ hổng này thường được xuất phát từ việc thiếu sót trong quá trình hiện thực cơ chế phân quyền cho cho hệ thống, cho phép việc thực hiện cách hành vi như:

• Truy cập vào tài nguyên khi không được xác thực và cấp quyền.

• Truy cập vào tài nguyên ngay cả khi đã đăng xuất.

• Truy cập vào tài nguyên ngoài quyền hạn được cấp.

Các hành vi này có thể được lợi dụng bởi các kẻ tấn công, gây ra các hậu quả như tiết lộ, thay đổi hoặc xóa các thông tin quan trọng trong hệ thống.

Vấn đề này có thể được loại bỏ thông qua việc thực hiện các bài kiểm thử trong hệ thống nhằm kiểm tra quyền truy cập tương ứng với các vai trò người dùng đã được định nghĩa trước đó.

Privilege escalation

Privilege escalation xảy ra khi người dùng có quyền truy cập vào nhiều tài nguyên hoặc chức năng hơn mức họ được cho phép Điều này thường được gây ra bởi một lỗ hổng trong ứng dụng, dẫn đến ứng dụng có thể cho phép việc người dùng có đặc quyền cao hơn so với những gì mà hệ thống được thiết kế Có hai loại privilege escalation:

• Vertical escalation: khi người dùng có quyền truy cập vào tài nguyên của người có quyền hạn cao hơn.

• Horizontal escalation: khi người dùng có khả năng truy cập vào các tài khoản cùng cấp khác trong hệ thống (như xem thông tin tài khoản của các người dùng khác trong ứng dụng ngân hàng).

Ba giải pháp sau có thể được sử dụng để chống lại loại hình trên, gồm:

• Lưu trữ các thông tin quan trọng ở phía máy chủ.

• Ngăn chặn việc sử đổi thông tin gửi đến người dùng (qua chữ ký số).

• Mã hóa dữ liệu gửi đến người dùng.

Quản lý phiên (Session management)

Session Fixation

Lỗ hổng này được xảy ra với các tình huống sau:

• Ứng dụng web xác thực người dùng mà không vô hiệu session ID trước đó mà tiếp tục sử dụng chúng cho người dùng.

4.6.KIỂM TRA ĐẦU VÀO(INPUT VALIDATION) 45

• Kẻ tấn công cố ý gán một giá trị session ID biết trước vào người dùng Để khi họ được xác thực, kẻ tấn công cũng có quyền truy cập vào phiên làm việc đó.

Loại hình tấn công này có thể được khắc phục bằng cách tạo lại một session ID mới trong quá trình xác thực.

CSRF (Cross Site Request Forgery)

CSRF là cách thức tấn công buộc người dùng thực hiện các hành động không mong muốn trên ứng dụng web mà họ hiện đang được xác thực Với sự trợ giúp của công cụ social engineering (như gửi liên kết qua email hoặc cuộc trò chuyện), kẻ tấn công có thể buộc ứng dụng đó thực hiện các hành động mà chúng mong muốn. Việc khai thác thành công lỗ hổng này có thể làm tổn hại để dữ liệu và hoạt động của người dùng Nếu tài khoản được tấn công là của quản trị viên, quá trình này có thể chiếm toàn bộ ứng dụng web.

Giải pháp có thể được thực hiện dựa trên hai phương diện khác nhau:

– Đăng xuất ngay sau khi sử dụng ứng dụng.

– Không cho phép trình duyệt lưu tên người dùng / mật khẩu và tắt tính năng ghi nhớ người dùng.

– Không sử dụng cùng một trình duyệt để truy cập các ứng dụng chứa nhạy cảm và lướt web thông thường.

• Về phía nhà phát triển: Thêm thông tin liên quan đến phiên vào URL, làm tăng độ phức tạp cho kẻ tấn công trong việc tìm ra cấu trúc URL để thực hiện quá trình trên.

Kiểm tra đầu vào (Input validation)

Reflected Cross Site Scripting

Loại tấn công này xảy ra khi kẻ tấn công chèn vào một đoạn mã có thể thực thi bởi trình duyệt vào phản hồi HTTP Phương thức này chỉ ảnh hưởng đến người dùng truy cập vào đường link giả mạo được tạo bởi kẻ tấn công bởi các đoạn mã này không được lưu trữ trong ứng dụng Các đoạn mã được chèn vào tham số hoặc URI sẽ được xử lý bởi trình duyệt, và do đó trả về các kết quả ngoài ý muốn đến người dùng.

Reflected Cross Site Scripting có thể được ngăn chặn thông qua việc xử lý và lọc các dữ liệu đầu vào của ứng dụng, sử dụng tường lửa của trang web hoặc sử dụng cơ chế có sẵn trong các trình duyệt hiện đại.

Stored Cross Site Scripting

Stored Cross Site Scripting là một hình thức nguy hiểm nhất của Cross Site Script- ing Các ứng dụng cho phép người dùng lưu trữ thông tin để có thể gặp lỗ hổng này.

Quá trình tấn công trên xảy ra xảy ra khi một ứng dụng web thu thập thông tin đầu vào từ một người dùng (có thể độc hại) và lưu trữ thông tin đó để sử dụng sau mà không lọc dữ liệu độc hại này Do vậy, dữ liệu độc hại này xuất hiện như một phần trong ứng dụng và được thực thi bên trong trình duyệt người dùng dưới quyền hạn của ứng dụng.

Tương tự như Reflected Cross Site Scripting, giải pháp này có thể được ngăn chặn thông qua việc lọc và xử lý dữ liệu đầu vào của người dùng trước khi được lưu trữ trong hệ thống.

SQL Injection

Loại hình này được thực hiện qua việc chén một đoạn mã SQL (một phần hoặc câu lệnh hoàn chỉnh) vào dữ liệu đầu vào hoặc dữ liệu được truyền tải từ phía trình duyệt đến ứng dụng Việc tấn công thành công cho phép việc có thể đọc dữ liệu nhạy cảm, sửa đổi dữ liệu cơ sở dữ liệu (chèn / cập nhật / xóa), thực hiện các hoạt động quản trị trên cơ sở dữ liệu (chẳng hạn như tắt DBMS), khôi phục nội dung của một tệp nhất định hiện có trên hệ thống DBMS Ví dụ, khi biết được hệ thống truy vấn đăng nhập sử dụng câu lệnh sau

WHERE Username=’$username’ AND Password=’$password’

4.6.KIỂM TRA ĐẦU VÀO(INPUT VALIDATION) 47 kẻ tấn công có thể nhập giá trịusernamevàpasswordnhư sau để có thể tiến hành việc bỏ qua quá trình đăng nhập:

Khi đó, câu lệnh truy vấn sẽ là:

WHERE Username=’1’ OR ’1’ = ’1’ AND Password=’1’ OR ’1’ = ’1’

Các giải pháp sau có thể được thực hiện để chống lại hình thức tấn công này:

• Tham số hóa các câu lệnh.

• Thoát các ký tự đặc biệt trong đầu vào.

• Từ chối các dữ liệu đầu vào có tính nghi ngờ (như khác các tiêu chuẩn về định dạng dữ liệu).

Phân tích yêu cầu

Định dạng chuỗi bí mật trong mô hình

Với việc sử dụng chuỗi bí mật trong quá trình tương tác, trao đổi thông tin giữa các thực thể với mô hình, định dạng JWT (JSON Web Token) [48] sẽ được sử dụng với các ưu điểm của nó như:

• Stateless: máy chủ không cần phải lưu trữ các mã này, các thông tin liên quan đến phiên đăng nhập, thời gian hết hạn sẽ được lưu trữ bên trong JWT với sự bảo mật của chữ ký số.

• Đảm bảo quá trình tạo và kiểm tra mã diễn ra nhanh chóng.

• Dễ dàng mở rộng: có thể lưu trữ thêm các thông tin bổ sung vào JWT khi cần thiết.

Mã JWT được cấu thành từ 3 thành chính gồm header, payload và signauture, được biểu diễn ở dạng Base64Url và nối với nhau bởi dấu chấm (".").

Mỗi thành phần trong JWT chứa các loại thông tin sau:

• Header: chứa các thông tin về loại mã và giải thuật được sử dụng trong việc xây dựng chữ ký số.

• Payload: chứa các thông tin liên quan đến việc xác thực và thông tin người dùng Có thể bao gồm các trường thông tin (claims) được đăng ký trong IANA như người cấp(iss), thời điểm cấp(iat), thời điểm hết hạn(exp)hoặc chứa các thông tin do mô hình tự định nghĩa như mã người dùng(USER_ID), mã định danh nguồn gốc(ORIGIN),

• Signature: chứa thông tin về chữ ký số, được sinh ra với quá trình sau:

– Dữ liệu trong header và payload sẽ được biểu diễn lại ở dạng Base64Url và nối với nhau bỏi dấu chấm (".").

– Giải thuật được định nghĩa trong header sẽ được sử dụng lên chuỗi vừa được tạo trên cùng với khóa bí mật tương ứng.

+0$&6+$ ơơEDVH8UO(QFRGHKHDGHUơ ơơEDVH8UO(QFRGHSD\ORDGơNH\

Chữ ký xác thực eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9. eyJPUklHSU4iOiI2ZmY2Li4uZGVhZCIsIlVTRVJfSUQiOiI0MTA5

AiOjE2MjcwNTY1OTgsImlhdCI6MTYyNzA1NjQ3OH0.

UK3LG9pm-NAcCxGzCe6AZtcW7U0S8-SCe6eSUhNvYtMvPml nf09J8mMGvvdeSuPOvu4z-9gVacs7S6vTzhN7cg

Hình 5.2: Các thành phần trong JWT

Ngoài ta, để phục vụ hiệu quả cho quá trình xác thực và ủy quyền trong hệ thống, các claims sau sẽ được lưu vào nội dung của JWT trong quá trình cung cấp cho người dùng, bao gồm:

• exp: thời điểm hết hạn của mã, tính theo giây trong hệ thời gian Unix.

• iat: thời điểm mã được cấp, tính theo giây trong hệ thời gian Unix.

• USER_ID: mã định danh của người dùng, được gán tự động khi người dùng đăng ký hệ thống.

• ORIGIN: kết quả băm của mã định danh thiết bị (UID) sử dụng giải thuậtSHA-256.UIDduy nhất này được sinh ra bởi ứng dụng cho mỗi thiết bị được cài đặt Giá trị này được sử dụng để xác định danh tính của thiết bị mà mãJWT cung cấp, từ đó giới hạn thiết bị mà mã được cấp có thể được sử dụng.

Các loại mã JWT trong hệ thống

Nhằm giảm thiểu rủi ro trong quá trình tương tác, mô hình sẽ sử dụng hai loại mã access token và refresh token (sử dụng định dạng JWT) trong việc tương tác và trao đổi thông tin, với chức năng cụ thể như sau:

• Access token (AT): dùng để truy cập vào các dịch vụ được hỗ trợ trong hệ thống, mã này sau đó được máy chủ dịch vụ chuyển tiếp đến máy chủ xác thực để kiểm tra AT có thời gian tồn tại ngắn (như 30 phút, có thể thay đổi phụ thuộc vào tính chất hệ thống), nhằm giảm thiểu thiệt hại có thể xảy ra khi mã này bị tiết lộ ClaimIS_ACCESS_TOKEN với giá trịtruesẽ được thêm vào JWT nhằm xác định loại mã này.

• Refresh token (RT): được dùng để thực hiện việc cấp lại AT khi chúng hết hạn mà không cần đến sự tương tác của người dùng RT có thời gian tồn tại dài hơn AT (như 30 ngày, có thể thay đổi phụ thuộc vào tính chất hệ thống), cho phép người dùng sử dụng ứng dụng trong khoảng thời gian này mà không cần đăng nhập lại ClaimIS_REFRESH_TOKEN với giá trịtruesẽ được thêm vào JWT nhằm xác định loại mã này.

Thu hồi các chuỗi bí mật

Với việc sử dụng JWT trong việc trao đổi thông tin, việc vô hiệu hóa các token này đang bị phụ thuộc vào thời điểm hết hạn của chúng Để có thể chủ động trong việc thu hồi các token này, cơ chế blacklist sẽ được sử dụng với mục tiêu loại bỏ các token đã được thu hồi trong quá trình kiểm chứng chúng Các mã bị blacklist sẽ được lưu vào một bộ nhớ đệm (cache) nhằm tăng tốc độ trong quá trình truy xuất và kiểm tra Ngoài ra, để tiết kiệm không gian lưu trữ, các token trong danh sách blacklist sẽ được lưu với thời gian tồn tại (TTL) bằng thời gian còn lại trước khi chúng được hết hạn. Đối với việc thu hồi tất cả các token thuộc một người dùng, một cơ chế blacklist khác sẽ được sử dụng: ghi lại thời điểm cấp token tối thiểu (không được cấp trước thời điểm này) cho mỗi người dùng, lưu trữ với hai thông tin tương ứngUSER_ID vàNOT_ISS_BEFORE Phương thức này có thể được mình họa thông qua một kịch bản như sau:

1 Người dùng đăng nhập vào hệ thống, AT và RT sẽ được cấp tại thời điểm này vớit LOG _ I N 27028319.

2 Người dùng sử dụng AT để truy cập vào hệ thống, truy cập hợp lệ vì không có

3 Ở một thiết bị khác (đã được đăng nhập trước đó), người dùng tiến hành cập nhật mật khẩu và hệ thống tự động đăng xuất người dùng ra khỏi tất cả các thiết bị Khi đó, cơ chế thu hồi tất cả token sẽ được sử dụng, lưu trữ thời gian đăng xuất của người dùng tại thời điểm đó vớiNOT_I SS_B E F ORE t LOG _ OU T 27035519, với t LOG _ OU T >t LOG _ I N

4 Người dùng sử dụng AT để truy cập vào hệ thống, truy cập bị từ chối vì AT được cấp trước thời điểm tối thiểu được lưu trữ trong hệ thống (t LOG _ I N Cập nhật giá trị PERMISSION, CLAIMED_USER_ID tương ứng.

QR_CODE: c4ca 849b CLAIMED_USER_ID: user1 PERMISSION: Đã được sử dụng

(bước 5) Đã được sử dụng để đổi lấy AT, RT

=>Xóa khỏi cache sau khi được truy vấn và sử dụng để đổi lấy AT, RT. Được xóa khỏi cache

Bảng 5.1: Giá trị lưu trữ liên quan đến mã QR trong quá trình thực hiện

Quá trình tạo và kiểm tra cho mã khôi phục mật khẩu

Mã khôi phục mật khẩu(RESET_TOKEN)có chiều dài 128 ký tự được sinh ra ngẫu nhiên sử dụng định dạng Base64Url, được sử dụng như một chứng chỉ tạm thời nhằm thực hiện quá trình đặt lại mật khẩu Sử dụng cơ chế whitelist,RESET_TOKEN sẽ được lưu vào cache với thời gian tồn tại là 2 phút và chỉ có thể được sử dụng một lần Vì thế, sau khiRESET_TOKEN được truy xuất và sử dụng, nó sẽ được xóa khỏi cache, đảm bảo việc tái sử dụng mã này là không khả thi.

Hiện thực khối quản lý thông tin người dùng

Vì không cần lưu trữ các thông tin đến phiên làm việc trong quá trình xác thực, hệ cơ sở dữ liệu chỉ lưu trữ các thông tin cơ bản của người dùng, gồm:

Các thông tin trên sẽ được kiểm tra và xử lý trước khi được lưu trữ, đặc biệt là đối với thông tin cần tính bảo vệ cao như mật khẩu Trong quá trình này, mật khẩu sẽ được kiểm tra với các tiêu chí sau để đảm bảo an toàn cho tài khoản người dùng:

• Độ dài tới thiểu 12 ký tự.

Hiện thực khối logic chức năng

Đăng ký người dùng

Nhằm có thể sử dụng mô hình đề xuất này, người dùng cần thực hiện việc đăng ký tài khoản với các thông tin cá nhân cần thiết (được mô tả trong phần trước) Quá trình đăng ký này sẽ diễn ra với các bước chính sau (Hình5.6):

1 Ứng dụng gửi yêu cầu đăng ký với các thông tin đã được nhập bởi người dùng.

2 Máy chủ kiểm tra thông tin và lưu trữ:

• Máy chủ truy kiểm tra thông tin đầu vào: trong bước này, các thông tin gửi từ người dùng sẽ được kiểm tra định dạng Đối với mật khẩu, các tiêu chí sẽ được kiểm tra thông qua sử dụng biểu thức chính quy (regular expression) nhằm đảm bảo các yêu cầu về bảo mật.

• Máy chủ truy vấn thông tin từ cơ sở dữ liệu và kiểm tra thông tin trùng lặp: quá trình kiếm tra này được thực hiện nhằm đảm bảo mỗi người dùng đều có một số điện thoại và địa chỉ email duy nhất.

• Máy chủ lưu thông tin vào cơ sở dữ liệu: trong quá trình lưu trữ này, mật khẩu sẽ được xử lý sử dụng giải thuật bcrypt trước khi lưu trữ xuống hệ cơ sở dữ liệu.

3 Máy chủ trả về yêu cầu thành công.

5.5.HIỆN THỰC KHỐI LOGIC CHỨC NĂNG 59

1 Yêu cầu đăng ký với thông tin cần thiết

3 Đăng ký thành công Ứng dụng

2 Kiểm tra và lưu trữ

Hình 5.6: Quá trình đăng ký người dùng

Đăng nhập (sử dụng mật khẩu và OTP)

Trong hệ thống được dề xuất, quá trình này sẽ được thực hiện với cơ chế xác thực đa yếu tố: sử dụng thêm mã OTP bên cạnh mật khẩu, được gửi đến người dùng thông qua tin nhắn SMS Quá trình đăng nhập sẽ diễn ra với các bước cơ bản sau, được biểu diễn qua hình5.7:

1 Ứng dụng gửi yêu cầu đăng nhập với tên đăng nhập, mật khẩu (nhập từ người dùng).

2 Máy chủ kiểm tra thông tin đăng nhập: thông tin đăng nhập sẽ được tìm kiếm trong cơ sở dữ liệu và so sánh.

3 Máy chủ trả về mã định danh OTP cho ứng dụng và gửi mã xác thực OTP đến SMS người dùng Quá trình này được biểu diễn với các bước chi tiết như sau:

(b) Tạo mã định danh OTP (OTP_TOKEN): dùng để xác định quá trình xác thực OTP đang được diễn ra, được sử dụng duy nhất một lần Mã này được sinh ra sử dụng định dạng JWT với các claims bắt buộc được định nghĩa trước đó, với thời gian hết hạn là 2 phút Ngoài ra, các claims sau sẽ được thêm vào trong quá trình sinh mã:

• IS_AUTH_OTP: có giá trịtrue, thể hiện loại mã được cung cấp trong mô hình.

• OTP_CODE_SIGNATURE: dùng để lưu trữ thông tin về mã OTP, phục vụ cho quá trình kiểm tra mã OTP do người dùng cung cấp Giá trị của claim này sẽ được tạo ra sử dụng giải thuật SHA-256 với dữ đầu vào làUID,USER_IDvà mã OTP.

(c) Gửi mã OTP đến người dùng thông qua dịch vụ SMS.

4 Ứng dụng gửiOTP_CODE_SIGNATURE và mã OTP (nhập bởi người dùng).

5 Máy chủ kiểm traOTP_TOKEN và mã OTP: quá trình kiểm tra này được thực hiện thông qua 2 bước sau:

(a) Kiểm traOTP_TOKEN: thực hiện dựa trên việc kiểm tra mã JWT.

(b) Kiểm tra mã OTP đã nhập: được thực hiện qua việc xây dựng lại giá trị

OTP_CODE_SIGNATURE dựa trên mã OTP nhận được từ người dùng và các giá trị liên quan và so sánh với giá trịOTP_CODE_SIGNATURE được chứa trong mã JWT Sau quá trình này,OTP_TOKEN bị vô hiệu hóa (dù thành công hay thất bại).

6 Máy chủ trả tạo và trả về AT, RT.

1 Tên đăng nhập + mật khẩu

3 Mã định danh OTP Ứng dụng

4 Mã định danh OTP + OTP

6 Mã truy cập + làm mới

Hình 5.7: Quá trình đăng nhập sử dụng mật khẩu và xác thực OTP

Đăng nhập sử dụng mã QR

Với mục tiêu đảm bảo tính an toàn trong quá trình đăng nhập người dùng ở những môi trường không đáng tin cậy, phương pháp đăng nhập sử dụng mã QR có thể được sử dụng để thực hiện việc đăng nhập trên một thiết bị mới, thông qua thiết bị đã được đăng nhập thành công trước đó Giải pháp này sẽ giúp giảm bớt một phần các yếu điểm của phương pháp sử dụng mật khẩu như xem trộm mật khẩu, khả năng ghi nhớ người dùng hoặc yếu tố bên ngoài ảnh hưởng đến quá trình xác thực hai yếu tố (số điện thoại đang ở ngoại tuyến và không thể nhận mã OTP) Hình thức đăng nhập này được thực hiện với sự tham gia của hai đối tượng chính:

• Ứng dụng trên thiết bị mà người dùng đã đăng nhập (D-LOGGED-IN).

• Ứng dụng trên thiết bị mà người dùng đang thực hiện thao tác đăng nhập(D-NEW).

Quá trình đăng nhập này được tiến hành với các bước như sau, được minh họa qua hình5.8:

1 D-NEW gửi yêu cầu cấp mã QR để bắt đầu quá trình này.

2 Máy chủ xác thực trả vềQR_CODE: quá trình tạoQR_CODE được thực hiện và trả về từkhối quản lý việc tạo / xác thực các mã trong hệ thống, với thời gian tồn tại là 2 phút.

3 D-NEW tạo hình ảnh QR từQR_CODE nhận được từ máy chủ: sau quá trình tạo và hiển thị này, D-NEW sẽ định kỳ yêu cầu đến máy chủ để kiểm tra tình trạng xác thực của QR_CODE này Nếu đã được xác thực, máy chủ sẽ tiến hành trả về AT và RT cho D-NEW (tương ứng với bước 3a và 3b).

4 D-LOGGED-IN quét mã QR do D-NEW hiển thị.

5 D-LOGGED-IN gửi yêu cầu xác thực bao gồm AT (khi D-LOGGED-IN đăng nhập) và mã QR vừa quét được.

6 Máy chủ xác thực quá trình đăng nhập cho mã QR: máy chủ tiến hành việc cập nhật các thông tinCLAIMED_USER_ID và PERMISSION tương ứng với

QR_CODEđược lưu trong bộ nhớ đệm.

7 Máy chủ trả về yêu cầu thành công cho D-LOGGED-IN.

Cập nhật thông tin

Việc cập nhật thông tin cá nhân có thể thực hiện bởi người dùng khi họ đã đăng nhập vào hệ thống Mọi thông tin, ngoại trừ số điện thoại, đều có thể được thay đổi khi thực hiện quá trình này Nếu mật khẩu được cập nhật, người dùng sẽ bị đăng xuất ra khỏi các thiết bị đã được đăng nhập trước đó Quá trình trên diễn ra với 3 bước cơ bản (với yêu cầu tài khoản đã được đăng nhập), thể hiện qua hình5.9:

1 Ứng dụng gửi yêu cầu thay đổi thông tin (gồm các thông tin cần được thay đổi và AT).

2 Máy chủ kiểm tra các thông tin và cập nhật với các bước sau:

(b) Kiếm tra định dạng các thông tin gửi từ người dùng, tương tự như quá trình kiểm tra trong giai đoạn đăng ký.

Hình 5.8: Quá trình đăng nhập sử dụng QR

(c) Máy chủ truy vấn thông tin từ cơ sở dữ liệu và kiểm tra thông tin trùng lặp: quá trình kiếm tra này được thực hiện nhằm đảm bảo mỗi địa chỉ email người dùng cung cấp chưa được sử dụng.

(d) Lưu trữ dữ liệu: mật khẩu sẽ được xử lý sử dụng giải thuật bcrypt trước khi lưu trữ xuống hệ cơ sở dữ liệu.

(e) Máy chủ đăng xuất tất cả thiết bị của người dùng (bao gồm thiết bị thực hiện yêu cầu), sử dụng cơ chế thu hồi tất cả token.

1 Yêu cầu cập nhật với danh sách các thông tin cần được thay đổi

3 Yêu cầu thành công Ứng dụng

Hình 5.9: Quá trình cập nhật thông tin

Khôi phục mật khẩu

Quá trình khôi phục mật khẩu sẽ được thực hiện thông qua việc xác nhận danh tính của người dùng sử dụng xác thực OTP, được mô tả trong hình 5.10, với các bước sau:

1 Ứng dụng gửi yêu cầu khôi phục mật khẩu.

2 Máy chủ trả về mã định danh OTP cho ứng dụng và gửi mã xác thực OTP đến SMS người dùng: quá trình này được thực hiện tương tự như quá trình đăng nhập.

3 Ứng dụng gửi mà định danh OTP và mã xác thực OTP (nhập bởi người dùng).

4 Máy chủ kiểm tra các mã định danh và OTP: quá trình kiểm tra này được thực hiện tương tự như quá trình đăng nhập.

5 Máy chủ trả về mã khôi phục mật khẩu(RESET_TOKEN): quá trình tạo RE- SET_TOKEN được thực hiện và trả về từkhối quản lý việc tạo / xác thực các mã trong hệ thống, có thời gian hiệu lực trong 2 phút và chỉ được sử dụng một lần.

6 Ứng dụng gửi mật khẩu mới và mã khôi phục mật khẩu.

7 Máy chủ kiểm tra và cập nhật mật khẩu:

(a) RESET_TOKEN sẽ được kiểm tra tính hợp lệ qua việc truy vấn trong cache.

(b) Kiểm tra độ mạnh mật khẩu (theo các tiêu chuẩn như quá trình đăng ký).

(c) Xử lý mật khẩu (băm mật khẩu sử dụng bcrypt) và lưu vào cơ sở dữ liệu.

(d) Máy chủ đăng xuất tất cả thiết bị của người dùng (bao gồm thiết bị thực hiện yêu cầu).

Đăng xuất

Chức năng này cho phép người dùng đăng xuất ra khỏi ứng dụng trên một thiết bị cụ thể, được thực hiện với 3 bước, thể hiện qua hình5.11:

1 Ứng dụng gửi yêu cầu đăng xuất kèm RT.

1 Yêu cầu khôi phục mật khẩu

4 Kiểm tra Ứng dụng Máy chủ xác thực

5 Mã khôi phục mật khẩu

6 Mã khôi phục mật khẩu và mật khẩu mới

Hình 5.10: Quá trình khôi phục mật khẩu

2 Máy chủ kiểm tra và vô hiệu hóa mã RT.

3 Số điện thoại và quyền hạn truy cập

Máy chủ dịch vụ khác

Hình 5.11: Quá trình đăng xuất trên một thiết bị

Cấp lại mã truy cập (AT)

Việc cấp lại này sẽ được thực hiện tự động bởi ứng dụng khi AT cũ đã hết hạn Quá trình này được thực hiện tự động bởi ứng dụng với 3 bước qua hình5.12:

• Ứng dụng gửi RT, yêu cầu cấp lại AT.

• Máy chủ kiểm tra AT.

• Máy chủ trả về AT mới.

3 Mã truy cập Ứng dụng

Hình 5.12: Quá trình cấp lại mã truy cập

Kiểm tra mã truy cập (RT)

Chức năng này giúp cho dịch vụ sử dụng mô hình xác thực này có thể xác minh tính hợp lệ của các mã truy cập được cung cấp từ ứng dụng, được thực hiện bởi dịch vụ sử dụng mô hình xác thực này qua 3 bước trong hình5.13

• Máy chủ dịch vụ gửi yêu cầu kiểm tra mã truy cập.

• Máy chủ kiểm tra mã truy cập: thông qua xây dựng và so sánh chữ ký số trong JWT.

• Máy chủ trả về số điện thoại người dùng và quyền hạn truy cập: các thông tin của người dùng được giải mã từ thông tin mã hóa lưu trữ trong JWT.

3 Số điện thoại và quyền hạn truy cập

Máy chủ dịch vụ khác

Hình 5.13: Quá trình kiểm tra mã truy cập

Tạm khóa tài khoản theo ràng buộc về số lần thất bại

Quá trình này sẽ diễn ra đồng thời với các chức năng trên, đảm bảo việc chống lại loại hình tấn công vét cạn trên các tác vụ nguy hiểm đến độ an toàn của người dùng trên hệ thống mà vẫn đảm bảotính sẵn sàng trong dịch vụ Với yêu cầu này, máy chủ sẽ ghi nhận lại số lần thao tác thất bại của tài khoản trên các tác vụ nguy hiểm như đăng nhập, nhập mã xác thực OTP và khôi phục mật khẩu Khi số lần yêu cầu thất bại vượt quá 3 lần trong khoảng thời gian 10 phút, máy chủ sẽ tiến hành tạm khóa các yêu cầu đến từ tài khoản trên thiết bị ấy trong khoảng thời gian được tính theo công thức sau (theo đơn vị giây): l ock_d ur at i on=f i bonacci_sequence[f ai l ed_at t emp t s]∗10

• l ock_d ur at i onlà số giây tài khoản bị tạm khóa, tính từ lần thực hiện yêu cầu thất bại trước đó.

• f i bonacci_sequence[n]là giá trị của số thứ n trong dãy số fibonacci.

• f ai l ed_at t emp t s là số lần đăng nhập thất bại (có giá trị bằng 4 khi bắt đầu kích hoạt quá trình khóa) Số lần này sẽ được hủy bỏ sau một ngày tính từ thời điểm được mở khóa Nếu người dùng được mở khóa vào lúc 20:34 ngày 20/07/2021, cơ chế tạm khóa này sẽ được hủy bỏ vào lúc 20:34 ngày 21/07/2021.

Dựa vào công thức trên, với lần đăng nhập thất bại thứ 8, thời gian tạm khóa tài khoản sẽ là 130 giây Các dữ liệu ghi nhận quá trình thất bại này sẽ được lưu vào cache với 4 dữ liệu sau:

• ORIGIN: định danh cho thiết bị gửi yêu cầu.

• USER_ID: định danh cho người dùng.

• ATTEMPT_COUNT: số lần thất bại,

• LOCK_UNTILlà thời điểm tài khoản được mở khóa, được tính bằng thời điểm khi thực hiện yêu cầu thất bại cộng thêm với thời gian khóa l ock _d ur at i on.Như vậy, với mỗi quá trình thực hiện các thao tác nguy hiểm trên, việc kiểm tra tình trạng tạm khóa này sẽ được thực hiện trước khi bắt đầu xử lý các yêu cầu.

Case study

Lược đồ lưu trữ cho dữ liệu được ủy quyền quản lý bởi dịch vụ điều phối

Với các ràng buộc trên, lược đồ sau có thể được dùng để lưu trữ các dữ liệu được ủy quyền này:

Quá trình đăng ký bổ sung thông tin tài xế và phương tiện

Chức năng này sẽ được thực hiện người khi dùng đã tiến hành đăng nhập vào hệ thống với mục tiêu bổ sung thêm các thông tin còn thiếu để phù hợp với yêu cầu nghiệp vụ cụ thể Quá trình này được thực hiện với các bước sau, được minh họa qua hình5.15:

1 Ứng dụng gửi yêu cầu đăng ký với các thông tin bắt buộc (nhập bởi người dùng) và AT.

Hình 5.14: Lược đồ cơ sở dữ liệu lưu trữ thông tin người dùng với các thông tin được bổ sung

2 Máy chủ kiểm tra thông tin và lưu trữ:

• Máy chủ kiểm tra AT

• Máy chủ truy kiểm tra thông tin đầu vào: trong bước này, các thông tin được yêu cầu trong quá trình đăng ký sẽ được kiểm tra về mặt định dạng dữ liệu.

• Máy chủ truy vấn thông tin từ cơ sở dữ liệu và kiểm tra thông tin trùng lặp: các thông tin được sử dụng để đăng ký phải chưa được sử dụng bởi bất kỳ người dùng nào.

• Máy chủ lưu thông tin vào cơ sở dữ liệu.

3 Máy chủ trả về AT và RT mới tương ứng với quyền hạn tài xế.

1 Yêu cầu đăng ký với thông tin cần thiết + mã truy cập

3 AT và RT mới Ứng dụng

Hình 5.15: Quá trình đăng ký bổ sung thông tin tài xế và phương tiện

Quá trình ủy quyền người dùng thay cho dịch vụ điều phối

Trong quá trình đăng nhập, ứng dụng dịch vụ sẽ gửi yêu cầu đăng nhập bao gồm các thông tin đã yêu cầu của mô hình xác thực (đã nêu trong phần chức năng) và thêm một trường thông tin về quyền hạn mà ứng dụng đang yêu cầu Quá trình thực hiện đăng nhập được diễn ra tương tự như chức năng có sẵn của hệ thống đề xuất trong 5 bước đầu tiên, được thay đổi ở bước 6 như sau:

1 Ứng dụng gửi yêu cầu đăng nhập với tên đăng nhập, mật khẩu (nhập từ người dùng) và quyền hạn cần truy cập.

2 Máy chủ kiểm tra thông tin đăng nhập.

3 Máy chủ trả về mã định danh OTP cho ứng dụng và gửi mã xác thực OTP đến SMS người dùng.

4 Ứng dụng gửiOTP_CODE_SIGNATURE và mã OTP (nhập bởi người dùng).

5 Máy chủ kiểm traOTP_TOKEN và mã OTP.

6 Máy chủ kiểm tra quyền hạn mà ứng dụng yêu cầu truy cập:

• Đối với trường hợp ứng dụng đăng nhập dưới quyền khách hàng: máy chủ trả về AT và RT, kèm theo claimIS_BIKERvới giá trịfalse.

• Đối với trường hợp ứng dụng đăng nhập dưới quyền tài xế: máy chủ tiến hành truy xuất dữ liệu tài xế nhằm xác định chính xác quyền hạn được đăng nhập Nếu có tài xế được tìm thấy, máy chủ trả về AT và RT kèm theo claimIS_BIKERvới giá trịtrue Ngược lại,IS_BIKERsẽ được trả về với giá trịfalse.

5.6.4 G IỚI HẠN MỘT NGƯỜI DÙNG CHỈ ĐƯỢC ĐĂNG NHẬP TRÊN MỘT

THIẾT BỊ TẠI MỘT THỜI ĐIỂM

Yêu càu này sẽ được thực hiện dựa vào cơ chế thu hồi tất cả các token của người dùng (trước thời điểm cung cấp AT, RT cho lần đăng nhập mới này) Sử dụng lưồng thực thi như trên, bước 5’ sẽ được thêm vào nhằm đạt được tính chất này, thể hiện ở hình5.17.

6 Mã truy cập + làm mới dựa trên quyền hạn người dùng

Hình 5.16: Quá trình đăng nhập sử dụng mật khẩu và xác thực OTP (được sửa đổi)

6 Mã truy cập + làm mới dựa trên quyền hạn người dùng

5' Thu hồi tất cả token

Hình 5.17: Quá trình đăng nhập với ràng buộc chỉ được sử dụng một thiết bị

6 Đ ÁNH GIÁ VÀ CẢI TIẾN GIẢI PHÁP ĐỀ XUẤT

Đánh giá giải pháp đề xuất

Qua các mục tiêu đã đặt ra trong chương 5, mô hình thí điểm đã đảm bảo được các nguyên tắc an toàn trong bảo mật thông tin cũng như sử dụng các hướng tiếp cận hợp lý để khắc phục các rủi ro trong xác thực và bảo mật trên thiết bị di động Với các khía cạnh như sau:

• Tính bí mật dữ liệu:

– Sử dụng phương thức giao tiếp an toàn giữa ứng dụng và máy chủ (HTTPS). – Sử dụng hàm băm để lưu trữ mật khẩu người dùng.

• Tính toàn vẹn dữ liệu:

– Sử dụng định dạng JWT cho các mã truy cập và mã làm mới, đảm bảo các mã này không thể bị chỉnh sửa so với ban đầu thông qua xác thực chữ ký bên trong mã.

• Tính sẵn sàng dữ liệu:

– Với cách sử dụng giải pháp tạm khóa chỉ dành cho các thiết bị có hành vi đăng nhập thất bại nhiều lần, người dùng hợp lệ sẽ có thể truy cập vào dịch vụ họ cần mà không bị gián đoạn so với phương thức khóa hoàn toàn tài khoản - kẻ tấn công có thể khóa tài khoản người dùng liên tục ngay cả sau khi được mở khóa.

Ngoài ra việc kết hợp thêm OTP trong xác thực bên cạnh mật khẩu đã tăng cường khả năng xác thực người dùng của giải pháp bởi giảm thiểu đi những hạn chế mà yếu tố mật khẩu còn tồn tại như xem trộm, vét cạn, từ điển Bên cạnh đó, giải pháp cũng đã tăng cường khả năng bảo mật của phương thức đầu tiên (mật khẩu) hơn nữa thông qua việc ràng buộc các tiêu chuẩn về mật khẩu, làm giảm thiểu khả năng thành công của các phương pháp từ điển, vét cạn.

Các rủi ro và giải pháp cải tiến

Tuy nhiên, trong hệ thống này vẫn còn tồn tại một số mặt hạn chế cần được giải quyết như sau:

• Mã làm mới bị lộ:

Với cơ chế sử dụng mã truy cập ngắn hạn và mã làm mới dài hạn, hệ thống đã hạn chế được các tác động của việc mã truy cập bị đánh cắp Tuy nhiên, với trường hợp của mã làm mới, kẻ tấn công sẽ có thể sử dụng chúng cho đến khi hết hạn trong trường hợp bị lộ Vì vậy cơ chế xoay vòng mã làm mới sẽ được thêm vào để giải quyết tình trạng trên Mã làm mới sẽ được xoay vòng sau mỗi làm yêu cầu cấp lại mã truy cập, dẫn đến chúng chỉ có thể được sử dụng một lần duy nhất, được minh họa qua hình6.1 Với hướng tiếp cận này, việc tái sử dụng mã làm mới cũng sẽ được phát hiện, bảo vệ ứng dụng khỏi tấn công phát lại bằng việc sử dụng các mã bị xâm phạm [50].

• Chức năng khôi phục mật khẩu chỉ sử dụng một yếu tố xác thực:

Các rủi ro xảy ra trong các yếu tố xác thực là một điều không thể tránh khỏi trong quá trình xác thực người dùng Với việc sử dụng OTP đơn thuần trong khôi phục mật khẩu, người dùng sẻ đối mặt với nguy cơ tài khoản của họ có nguy cơ bị thỏa hiệp khi thiết bị bị thất lạc Để giải quyết tình trạng này, một yếu tố xác thực khác nên bổ sung vào quá trình này, đơn giản nhất là yếu tốdựa trên những gì họ biết Với yếu tố này, với yêu cầu nghiệp vụ cụ thể của từng dịch vụ, các câu hỏi liên quan đến lịch sử sử dụng của người có thể được tạo ra nhằm xác thực họ bên cạnh yếu tố dùng OTP Với case study về hệ thống hỗ trợ theo dõi và điều phối giao nhận hàng, lịch sử về địa điểm sử dụng dịch vụ sẽ được dùng để tạo câu hỏi bảo mật.

6.2.CÁC RỦI RO VÀ GIẢI PHÁP CẢI TIẾN 73

Yêu cầu đăng nhập {số điện thoại, mật khẩu, UUID}

Xác thực người dùng Tạo mã JWT với khóa bí mật

Trả về mã JWT (AT1 và RT1)

Yêu cầu dữ liệu với AT1 được gửi kèm

Trả về dữ liệu yêu cầu

6 Kiểm tra chữ ký JWT

Lấy dữ liệu được yêu cầu Ứng dụng Máy chủ xác thực

Yêu cầu làm mới AT với RT1 được gửi kèm

8 Kiểm tra chữ ký JWT Tạo mã JWT với khóa bí mật Trả về mã JWT (AT2 và RT2)

Hình 6.1: Quá trình xoay vòng mã làm mới

Hiện thực giải pháp cải tiến

Trong việc xoay vòng mã làm mới

Với việc cấp lại mã làm mới mới khi tiến hành yêu cầu cấp lại AT, các RT cũ cần được blacklist để tránh việc chúng bị sử dụng lại trong tương lai Nếu sử dụng phương pháp blacklist đã được đề cập trước đó: lưu tất cả các RT đã được vô hiệu vào cache, không gian lưu trữ sẽ cực kỳ tốn kém với cách hiện thực này Để giải quyết cho vấn đề trên, với tính chất cung cấp các token của hệ thống: các token được cung cấp chỉ được sử dụng trên một thiết bị duy nhất, việc blacklist sẽ được thực hiện dễ dàng hơn sử dụng hình thức tương tự như trong quá trình thu hồi tất cả token: sử dụng thời điểm cung cấp tối thiểu (token được cấp trước thời điểm này sẽ không có hiệu lực) Với cách tiếp cận này, các thông tin sau sẽ được lưu trữ trong cache:

• ORIGIN: định danh thiết bị người dùng

• USER_ID: định danh người dùng

• NOT_ISS_BEFORE: thời điểm cung cấp tối thiểu

Việc xác thực RT này được thực hiện tương tự quá trình thu hồi tất cả các token thuộc một người dùng (điểm khác biệt là sử dụng kèm theo ORIGIN để xác định thiết bị bên cạnh việc xác định người dùng) Ngoài ra, mã làm mới trong quá trình cấp lại này sẽ có thời gian hiệu lực bằng thời gian hiệu lực còn lại của mã trước đó(thay vì 30 ngày), đảm bảo tất cả các mã làm mới này sẽ có cùng thời điểm hết hạn,ngăn ngừa việc sử dụng phương thức này để duy trì đăng nhập vô thời hạn.

Ngăn chặn kịp thời việc sử dụng lại mã làm mới đã hết hạn

Với việc vô hiệu quá các mã làm mới như trên, tiêu chí này có thể được phát hiện dễ dàng thông qua việc kiểm tra thời điểm được cấp của mã làm mới so với thời điểm cấp lại gần nhất Khi phát hiện mã còn thời gian hiệu lực nhưng đã bị vô hiệu hóa về thời gian cấp (cấp trước thời điểm được lưu trữ), hệ thống sẽ phát hiện được việc sử dụng lại mã làm mới này Trong trường hợp phát hiện, yêu cầu sẽ bị từ chối và giá trịNOT_ISS_BEFOREdành cho thiết bị này sẽ được gán bằng thời điểm hiện tại, từ đó thực hiện được việc đăng xuất người dùng ra khỏi thiết bị, yêu cầu quá trình đăng nhập lại để tiếp tục sử dụng hệ thống.

6.3.HIỆN THỰC GIẢI PHÁP CẢI TIẾN 75

Khôi phục mật khẩu sử dụng lịch sử người dùng

Sử dụng case study ở chương trước, quá trình này sẽ được thực hiện với câu hỏi thử thách "Hãy liệt kê những địa điểm bạn đã từng đi trong vòng 1 tháng gần nhất". Quá trình khôi phục mật khẩu này sẽ diễn ra gồm 2 giai đoạn: xác thực OTP (giống như trong quá trình được đề xuất) và trả lời câu hỏi thử thách (giải pháp cải tiến), được biểu diễn qua hình6.2

1 Ứng dụng gửi yêu cầu khôi phục mật khẩu.

2 Máy chủ trả về mã định danh OTP cho ứng dụng và gửi mã xác thực OTP đến SMS người dùng: quá trình này được thực hiện tương tự như quá trình đăng nhập.

3 Ứng dụng gửi mà định danh OTP và mã xác thực OTP (nhập bởi người dùng).

4 Máy chủ kiểm tra các mã định danh và OTP: quá trình kiểm tra này được thực hiện tương tự như quá trình đăng nhập.

5 Máy chủ trả về mã định danh thử thách và danh sách các câu trả lời cho câu hỏi thử thách: quá trình này gồm các bước sau:

(a) Tạo danh sách câu trả lời: Bộ câu trả lời sẽ có số lượng là 5, trong đó sẽ có từ 1 đến 3 địa điểm đúng mà người dùng đã di chuyển, các câu trả lời còn thiếu sẽ được lựa chọn ngẫu nhiên từ các người dùng khác Trong trường hợp không có bất kỳ địa điểm nào trong vòng 1 tháng gần nhất, máy chủ sẽ tạo 5 địa điểm ngẫu nhiên và sẽ chấp nhận câu trả lời rỗng đến từ phía người dùng Các câu trả lời sẽ được trộn lại và đánh số từ 1 đến 5, sau đó số thứ tự của các câu trả lời đúng sẽ được lựa chọn và lưu trữ theo thứ tự từ nhỏ đến lớn Ví dụ với danh sách 5 địa điểm (đã được trộn), người dùng đã đi đến địa điểm thứ 2, 3 và 5 thì câu trả lời đúng được lưu trữ sẽ là 2,3,5.

(b) Tạo mã định danh thử thách: tương tự như việc tạo mã định danh OTP, quá trình này được thực hiện như phần mô tả phía trên, với sự thay thế mã OTP bằng danh sách câu trả lời dùng Như ví dụ ở trên, dãy số 235 sẽ được sử dụng thay thế cho mã OTP.

6 Ứng dụng hiển thị câu trả lời để người dùng lựa chọn.

7 Ứng dụng gửi câu trả lời người dùng (số thứ tự của câu trả lời) cùng với mã định danh thử thách.

8 Máy chủ kiểm tra mã định danh thử thách và câu trả lời: máy chủ sẽ tạo dãy số từ các số thứ tự của câu trả lời mà người dùng lựa chọn để phục vụ cho quá trình kiểm chứng kết quả Nếu người dùng lựa chọn câu trả lời thứ 1,5 và

3 thì dãy số được tạo sẽ là 135 (theo thứ tự từ nhỏ đến lớn) Tương tự như quá trình kiểm chứng mã định danh OTP, dãy số được tạo ra sẽ được sử dụng thay cho mã OTP trong quá trình này.

9 Máy chủ trả về mã khôi phục mật khẩu(RESET_TOKEN): quá trình tạo RE- SET_TOKEN được thực hiện và trả về từkhối quản lý việc tạo / xác thực các mã trong hệ thống, có thời gian hiệu lực trong 2 phút và chỉ được sử dụng một lần.

10 Ứng dụng gửi mật khẩu mới và mã khôi phục mật khẩu.

11 Máy chủ kiểm tra và cập nhật mật khẩu:

(a) RESET_TOKEN sẽ được kiểm tra tính hợp lệ qua việc truy vấn trong cache.

(b) Kiểm tra độ mạnh mật khẩu (theo các tiêu chuẩn như quá trình đăng ký).

(c) Xử lý mật khẩu (băm mật khẩu sử dụng bcrypt) và lưu vào cơ sở dữ liệu.

(d) Máy chủ đăng xuất tất cả thiết bị của người dùng (bao gồm thiết bị thực hiện yêu cầu).

6.3.HIỆN THỰC GIẢI PHÁP CẢI TIẾN 77

1 Yêu cầu khôi phục mật khẩu

5 Mã định danh thử thách và bộ câu trả lời làm mới

6 Hiển thị câu hỏi và câu trả lời Ứng dụng Máy chủ xác thực

7 Mã định danh thử thách và câu trả lời

9 Mã khôi phục mật khẩu

10 Mã khôi phục mật khẩu và mật khẩu mới

Hình 6.2: Quá trình khôi phục mật khẩu (đã được cải tiến)

T RIỂN KHAI , THỬ NGHIỆM VÀ ĐÁNH GIÁ

Triển khai

Mô hình đề xuất cùng với các giải pháp cải tiến sẽ được hiện thực sử dụng ngôn ngữ Java trên framework Spring Boot, với hệ cơ sở dữ liệu được sử dụng cho quá trình lưu trữ thông tin người dùng là PostgreSQL Ngoài ra, Redis sẽ được sử dụng làm cache để lưu trữ các thông tin quản lý liên quan đến quá trình đăng nhập của người dùng với cơ chế AOF (Append Only File) [51] nhằm đảm bảo dữ liệu có thể được lưu trữ an toàn khi có sự cố xảy ra Các công cụ, cấu hình cụ thể được sử dụng trong việc triển khai:

• Ngôn ngữ và framework: Spring Boot 2.2.0 cùng với Java 1.8.

• Nền tảng triển khai: Heroku với gói free, sử dụng 1 vCPU và 512 MB RAM.

• Hệ cơ sở dữ liệu: Heroku Postgres với gói Hobby Dev, giới hạn 10,000 records hoặc 1 GB dữ liệu.

• Cache: Redis Labs gói free với 30 MB dữ liệu.

Thử nghiệm và kiểm thử mô hình

Kiểm thử yêu cầu hệ thống

Trong phần đánh giá này, các chức năng cũng như yêu cầu ràng buộc đặt ra trong đề tài sẽ được kiểm thử nhằm đảm bảo tính đúng đắn trong quá trình thực hiện.

7.2.THỬ NGHIỆM VÀ KIỂM THỬ MÔ HÌNH 79

K IỂM THỬ CÁC CHỨC NĂNG TRONG HỆ THỐNG

Các chức năng đăng ký, đăng nhập, thay đổi mật khẩu, khôi phục mật khẩu, trong hệ thống sẽ được thực hiện kiểm thử thông qua hai phương thức khác nhau:

• Unit Test: thực hiện kiểm thử từng chức năng thông qua một bộ các test case được tạo ra sử dụng framework JUnit 5 Quá trình này đảm bảo các luồng thực thi được chạy qua ít nhất một lần (bao gồm các trường hợp sinh ra lỗi trong quá trình bảo mật và xác thực), nhằm phát hiện các sai sót, sự dư thừa trong việc hiện thực (có thể tạo ra các lỗ hổng bảo mật ngoài ý muốn).

• Integration Test / Load Test: trong phương thức này, mô hình xác thực sẽ được triển khai trên nền ràng Heroku nhằm đánh giá tính khách quan của việc kiểm thử Các kịch bản sẽ được tạo ra trên tinh thần mô phỏng các yêu cầu được gửi đến từ phía người dùng sử dụng ngôn ngữ Python Các kịch bản được tạo ra cho quá trình này, dựa trên các đặc tả API, bao gồm:

– Đăng ký người dùng và tài xế (với số lượng 50 người dùng và 50 tài xế). – Đăng nhập trên các tài khoản được tạo sử dụng mật khẩu.

– Đăng nhập sử dụng mã QR.

– Cấp lại mã truy cập.

– Kiểm tra mã truy cập.

– Đăng nhập sai mật khẩu nhiều lần (kiểm tra chức năng tạm khóa tài khoản).

Thời gian trung bình để thực hiện các yêu cầu trên được mô tả trong bảng7.1. Thời gian này không bao gồm độ trễ của đường truyền internet và chỉ thể hiện thời gian tính toán của máy chủ trong việc thực hiện các yêu cầu trên một cách tuần tự Đối với các chức năng cần gửi nhiều yêu cầu, thời gian mỗi bước sẽ được thể hiện độc lập Thời gian trên đã đáp ứng được tiêu chí được đặt ra trong quá trình kiểm thử này, với 1 giây cho các thao tác sử dụng hệ cơ sở dữ liệu và 0.1 giây cho các tác vụ khác, dựa trên cấu hình hiện tại mà giải pháp đang được triển khai.

S Ử DỤNG GIAO THỨC TLS 1.2 TRONG CÁC KẾT NỐI ĐẾN MÁY CHỦ Để kiểm tra ràng buộc này, công cụ openssl trên hệ điều hành Ubuntu sẽ được sử dụng để kiểm tra các phiên bản TLS được hỗ trợ với các câu lệnh sau:

Loại yêu cầu Thời gian trung bình của 20 lần chạy (ms) Đăng ký 613.5 ms Đăng ký bổ sung thông tin tài xế 421.1 ms Đăng nhập sử dụng mật khẩu

468.8 ms (kiểm tra mật khẩu) 8.3 ms (kiểm tra OTP) Đăng nhập sử dụng mã QR

23.3 ms (lấy mã định danh) 40.7 ms (xác thực cho mã định danh) 13.0 ms (kiểm tra tình trạng xác thực của mã định danh) Đổi mật khẩu 323.4 ms

80.9 ms (yêu cầu khôi phục) 407.4 ms (kiểm tra OTP và tạo câu hỏi thử thách) 18.3 ms (kiểm tra câu trả lời thử thách)

345.7 ms (đặt lại mật khẩu) Cấp lại mã truy cập 76.2 ms

Kiểm tra mã truy cập 9.4 ms

Bảng 7.1: Thời gian thực hiện các yêu cầu trên máy chủ được triển khai

(không bao gồm độ trễ đường truyền) openssl s_client -connect bike-auth.herokuapp.com:443 -tls1 openssl s_client -connect bike-auth.herokuapp.com:443 -tls1_1 openssl s_client -connect bike-auth.herokuapp.com:443 -tls1_2

Trong đó lần lượt sẽ kiểm tra các phiên bản 1.0, 1.1 và 1.2 Phiên bản 1.0 và 1.1 sẽ không được hỗ trợ và có kết quả trả về với lỗi sau:

140222723126592:error:141E70BF:SSL routines:tls_construct_client_hello :no protocols available: /ssl/statem/statem_clnt.c:1112:

Ở phiên bản được hỗ trợ 1.2, kết quả sẽ được trả về bao gồm các chuỗi chứng chỉ (certificate chain), chứng chỉ của máy chủ (server certificate), và thông tin về phiên kết nối:

Cipher : ECDHE-RSA-AES128-GCM-SHA256

Session-ID: 657B5FCFBC26A09552C7DBB3529B5702EC91328E8

Master-Key: 6EA86E23D6B48CAB96F671E17A815EE245BABC422

Ngoài ra, khi ứng dụng gửi yêu cầu nhầm đến máy chủ với giao thức không an toàn (HTTP), yêu cầu đó sẽ được chặn lại Thử nghiệm sử dụng Postman, khi gửi yêu cầu đăng nhập đến máy chủ sử dụng giao thức HTTP, mã 302 sẽ được trả về,chuyển hướng đến máy chủ sử dụng giao thức an toàn HTTPS.

Kiểm thử xâm nhập (Penetration Test)

Trong phần kiểm thử này, các công cụ StackHawk, HostedScan sẽ được sử dụng để tìm kiếm các lỗ hổng bảo mật của mô hình để xuất (đã triển khai trên Heroku).

S TACK H AWK ( SỬ DỤNG ZAP)

Hình 7.1: Kết quả sử dụng công cụ StackHawk

Các rủi ro sau đã được quét trong quá trình sử dụng công cụ này:

• Cloud Metadata Potentially Ex- posed

• Apache Range Header DoS (CVE- 2011-3192)

• Insecure HTTP Method • User Agent Fuzzer

Hình 7.2: Kết quả sử dụng công cụ HostedScan với ZAP

Tương tự như trên, kết quả kiểm thử xâm nhập với ZAP trên công cụ này không cho thấy bất kỳ lỗ hổng bảo mật nào. Đối với Nmap, vì hiển thị tất cả các cổng đang mở của hệ thống, có thể thấy rằng việc mở cổng 80 cho giao thức HTTP là không cần thiết (vì tất cả phải sử dụng HTTPS) Tuy nhiên, vì sử dụng nền tảng bên thứ 3 để triển khai, thông số này không thể bị thay đổi và giải pháp để giải quyết vấn đề này được thực hiện qua việc chuyển tiếp tất cả các kết nói sử dụng HTTP sang HTTPS (đã nêu trong mục5.1).

Sử dụng công cụ này với OpenVAS, các rủi ro về việc sử dụng giao thức TLS 1.0 và 1.1 có thể được tìm thấy trên hệ thống này Sự phát hiện này được tìm thấy bởi hai giao thức này chỉ bị vô hiệu hóa nhưng vẫn được hỗ trợ đến ngày 31/07/2021 [53], do đó quá trình kiểm tra thủ công ở trên không thể phát hiện Với việc sử dụng chứng chỉ xác thực của nền tảng triển khai, không có giải pháp khả thi nào có thể được thực hiện bên cạnh việc chờ các giao thức này bị ngưng hỗ trợ Ngoài ra, với lỗ hổng TCP timestamps, kẻ tấn công có thể tìm được thời gian mà hệ thống đã chạy thông qua đo độ trễ giữa các gói gửi đi Một lần nữa, không có giải pháp có thể được thực hiện bởi việc phụ thuộc vào nền tảng triển khai (không thể cấu hình ở hệ điều hành triển khai).

Hình 7.3: Kết quả sử dụng công cụ HostedScan với Nmap

Hình 7.4: Kết quả sử dụng công cụ HostedScan với OpenVAS

Đánh giá

Thông qua việc kiểm thử ở mức hệ thống và xâm nhập, mô hình kiểm thử này đã vượt qua được một số các lỗ hổng bảo mật đã được đề cấp đến trong chương 4 và mô hình OWASP Top 10 trong chương 2 Đồng thời phản ánh mức độ khả thi của giải pháp trong điều kiện thực tế thông qua việc đo đạc về hiệu năng của mô hình thử nghiệm.

Những hạn chế và hướng phát triển

tế nhằm đảm bảo giải pháp thỏa mãn được những tiêu chí đã đề ra Bên cạnh đó, việc kiểm tra và đo đạc hiệu suất của hệ thống cũng được thực hiện để xác định mức độ đáp ứng của giải pháp khi đưa vào ứng dụng.

8.2 N HỮNG HẠN CHẾ VÀ HƯỚNG PHÁT TRIỂN

Song song với những kết quả mà đề tài đã đạt được ở trên, vẫn còn tồn tại những mặt hạn chế mà đề tài cần được cải thiện, những hạn chế này bao gồm:

• Mô hình kiểm thử trong môi trường tích hợp còn hạn chế, mức độ triển khai thử nghiệm chỉ ở mức 1 VPS với cấu hình tối thiểu 1vCPU và 512 MB RAM.

• Mô hình triển khai thực tế chỉ được thực hiện ở mức độ nguyên mẫu(proto- type) với số lượng yêu cầu xác thực chưa nhiều nên việc đánh giá hiệu năng của hệ thống chưa triệt để.

• Chưa bao quát được toàn bộ những rủi ro về bảo mật có thể xảy ra trong thực tế mà những hệ thống nhạy cảm với dữ liệu người dùng đang gặp phải như các lĩnh vực liên quan đến ngân hàng, hệ thống thanh toán trung gian, hoặc những cơ quan của chính phủ.

Trong định hướng phát triển tiếp theo của đề tài, ngoài việc khắc phục những mặt hạn chế nêu trên, việc xây dựng những ràng buộc về nghiệp vụ tronghệ thống điều phối và giao nhận hàng cũng cần được bổ sung Từ đó hướng đến việc tổng quát hóa một mô hình xác thực người dùng được áp dụng chung cho những ứng dụng thực tiễn khác nhau Một số hạng mục có thể được xem xét mở rộng bao gồm:

• Kiểm tra độ chính xác của thông tin mà người dùng cung cấp so với thực tế(Know Your Customer - KYC) để nâng cao độ tin cậy so với phương pháp hiện nay.

• Kết hợp với thông tin dữ liệu người dùng nhiều chiều khác nhau thông qua việc thu thập thêm dữ liệu từ những cổng thông tin của chính phủ như:

– Bảo hiểm xã hội:https://baohiemxahoi.gov.vn/tracuu/Pages/tra-cuu-ho- gia-dinh.aspx

– Thông tin giấy phép lái xe:https://gplx.gov.vn/default.aspx

– Thông tin phương tiện:http://app.vr.org.vn/ptpublic/ để tự động hóa quá trình xác thực người dùng với độ tin cậy cao hơn.

[1] “Smartphone market share - os,” Dec 2020 [Online] Available: https: //www.idc.com/promo/smartphone-market-share/os

[2] P Technologies, “Vulnerabilities and threats in mobile applications, 2019,” Sep 2019 [Online] Available:https://www.ptsecurity.com/ww-en/analytics/ mobile-application-security-threats-and-vulnerabilities-2019/

[3] P b H Tankovska and A 27, “Global public wi-fi hotspots 2016-2022,” Aug 2020 [Online] Available: https://www.statista.com/statistics/677108/ global-public-wi-fi-hotspots/

[4] L Q Nguyễn and H M Trần, “Hệ thống hỗ trợ theo dõi và điều phối giao nhận hàng,” 2021.

[5] S Samonas and D Coss, “The cia strikes back: Redefining confidentiality, in- tegrity and availability in security.” Journal of Information System Security, vol 10, no 3, 2014.

[6] “Information security concepts: Authenticity,” Apr 2009 [Online] Available: https://www.brighthub.com/computing/smb-security/articles/31234/

[7] D M Turner, “Digital authentication - the basics,” Aug 2016. [Online] Available: https://www.cryptomathic.com/news-events/blog/ digital-authentication-the-basics

[8] “Most common passwords of 2020.” [Online] Available: https://nordpass. com/most-common-passwords-list/

[9] M F Rahman, F Sthevanie, and K N Ramadhani, “Face recognition in low lighting conditions using fisherface method and clahe techniques,” in2020 8th International Conference on Information and Communication Technology (ICoICT), 2020, pp 1–6.

[10] J Shelton, G Dozier, J Adams, and A Alford, “Permutation-based biometric authentication protocols for mitigating replay attacks,” in2012 IEEE Congress on Evolutionary Computation, 2012, pp 1–5.

[11] L Q Huan, D.-M Nguyen, H.-A Pham, and N Huynh-Tuong, “Authentica- tion in e-learning systems: Challenges and solutions,”Science & Technology Development Journal-Engineering and Technology, vol 3, no SI1, pp SI95–

[12] B Y Fraser, “Site Security Handbook,” RFC 2196, Sep 1997 [Online]. Available:https://rfc-editor.org/rfc/rfc2196.txt

[13] “Authentication vs authorization.” [Online] Available: https://www.okta. com/identity-101/authentication-vs-authorization/

[14] K Garska, “Two-factor authentication (2fa) explained: One time password soft tokens,” Jul 2018. [Online] Available: https://blog.identityautomation.com/ two-factor-authentication-2fa-explained-one-time-password-soft-tokens

[15] M View, D M’Raihi, F Hoornaert, D Naccache, M Bellare, and O Ranen,

“HOTP: An HMAC-Based One-Time Password Algorithm,” RFC 4226, Dec.

2005 [Online] Available:https://rfc-editor.org/rfc/rfc4226.txt

[16] M View, J Rydell, M Pei, and S Machani, “TOTP: Time-Based One- Time Password Algorithm,” RFC 6238, May 2011 [Online] Available: https://rfc-editor.org/rfc/rfc6238.txt

[17] T Roeder, 2010 [Online] Available: https://www.cs.cornell.edu/courses/ cs5430/2010sp/TL03.symmetric.html

[18] C Fontaine,Synchronous Stream Cipher Boston, MA: Springer US, 2011, pp.

1274–1275 [Online] Available:https://doi.org/10.1007/978-1-4419-5906-5_ 376

[19] N Li,Asymmetric Encryption Boston, MA: Springer US, 2009, pp 142–142. [Online] Available:https://doi.org/10.1007/978-0-387-39940-9_1485

[20] S Al-Kuwari, J H Davenport, and R J Bradford, “Cryptographic hash func- tions: Recent design trends and security notions,” Cryptology ePrint Archive, Report 2011/565, 2011,https://eprint.iacr.org/2011/565.

[21] B Lutkevich, V.-L Brunskill, and P Loshin, “What is a digital signature?” Feb

2021 [Online] Available: https://searchsecurity.techtarget.com/definition/ digital-signature

[22] Jun 2017 [Online] Available: https://www.signinghub.com/wp-content/ uploads/2017/05/Basics-of-Digital-Signatures-and-PKI-s.pdf

[23] D H Krawczyk, M Bellare, and R Canetti, “HMAC: Keyed-Hashing for Message Authentication,” RFC 2104, Feb 1997 [Online] Available: https://rfc-editor.org/rfc/rfc2104.txt

[24] R T Fielding, Architectural styles and the design of network-based software architectures University of California, Irvine, 2000.

[25] “Owasp top ten.” [Online] Available: https://owasp.org/ www-project-top-ten/

[26] “Table of contents,” 2017 [Online] Available: https://owasp.org/ www-project-top-ten/2017/

[27] I Jemal, O Cheikhrouhou, H Hamam, and A Mahfoudhi, “Sql injection attack detection and prevention techniques using machine learning,”Interna- tional Journal of Applied Engineering Research, pp 569–580, 01 2020.

[28] “Dom based xss.” [Online] Available: https://owasp.org/www-community/ attacks/DOM_Based_XSS

[29] “Owasp top 10.” [Online] Available:https://www.hacksplaining.com/owasp

[30] S Chandralekha, “Using components with known vulnerabilities: Owasp top 10: Siemba inc,” Aug 2020 [Online] Available:https://www.siemba.io/post/ owasp-top-10-using-components-with-known-vulnerabilities

[31] “A10:2017-insufficient logging & monitoring,” 2017 [Online] Avail- able: https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_ Logging&Monitoring

[32] P J Franks, P Hallam-Baker, L C Stewart, J L Hostetler, S Lawrence,

P J Leach, and A Luotonen, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, Jun 1999 [Online] Available: https: //rfc-editor.org/rfc/rfc2617.txt

[33] [Online] Available: https://swagger.io/docs/specification/authentication/ api-keys/

[34] E Hammer-Lahav, “The OAuth 1.0 Protocol,” RFC 5849, Apr 2010 [Online].Available:https://rfc-editor.org/rfc/rfc5849.txt

[35] “Oauth 1.” [Online] Available:https://oauth.net/1/

[36] D Hardt, “The OAuth 2.0 Authorization Framework,” RFC 6749, Oct 2012. [Online] Available:https://rfc-editor.org/rfc/rfc6749.txt

[37] M Argyriou, N Dragoni, and A Spognardi, “Security flows in oauth 2.0 framework: a case study,” inInternational Conference on Computer Safety, Reliabil- ity, and Security Springer, 2017, pp 396–406.

[38] Y AG, J Bradley, Yubico, A Labunets, Facebook, and D Fett, “Oauth 2.0 security best current practice - ietf tools,” Oct 2018 [Online] Available: https://tools.ietf.org/id/draft-ietf-oauth-security-topics-08.html

[39] “Single sign-on: What is it & how does it work?” [Online] Available: https://www.onelogin.com/learn/how-single-sign-on-works

[40] Auth0, “Authorization code flow.” [Online] Available: https://auth0.com/ docs/flows/authorization-code-flow

[41] [Online] Available: https://developers.google.com/identity/sign-in/web/ server-side-flow

[42] B Schneier, “Two-factor authentication: too little, too late,”Communications of the ACM, vol 48, no 4, p 136, 2005.

[43] K Adhatrao, A Gaykar, R Jha, and V Honrao, “A secure method for signing in using quick response codes with mobile authentication,” arXiv preprint arXiv:1310.4000, 2013.

[44] “Zap.” [Online] Available: https://www.zaproxy.org/docs/desktop/addons/ active-scan-rules/

[45] “Zap.” [Online] Available: https://www.zaproxy.org/docs/desktop/addons/ passive-scan-rules/

[46] “Burp suite - application security testing software.” [Online] Available: https://portswigger.net/burp

[47] R Severns, “Zap vs stackhawk: Dynamic application security testing tool comparison,” Mar 2021 [Online] Available: https://www.stackhawk.com/ blog/zap-vs-stackhawk-comparison/

[48] M Jones, J Bradley, and N Sakimura, “JSON Web Token (JWT),” RFC 7519,May 2015 [Online] Available:https://rfc-editor.org/rfc/rfc7519.txt

[49] D J C Klensin, “Application Techniques for Checking and Transformation of Names,” RFC 3696, Feb 2004 [Online] Available: https://rfc-editor.org/rfc/ rfc3696.txt

[50] Auth0, “Refresh token rotation.” [Online] Available:https://auth0.com/docs/ tokens/refresh-tokens/refresh-token-rotation#automatic-reuse-detection [51] “Redis persistence.” [Online] Available:https://redis.io/topics/persistence [52] HostedScan.com [Online] Available:https://hostedscan.com/

[53] “Tls v1.0/v1.1 end of life schedule.” [Online] Available:https://help.heroku.com/SXWA00YI/tls-v1-0-v1-1-end-of-life-schedule

T ÀI LIỆU API HỆ THỐNG

Máy chủ của hệ thống sẽ được đặt tạihttps://bike-auth.herokuapp.com/ Trong quá trình trả về kết quả từ các yêu cầu đến hệ thống, định dang sau sẽ được sử dụng, với nội dung data và mã lỗi sẽ được định nghĩa cụ thể cho từng chức năng.

Tên Mô tả error Mã lỗi message Mô tả lỗi data Trả về dữ liệu tương ứng khi thành công, hoặc null khi thất bại (hoặc bản ghi lỗi trong quá trình phát triển)

Đăng ký

Đăng ký tài khoản

• Content & Response Type: application/json

1001 Email đã được sử dụng

1002 Số điện thoại đã được sử dụng

5002 Các thông tin quan trọng bị thiếu hoặc sai định dạng

Đăng ký bổ sung thông tin tài xế, phương tiện

UID Mã định danh duy nhất của thiết bị

Đăng nhập

Đăng nhập sử dụng mật khẩu và OTP

3001 Sai tên đăng nhập hoặc mật khẩu

1005 Tài khoản bị tạm khóa

2002 Mã không được cung cấp bởi máy chủ

2006 Mã sử dụng không được cấp cho thiết bị này

Đăng nhập sử dụng QR

B ƯỚC 1 - Y ÊU CẦU LẤY MÃ QR

B ƯỚC 2 -X ÁC THỰC ĐĂNG NHẬP CHO MÃ QR

B ƯỚC 3 -K IỂM TRA ĐĂNG NHẬP CHO MÃ QR

• Endpoint path:/qr-authenticate-check

Khôi phục mật khẩu

Khôi phục sử dụng OTP và câu hỏi bảo mật

B ƯỚC 1 -Y ÊU CẦU KHÔI PHỤC MẬT KHẨU

B ƯỚC 2 -S Ử DỤNG OTP XÁC THỰC

B ƯỚC 3 -T RẢ LỜI CÂU HỎI BẢO MẬT

1006 Trả lời thử thách thất bại

B ƯỚC 4 -Đ ẶT MẬT KHẨU MỚI

Cập nhật thông tin

Thay đổi mật khẩu

Quản lý token

Cấp lại access token

Kiểm tra access token

Tiêu đề	Tìm hiểu về một số giải pháp bảo mật xác thực cho ứng dụng trên thiết bị di động
Tác giả	Nguyễn Thanh Bỡnh
Người hướng dẫn	ThS. Lưu Quang Huõn, ThS. Hồ Quang Chi Bảo
Trường học	Đại học Bách Khoa
Chuyên ngành	Khoa học máy tính
Thể loại	Luận văn tốt nghiệp Đại học
Năm xuất bản	2021
Thành phố	TP.HCM

Định dạng
Số trang	123
Dung lượng	2,38 MB