<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">

<b>ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜNG ĐẠI HỌC CÔNG NGHỆ</b>

<b>BÁO CÁO MÔN HỌC KIẾN TRÚC HƯỚNG DỊCH VỤ</b>

<i>Giảng viên hướng dẫn: Võ Đình HiếuNhóm sinh viên thực hiện</i>

Nguyễn Hữu Vượt Lê Huy Vũ Kiều Thế Vinh

<i>Hà Nội, năm 2022</i>

</div><span class="text_page_counter">Trang 2</span><div class="page_container" data-page="2">

<b>Phương pháp xác thực JSON Web Token (JWT)</b>

<b>Các khía cạnh cần bảo vệ với API</b>

<b>Demo một số phương pháp bảo vệ API</b>

</div><span class="text_page_counter">Trang 3</span><div class="page_container" data-page="3">

<b>Mở đầu</b>

Hiện nay, giao diện lập trình ứng dụng APIs (Application Programming Interfaces) đang dần trở nên phổ biến trong việc xây dựng các ứng dụng. Ta có thể dễ dàng bắt gặp ứng dụng của API trên bất cứ phần mềm hay thiết bị nào, ví dụ như các trang web, các phần mềm trên điện thoại thơng minh, hoặc các thiết bị IOT có kết nối Internet đều có thể sử dụng API. Công nghệ API được ứng dụng ngày càng nhiều, ngày càng phức tạp, chính vì thế đã phát sinh ra nhiều vấn đề, lỗ hổng bảo mật ảnh hưởng tới sự an toàn của ứng dụng. Trong tài liệu này, ta cùng thảo luận về API Security là gì và một số phương pháp đảm bảo an toàn cho các ứng dụng API. Các phần của tài liệu này bao gồm:

Phương pháp xác thực bằng session và cookie Phương pháp xác thực sử dụng OAuth2.0

Phương pháp xác thực sử dụng JSON Web Token (JWT) Phương pháp xác thực bằng Phương pháp xác thực bằng OpenID Các cơ chế cần bảo vệ với API

<b>Phương pháp xác thực bằng session và cookie </b>

Xác thực dựa trên token là phương thức phổ biến thường được sử dụng để bảo mật API với nhiều kỹ thuật và các cách tiếp cận khác nhau. Mỗi cách tiếp cận sẽ phù hợp cho từng tình huống. Dưới đây phương pháp cơ bản để xác thực API: xác thực bằng session

● Cơ chế:

○ Khi người dùng đăng nhập ứng dụng bằng tên người dùng và mật khẩu của ọ, API sẽ tạo ra một chuỗi ngẫu nhiên (token) và gửi về cho client ○ Sau đó server sẽ tạo một session có thể được xác thực bằng token trên, khi

người dùng gửi request lên server sẽ kèm theo token trong trường header ⇒

</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">

Hình 2.1: Mô tả cấu trúc xác thực API bằng token ● Giải thích chi tiết:

○ Sau khi Server xác thực người dùng bằng username, password của họ, sẽ trả về cho người dùng một response trong đó bao gồm trường

trong phần header, nội dung của trường này là chuỗi token do Server sinh ra, chuỗi này được Server lưu trữ trong

■ Token này sẽ hết hạn khi tồn tại quá thời gian quy định hoặc khi người dùng đăng xuất kết thúc phiên làm việc

○ Khi nhận được response trả về, trình duyệt web sẽ lưu trữ token đó trong ○ Các request từ client lên server sau này sẽ bao gồm trường

phần header để có thể xác thực phiên làm việc

</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">

Hình 2.2: Chi tiết phương pháp xác thực API bằng token ● Nhược điểm của phương pháp này:

○ Với cơ chế hoạt động như trên, phương pháp này vẫn tồn tại một lỗ hổng có thể bị khai thác và tấn công. Phương pháp khai thác này gọi là “a session fixation attack”

○ Theo luồng hoạt động bình thường:

■ Khi client gửi request khơng bao gồm trường

server sẽ tự động tạo ra một phiên làm việc hoàn toàn mới ■ Khi client gửi request có chứa trường , server sẽ trả về phiên

làm việc hiện tại của người dùng

■ Lợi dụng việc này, Attacker sẽ thay đổi Cookie của người dùng được lưu trên máy của họ bằng Cookie đang được lưu trên máy của Attacker thông qua việc gửi cho người dùng một đường link độc hại chứ câu lệnh đặt lại cookie ⇒ ườ ử đă ậ

ườ

</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">

Hình 2.3: Mơ hình tấn cơng lỗ hổng đánh cắp Cookie

<b>Phương pháp xác thực bằng OAuth 2.0</b>

● Định nghĩa: OAuth là một phương thức xác thực giúp một ứng dụng bên thứ 3 có thể được ủy quyền bởi người dùng để truy cập đến tài nguyên người dùng nằm trên một dịch vụ khác.

○ Resource owner: là những người dùng có khả năng cấp quyền truy cập, chủ sở hữu của tài nguyên mà ứng dụng muốn lấy.

○ Resource server: nơi lưu trữ các tài nguyên, có khả năng xử lý yêu cầu truy cập đến các tài nguyên được bảo vệ.

○ Client: là những ứng dụng bên thứ 3 muốn truy cập vào phần tài nguyên được chia sẻ với tư cách của người sở hữu (resource owner) và tất nhiên trước khi truy cập ứng dụng cần được sự ủy quyền của user.

○ Authorization server: làm nhiệm vụ xác thực, kiểm tra thông tin mà user gửi đến từ đó cấp quyền truy cập cho ứng dụng bằng việc sinh ra các đoạn mã access token. Đơi khi authorization server cũng chính là resource server. ●

○ Dùng xác thực quyền truy cập, cho phép ứng dụng bên thứ 3 có thể truy cập trong phạm vi mà nó cho phép ○ Có thời gian sử dụng nhất định, khi hết hiệu lực phải gửi lại yêu cầu

đến để lấy access token mới

</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">

○ Được gửi đi để lấy về một access token mới khi hết hạn mà không cần xác thực lại từ phía người dùng

○ Bị xố khi người dùng đăng xuất

● là một tham số được định nghĩa trong

để giới hạn quyền, phạm vi tài nguyên mà access token được phép truy cập. Client sẽ xác định sử dụng scope nào khi yêu cầu sinh ra một đoạn access token

● Authorization Code: là loại phổ biến nhất

○ Người dùng click vào nút đăng nhập trên ứng dụng web.

○ Ứng dụng web chuyển hướng người dùng đến Authorization server để bắt đầu quá trình nhận authorization code.

○ Người dùng được chuyển đến trang đăng nhập.

○ Người dùng nhập thông tin đăng nhập để xác thực ví dụ như nhập username ○ r sẽ xác thực thông tin đăng nhập và chuyển hướng

người dùng đến "redirect uri" của ứng dụng (nơi ứng dụng bắt thông tin trả về từ Authorization server) kèm theo một đoạn "authorization code". ○ Ứng dụng (Client) gửi request đến Authorization server gồm Clie

Client secret (đã khai báo với Authorization server trước đó) cùng với đoạn mã authorization code vừa nhận.

○ Authorization server sẽ xác minh thông tin mà Client vừa gửi. ○ Nếu thông tin mà Client gửi lên là hợp lệ, Authorization sẽ trả về access

token cùng với refresh token (nếu có).

○ Ứng dụng gửi request tới Resource server kèm theo Access token vừa nhận được.

○ Resource server kiểm tra access token, nếu hợp lệ thì trả về cho nguyên tương ứng mà access token cho phép truy cập.

</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">

<i>Mô tả luồng hoạt động của </i>

○ Người dùng nhập thơng tin đăng nhập (ví dụ: username, password...) vào form trên chính ứng dụng đang dùng

○ Ứng dụng(Client) gửi thông tin đăng nhập cùng Client ID, Client secret lên ○ Authorization server kiểm tra thông tin đăng nhập của người dùng cũng

như định danh mà Client gửi lên, nếu tất cả là hợp lệ thì sẽ trả về access n cùng với refresh token (nếu có).

○ Ứng dụng sử dụng access token vừa nhận được để truy cập đến Resource

</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">

<i>Mô tả luồng hoạt động của </i>

● Implicit: access token được gửi thẳng đến ứng dụng thơng qua URI trên trình ệt (browser). Không hỗ trợ refresh token

○ Người dùng click vào đăng nhập bên phía ứng dụng web

○ Người dùng được chuyển hướng bởi trình duyệt tới Authorization server. ○ Nếu người dùng cho phép truy cập, Authorization server chuyển hướng về

lại ứng dụng với một đoạn access token được gửi trong đoạn URI. ○ Bây giờ ứng dụng (Client) có thể truy vấn tới Resource server thơng qua

access token vừa lấy được.

<i>Mô tả luồng hoạt động của </i>

</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">

● Client Credentials: giúp Client xác thực chính nó với Authorization server để truy cập vào chính những tài ngun mà nó hiện đang nắm giữ.

○ Client gửi Client ID và Client secret của chính mình đến Authorization ○ Authorization server xác thực thơng tin được gửi đến, nếu xác nhận đó là

Client thì gửi lại access token.

○ Client dùng access token đó truy cập đến Resource server để lấy tài ngu

<i>Mơ tả luồng hoạt động của </i>

<b>Phương thức xác thực bằng OpenID</b>

● Định nghĩa: OpenID là một giao thức định danh giúp người dùng có thể đăng nhập vào các websites khác nhau mà không cần tạo tài khoản hay mật khẩu mới. ● Điểm mạnh của OpenI

○ Độ bảo mật cao do khơng có website nào biết được password, chỉ identity provider quản lý password

○ Đăng ký / đăng nhập nhanh chóng và dễ dàng ○ Giúp người dùng tiệm cận với “web identity” ●

○ Identifier: Một String xác định duy nhất cho người sử dụng.

</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">

○ Relying Party (RP): Một nguồn tài nguyên trực tuyến (có thể là một trang web, một tập tin, hình ảnh, hoặc bất cứ điều gì bạn muốn kiểm sốt quyền truy cập vào) có sử dụng OpenID để xác định những người có thể truy cập ○ OpenID Provider (OP): Một trang web mà người sử dụng có thể yêu cầu

một OpenID và sau đó đăng nhập và xác thực danh tính của sử dụng RP. ● Phương thức hoạt động:

○ Người dùng xuất trình OpenID của mình trong một form. ○ OpenID được mã hố với vị trí của provider

○ Relying party lấy định danh của người dùng và chuyển hướng người dùng tới provider.

○ Người dùng chứng minh yêu cầu của mình sử dụng ID đó.

● Identifier: là một chuỗi duy nhất định danh một người nào đó, có thẻ được RP giải mã để xác thực người dùng

○ Supplied Identifier: là định danh được user cung cấp tới RP. ○ Claimed Identifier: là định danh được chuẩn hoá từ User

● Provider: chịu trách nhiệm phát hành Identifiers và thực hiện xác thực user.

<b>Phương pháp xác thực JSON Web Token (JWT)</b>

● JWT là một tiêu chuẩn xác định cách để truyền thơng tin an tồn giữa máy chủ và máy khách dưới dạng đối tượng JSON.

● JWT có thể được gửi qua URL, thơng qua tham số POST hoặc bên trong header của HTTP.

● JWT chứa tất cả thông tin cần thiết về người dùng để tránh truy vấn cơ sở dữ liệu nhiều lần

● Lợi ích của việc sử dụng JWT để xác thực

○ Json sẽ nhỏ gọn ít dài dịng hơn XML ⇒ ợ để ử hận thông qua ○ Sử dụng JWT an tồn hơn: JWT có thể sử dụng cặp khóa cơng khai / khóa

riêng tư để ký, ngồi ra cũng có thể được ký đối xứng bằng cách sử dụng thuật tốn mã hóa HMAC

○ Phổ biến hơn: hầu hết các ngơn ngữ đều tích hợp cú pháp để phân

</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">

● Cấu trúc của một JSON Web Token gồm 3 chuỗi được mã hóa base64 nối liền nhau, phân tách bằng dấu .:

○ JOSE Header: chứa thông tin về loại token, các thuật tốn mã hóa đc sử dụng

○ JWS payload: chứa thơng tin bảo mật để xác minh, ví dụ như danh tính của người dùng, quyền truy cập của người dùng

○ JWS signature: sử dụng để xác thực rằng mã thông báo là đáng tin cậy, không bị giả mạo. Khi sử dụng JWT, phải kiểm tra JWS signature trước khi lưu trữ và sử dụng

<i>Hình 3.1: Cấu trúc của JWT token</i>

● JOSE header: chứa thông tin tham số về thuật tốn mã hóa được sử dụng

</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13">

● JWS payload: có chứa các claims

○ Claims là là các biểu thứ về một thực thể và một số metadata phụ trợ

● JWS signature: dùng để xác minh người gửi mã JWT, chữ ký được tạo bằng cách mã hóa header đã được mã hóa bằng base64 và payload bằng thuật tốn ghi trong

ể để ể toàn vẹn của dữ liệu khi truyền tải

● Cách xác thực JSON Web Token

○ Token được ký bởi một trong số các thuật toán ký khác nhau: RS256, ○ Khi thực hiện xác thực JWT, cả chuỗi băm ban đầu và chuỗi băm hiện tại

đều cần được giải mã ⇒ hai kết quả giải mã ⇒ ự ○ Để phân tích cú pháp và xác thực các chuỗi hash cần những tính tốn phức

tạp, do đó, ta thường sử dụng các thư viện của bên thứ ba, middleware của framework hoặc các SDKs có sẵn để giải mã và tiến hành so sánh. ○ Một trong những thư viện của bên thứ ba phổ biến nhất là ● Cách hoạt động của JSON Web Token

</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14">

○ Cách thức hoạt động của JWT tương tự như cookie và token truyền thống, tuy nhiên có một số điểm khác biệt

○ Client sẽ gửi JWT token trong header với cú pháp

○ JWT hoạt động theo cách phi trạng thái server sẽ không tạo session để lưu thông tin làm việc của user, mọi thông tin trạng thái làm việc đều được đóng gói vào trong JWT (trường header và payload) ⇒ được lỗi với CORS và lỗ hổng đánh cắp session như trên

<i>Hình 3.2: Luồng hoạt động của xác thực JWT</i>

<b>Các khía cạnh cần bảo vệ với API</b>

OWASP (Open Web Application Security Project) là một tổ chức phi lợi nhuận hoạt động với tiêu chỉ cải thiện, nâng cao tính bảo mật của các phần mềm. Sau đây là 10 vấn đề của API security thường gặp do OWASP thống kê năm 2019

</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15">

Đây là vấn đề cơ bản về phân quyền mà hầu hết mọi người gặp phải.

VD: API của chúng ta có dạng và có người tiến hành thử nghiệm bằng cách thay thế từng một. Nếu những API không kiểm tra quyền truy cập dữ liệu, tồn bộ thơng tin user của các công ty sẽ bị lộ.

Vấn đề bảo mật ở đây ngồi sự thiếu sót trong kiểm tra quyền hạn mỗi khi client request thì vấn đề nổi bật chính là sử dụng dễ đốn. Việc dùng

mang tính tuyến tính đã mang lại rủi ro rất lớn và nếu như Authorization khơng tốt, tồn bộ thơng tin có thể bị lấy một cách dễ dàng.

Cách ngăn chặn:

● Thực hiện cơ chế phân quyền phù hợp dựa trên chính sách người dùng và hệ thống phân cấp

VD: user A chỉ có thể xem được thơng tin user A, không thể xem thông tin user B. Chỉ có admin có thể xem danh sách tồn bộ user

● Sử dụng cơ chế phân quyền để kiểm tra xem người dùng đã đăng nhập có quyền thực hiện yêu cầu từ client để truy cập vào database hay không

● Sử dụng random ID (UUID) thay vì các ID tăng dần

● Kiểm tra lại cẩn thận các cơ chế phân quyền. Không triển khai thay đổi dễ phá vỡ các bài kiểm tra

Điểm cuối và luồng xác thực cần được bảo vệ. “Quên mật khẩu / đặt lại mật khẩu” phải được xử lý giống như cơ chế xác thực.

</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16">

VD: với API yêu cầu cung cấp lại mật khẩu và bắt nhập SMS token, hacker tạo và gửi hàng loạt request với các SMS token khác nhau (thường là 6 số, tầm 1 triệu request) thì sẽ có một cái thành cơng nếu như cơ chế xác thực chỉ đơn giản là check SMS token

Một API dễ bị tấn công nếu: ● Do cơ chế xác thực đơn giản

● Thiếu sót các thành phần validation trong access token (ví dụ như verify signature ● Sử dụng mật khẩu yếu hoặc cơ chế mã hóa cũ

● Sử dụng token vĩnh viễn, không hết hạn Cách ngăn chặn:

● Áp dụng các phương thức authen hiệu quả ● Thêm các xác thực khác như xác thực app ● Sử dụng token có thời gian ngắn hạn

● Đối với mật khẩu và các cơ chế bảo mật, cần áp dụng các cơ chế mã hóa hiệu quả

API trả về dữ liệu nhạy cảm cho client theo thiết kế. Dữ liệu này được lọc ở phía client trước khi trả cho người dùng. Kẻ tấn công có thể dễ dàng theo dõi lưu lượng truy cập và xem các dữ liệu nhạy cảm. Việc trả về full data khơng chỉ tốn rất nhiều chi phí giảm performance mà có cịn là về vấn đề bảo mật. Sẽ có những data mà client khơng được phép truy cập và việc trả về full data là quá mức cần thiết.

độ xem bài viết để hiển thị các nhận xét. Kẻ tấn công phát hiện ra những dữ liệu nhạy cảm khác liên quan đến tác giả của nhận xét cũng được trả ra.

Cách ngăn chặn:

● Không sử dụng client để lọc dữ liệu

</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">

● Xem lại các phản hồi từ API để kiểm tra dữ liệu trả ra là hợp lệ

● Phải có sự thống nhất rõ ràng từ cả 2 phía backend và front trong việc thiết kế và xây dựng API để xác định rõ data cần thiết cho mỗi API response

● Tránh sử dụng các phương thức chung như to_json(), to_string()

● Thêm xử lý kiểm tra cần thiết đối với các data response, ngăn chặn nếu như dữ liệu đó nằm trong blacklist

Các yêu cầu API sử dụng các tài nguyên như mạng, bộ nhớ, lưu trữ. Số lượng tài nguyên cần thiết để đáp ứng một yêu cầu phụ thuộc rất nhiều vào đầu vào của người dùng là logic nghiệp vụ của điểm cuối.Ngoài ra, hãy xem xét thực tế là các yêu cầu từ nhiều ứng dụng khách API cạnh tranh để giành tài nguyên. API dễ bị tấn công nếu thiếu ít nhất một trong các giới hạn sau hoặc được đặt khơng phù hợp (ví dụ: q thấp / cao):

● Hết thời gian thực thi ● Bộ nhớ phân bổ tối đa ● Số lượng tệp mô tả ● Số lượng tiến trình ● Kích thước tệp request ● Số lượng request / khách hàng

● Số lượng bản ghi trên mỗi trang trong một yêu cầu

VD: Kẻ tấn cơng tải lên một hình ảnh lớn bằng cách đưa ra yêu cầu POST tới / api / v1 / images. Khi q trình tải lên hồn tất, API sẽ tạo nhiều hình thu nhỏ với các kích thước khác nhau. Do kích thước của hình ảnh được tải lên, bộ nhớ khả dụng sẽ cạn kiệt trong q trình tạo hình thu nhỏ và API khơng phản hồi

Cách ngăn chặn:

● Sử dụng docker để giới hạn bộ nhớ, CPU, …

● Giới hạn tần suất gọi API trong một khoảng thời gian nhất định ● Thông báo khi vượt quá giới hạn và thời gian đặt lại giới hạn ● Kiểm soát số lượng bản ghi được trả về

● Xác định và thực thi kích thước tối đa của dữ liệu

Tương tự như mục 1, nhưng thay vì đốn ID thì ở đây kẻ tấn cơng sẽ đoán function. Câu hỏi được đặt ra là:

● Người dùng thơng thường có thể truy cập các điểm cuối quản trị hay khơng? ● Người dùng có thể thực hiện các hành động nhạy cảm (VD: tạo, sửa, xóa,...) bằng

cách thay đổi phương thức từ GET thành DELETE hay không?

</div>