Báo Cáo Môn Học Kiến Trúc Hướng Dịch Vụ.pdf

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

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

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

Giảng viên hướng dẫn: Võ Đình Hiếu

Nhóm sinh viên thực hiện

Nguyễn Hữu Vượt

Lê Huy Vũ

Kiều Thế Vinh

Hà Nội, năm 2022

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

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

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

Mở đầu

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

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

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 ⇒

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

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 ⇒ ườ ử đă ậ

ườ

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

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

● Đị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

○ Đượ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ị xoá 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

Mô tả luồng hoạt động của

●

○ 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

Mô tả luồng hoạt động của

● 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

Mô tả luồng hoạt động của

● 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 nguyên 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

Mô tả luồng hoạt động của

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

● Đị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

○ 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 soá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ã hoá 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

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

● JWT là một tiêu chuẩn xác định cách để truyền thông tin an toà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 toàn hơn: JWT có thể sử dụng cặp khóa công khai / khóa riêng tư để ký, ngoài ra cũng có thể được ký đối xứng bằng cách sử dụng thuật toá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

● 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 toá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

Hình 3.1: Cấu trúc của JWT token

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

● 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 toá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 toá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

○ 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

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

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

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

Đâ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, toàn bộ thông tin user của các công ty sẽ bị lộ

Vấn đề bảo mật ở đây ngoà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ễ đoá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, toàn

bộ thông tin có thể bị lấy một cách dễ dà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

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

● 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ụ: quá 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 quá trình tải lên hoà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 quá 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ì đoá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?