AN TOÀN ỨNG DỤNG WEB VÀ CSDL đề TÀI BROKEN ACCESS CONTROL

HỌC VIỆN CƠNG NGHỆ BƯU CHÍNH VIỄN THƠNG
KHOA CƠNG NGHỆ THƠNG TIN I
-----□□&□□-----

BÁO CÁO BÀI TẬP LỚN
MƠN: AN TỒN ỨNG DỤNG WEB VÀ CSDL
ĐỀ TÀI: BROKEN ACCESS CONTROL
Nhóm lớp: 01.
GIẢNG VIÊN:

Nguyễn Quốc Dũng

NHÓM THỰC HIỆN:

NHÓM 8

Nguyễn Bá Đạt

B18DCAT049

Vũ Lâm Thạch

B18DCAT097

Dương Văn Chung

B18DCAT029

Đặng Quốc Việt

B18DCAT261

Hán Nam Long

B18DCAT138

1


I. MỤC LỤC
II.Cấu trúc của Broken Access Control....................3
1. Khái niệm Broken Access Control.....................3
2. Điểm yếu về bảo mật..........................................3
3. Các yếu tố tác động.............................................3
4. Các lỗ hổng đã xảy ra .........................................3
III. Các cách thức tấn công Broken Access Control. 4
1. Bỏ qua kiểm tra kiểm soát quyền truy cập bằng
cách sửa đổi URL....................................................4
2. Khai thác từ APIs của web chưa được phân
quyền.......................................................................6
3. Nâng cao đặc quyền..........................................10
4. Cấu hình sai CORS cho phép truy cập API trái
phép.......................................................................11
5. Tấn công mã thông báo web JSON (JWT).......12

2


II.

Cấu trúc của Broken Access Control

1.
Khái niệm Broken Access Control
- Kiểm sốt truy cập nhằm mục đích kiểm sốt người dùng được ủy quyền được
phép hay khơng được phép làm gì trong một ứng dụng và để thiết lập quyền kiểm
soát truy cập một cách hợp lí, ứng dụng phải đảm bảo rằng nó đang nghiêm túc
thực hiện kiểm tra ủy quyền và xác thực hợp lệ để xác định người dùng được đặc
quyền, Đơn giản hóa đi đó là những lỗ hổng cho phép kẻ tấn công bỏ qua ủy
quyền (authorization) và thực hiện các tác vụ như thể là người dùng có đặc quyền,
chẳng hạn như quản trị viên (admin)

-

Các lỗi phân quyền thường do thiếu đi các bộ phát hiện lỗi tự động hoặc cách
thức kiểm thử hoặc các hàm kiểm thử chưa hiệu quả khiến cho hệ thống bị rò rỉ

2.
-

Điểm yếu về bảo mật
Các điểm yếu của kiểm soát truy cập xảy ra phổ biến do thiếu khả năng tự động
phát hiện lỗi và khả năng kiểm tra chức năng hiệu quả bởi các nhà phát triển ứng
dụng.

-

Tính năng phát hiện kiểm sốt truy cập thường khơng thích hợp với kiểm tra động
hoặc tĩnh tự động. Kiểm tra thủ công là cách tốt nhất để phát hiện Broken Access
Control, bao gồm phương pháp HTTP (GET vs PUT, v.v.), bộ điều khiển, tham
chiếu đối tượng trực tiếp, v.v.

3.
-

Các yếu tố tác động
Tác động kĩ thuật là những kẻ tấn cơng đóng vai trị là người dùng hoặc quản trị
viên, hoặc người dùng sử dụng các chức năng đặc quyền, hoặc tạo, truy cập, cập
nhật hoặc xóa mọi bản ghi.

4.

Tác động kinh doanh phụ thuộc vào nhu cầu bảo vệ của ứng dụng và dữ liệu.
Các lỗ hổng đã xảy ra .
Yahoo! Mục Tiêu ưa thích của tin tặc trên mạng internet
Năm 2014, Yahoo tiết lộ họ đã phải chịu cuộc tấn công Internet ảnh hưởng
đến 500 triệu tài khoản và không cần phải bàn cãi nhiều bởi khơng chỉ bị Hack mà
các tài khoản này cịn bị sử dụng để tiếp tục lừa các người thân của chính chủ.
3


Các thông tin như tên, ngày sinh, điện thoại bị đánh cắp đã gây nên cơn sốt ở thời
điểm đó. Bất chấp cho việc Yahoo! Khẳng định việc lộ thông tin này sẽ không
ảnh hưởng đến tài khoản ngân hàng nhưng người dùng của Yahoo! Đã giảm lao
dốc.
Trước đó năm 2012, nhóm Hacker “Peace” đã rao bán 200 triệu thơng tin người
dùng kèm theo mật khẩu với giá là 1900 USD trên internet. Điều tồi tệ nhất đã
xảy ra với Yahoo khi lần nữa họ lại bị tấn công khiến 32 triệu tài khoản bị ảnh
hưởng, những kẻ tấn công đã sử dụng phương thức cũ như trước đó, Hacker đã
tạo ra các cookie độc hại trên internet và đăng nhập mà không cần mật khẩu
Yahoo.
Cái kết đáng buồn khi Yahoo! Từ một công ty được định giá tỷ đô đã phải bán

mình với giá 4,5 triệu đơ vào năm 2017 cho Verizon. Tháng 12 năm 2018, Yahoo
tiếp tục thừa nhận trong quá khứ họ đã để mất tất cả 3 tỷ tài khoản vào tay các
Hacker. Đây có thể coi như cuộc tấn công lớn nhất trong lịch sử internet.
Microsoft xuất hiện lỗ hổng bảo mật HiveNightmare vừa mới được khám phá ra
bởi các chuyên gia bảo mật.
Hai chuyên gia với tài khoản Twitter là Jonas L và @GosiTheDog đã phát
hiện ra rằng Windows 10 và Windows 11 có lỗ hổng bảo mật cho phép tài khoản
cấp thấp truy cập file chứa dữ liệu quan trọng. Dựa vào đó, hacker có thể thực
hiện kiểu tấn công leo thang đặc quyền (LPE) để chiếm quyền kiểm sốt tồn bộ
máy tính.
Cụ thể, ngay cả tài khoản không phải quản trị viên trên máy tính Windows 10,
Windows 11 cũng có thể truy cập vào Trình quản lý tài khoản bảo mật Windows
(SAM). Những tệp registry quan trọng khác như SYSTEM và SECURITY cũng
có thể bị truy cập nếu hacker khai thác thành công lỗ hổng này.

III.

Các cách thức tấn công Broken Access Control
1.
Bỏ qua kiểm tra kiểm soát quyền truy cập bằng cách sửa đổi URL.
Các lỗ hổng phổ biến
ID khơng an tồn :
Thơng thường, ID này được sử dụng trong URL để xác định dữ liệu mà
người dùng muốn nhận. Giả sử tôi đã đăng nhập vào một trang web và ID người
dùng của tôi là 1337. Khi tôi vào trang hồ sơ của riêng mình, URL trơng như thế
này:
4


/>Nhưng nếu tôi thay thế ID bằng ID của người dùng khác thì sao?

/>Nếu webserver được cấu hình khơng đúng, thì nếu tơi truy cập một trang khác, ví
dụ , thì tơi sẽ nhận được trang hồ sơ của người dùng khác, với tất cả dữ liệu nhạy
cảm của họ.
Forced browsing
là khi người dùng cố gắng truy cập các tài ngun khơng được ứng dụng
tham chiếu, nhưng vẫn có sẵn
 Ví dụ: một ứng dụng web có thể có trang quản trị, nhưng khơng có liên kết đến
trang quản trị trên các phần khác của trang web, người dùng thông thường sẽ
khơng tìm thấy trang quản trị bằng cách nhấp vào xung quanh. Nhưng nếu ai đó
trực tiếp chỉnh sửa URL, ví dụ: truy cập , họ có thể truy cập trang quản trị 
/>Thư mục :
Khi một trang web lưu trữ dữ liệu trong các tệp khác nhau, máy chủ có thể
yêu cầu một tên tệp làm tham số yêu cầu.
Ví dụ. nếu có một ứng dụng web để đọc tiểu thuyết ngắn, URL có thể trơng
giống như sau:
/>Ở phía máy chủ, có thể có một thư mục lưu trữ tất cả các tiểu thuyết và máy chủ
sẽ tìm kiếm tên tệp đã cho trong thư mục này. Chẳng hạn, kẻ tấn cơng có thể lạm
dụng hành vi này bằng cách truy cập URL
/>Mẫu lặp lại của ../-s cuối cùng sẽ đến thư mục gốc và kẻ tấn cơng có thể truy cập
bất kỳ tệp nào từ đó.
Giai pháp :
Trong hầu hết các ví dụ trên, kẻ tấn cơng sửa đổi URL, nhưng trong các
ứng dụng web hiện đại, điều này có thể khơng hoạt động. Ngày nay, hầu hết các
ứng dụng web sử dụng API ở phía máy chủ và một số mã javascript ở phía máy
khách để giao tiếp với API. Khi mã javascript gửi yêu cầu đến API, bạn sẽ khơng
thấy bất cứ điều gì trong thanh URL. Nói chung, những yêu cầu này rất giống với
những yêu cầu mà trình duyệt của bạn gửi đến máy chủ khi bạn điều hướng đến
5

URL. Chúng vẫn là các yêu cầu HTTP, chỉ hơi khác một chút. Rất may, hầu hết
các trình duyệt hiện đại đều được trang bị một số công cụ dành cho nhà phát triển,
có thể thực sự hữu ích. Với các cơng cụ dành cho nhà phát triển, bạn có thể kiểm
tra mọi yêu cầu mà trình duyệt của bạn gửi, bất kể nó được gửi như thế nào.
Trong một số trình duyệt (ví dụ: Firefox) có tùy chọn Chỉnh sửa và Resend rất
hữu ích. Bạn có thể làm điều tương tự như trong các ví dụ trên, nhưng thay vì sử
dụng thanh URL, bạn phải sử dụng các cơng cụ phát triển để kiểm tra các yêu cầu
và khi bạn thấy một số thông số đáng ngờ, hãy sửa đổi chúng và gửi lại yêu cầu.
2.

Khai thác từ APIs của web chưa được phân quyền
API là gì?
API là viết tắt của Application Programming Interface phương thức
trung gian kết nối các ứng dụng và thư viện khác nhau.
Nó cung cấp khả năng truy xuất đến một tập các hàm hay dùng, từ đó có thể
trao đổi dữ liệu giữa các ứng dụng.
Đặc điểm nổi bật của API
API sử dụng mã nguồn mở, dùng được với mọi client hỗ trợ XML,
JSON.
API có khả năng đáp ứng đầy đủ các thành phần HTTP: URI,
request/response headers, caching, versioning, content forma…. Bạn có thể sử
dụng các host nằm trong phần ứng dụng hoặc trên IIS.
Mơ hình web API dùng để hỗ trợ MVC như: unit test, injection, ioc container,
model binder, action result, filter, routing, controller. Ngồi ra, nó cũng hỗ trợ
RESTful đầy đủ các phương thức như: GET, POST, PUT, DELETE các dữ
liệu.
Các lỗ hổng API chính
Các lỗ hổng xác thực và tiếp quản tài khoản

 

Nhiều API không kiểm tra trạng thái xác thực khi có u cầu đến từ người
dùng chính hãng. Những kẻ tấn công khai thác các lỗ hổng này theo nhiều cách
khác nhau, như chiếm quyền điều khiển phiên và tài khoản, để bắt chước các lệnh
gọi API chính hãng. Tội phạm mạng cũng thực hiện các cuộc tấn công nhồi thông
tin xác thực để chiếm đoạt tài khoản người dùng.
 
Thiếu mã hóa mạnh
 
Nhiều API thiếu mã hóa mạnh mẽ giữa máy khách và máy chủ API. Những
kẻ tấn công khai thác các lỗ hổng thông qua các cuộc tấn cơng MITM (man-inthe-middle). Theo đó, kẻ tấn cơng chặn các giao dịch API khơng được mã hóa
hoặc được bảo vệ kém để đánh cắp thông tin nhạy cảm hoặc thay đổi dữ liệu giao
6


dịch. Ngoài ra, do việc sử dụng phổ biến các thiết bị di động, hệ thống đám mây
cùng kiến trúc tiểu dịch vụ (Microservice) càng làm cho vấn đề bảo mật API trở
nên phức tạp hơn.
 
Lỗ hổng logic kinh doanh
 
Các API dễ bị lạm dụng logic nghiệp vụ. Đây chính là lý do tại sao cần
phải có giải pháp quản lý chuyên dụng và cần áp dụng phương pháp phát hiện tốt
đối với cả ứng dụng web và ứng dụng di động nhằm phát hiện các nhiều lỗi dương tính giả và âm tính giả.
 
Bảo mật điểm cuối kém
 
Hầu hết các thiết bị IoT và công cụ microservice đều được lập trình để
giao tiếp với máy chủ thơng qua các kênh API. Các thiết bị này tự xác thực trên
máy chủ API bằng chứng chỉ ứng dụng khách. Khi tin tặc cố gắng giành quyền
kiểm soát một API từ điểm cuối IoT và nếu thành cơng, chúng có thể dễ dàng sắp

xếp lại thứ tự API, do đó dẫn đến vi phạm dữ liệu.
Một số giải pháp bảo vệ API khỏi các rủi ro bảo mật
Các mối đe dọa đối với các lỗ hổng API khá đa dạng, bao gồm cấy mã
độc, tấn công giao thức, chuyển hướng không hợp lệ và tấn công bot. Theo
Radware, 1/3 số cuộc tấn cơng chống lại API nhằm mục đích gây ra trạng thái từ
chối dịch vụ (DoS). Bất chấp lỗ hổng bảo mật mà API gây ra nhưng nhiều DN có
xu hướng cấp quyền truy cập API vào dữ liệu nhạy cảm mà không kiểm tra API
để phát hiện hoạt động độc hại.
 
Một số bước đơn giản mà bạn có thể triển khai để giảm thiểu rủi ro bảo mật API
ngay lập tức.
 
Thống nhất kế hoạch bảo mật trong toàn bộ hệ thống
 
Nếu trong nội bộ tổ chức, công ty của bạn đang gặp vấn đề liên quan đến bảo mật
API, thì có khả năng các biện pháp được triển khai khơng phù hợp hoặc thiếu nhất
quán.
 
Để giải quyết vấn đề này, các bên liên quan nên thảo luận về việc làm thế nào để
cùng nhau cộng tác tốt nhất nhằm đề xuất và triển khai sáng kiến bảo mật API
phù hợp với tình hình thực tế. Để làm cơ sở cho các cuộc họp này, các nhóm nên
tham khảo NIST Cybersecurity Framework. Đây là công cụ tuyệt vời để phát triển
sự hiểu biết chung về các rủi ro an ninh mạng trong tồn tổ chức. Nó sẽ giúp các
bên có được nhận thức cơ bản về các API được sử dụng trong toàn tổ chức để xác
định những lỗ hổng tiềm ẩn trong các quy trình liên quan, từ đó có thể cải thiện
chiến lược bảo mật API của mình ngay lập tức.
 
7

Đưa ra vấn đề và tìm cách tháo gỡ
 
Để cải thiện tình trạng bảo mật API của một tổ chức, điều quan trọng là
phải đưa ra được các vấn đề tồn tại và cùng nhau tìm ra phương án giải quyết tối
ưu nhất. Hãy xem xét tổng thể các API mà tổ chức của bạn sử dụng, môi trường
kinh doanh, quản trị, đánh giá rủi ro, chiến lược quản lý rủi ro, kiểm sốt truy cập,
các sự kiện và tình huống bất thường, giám sát bảo mật liên tục, quy trình phát
hiện, v.v... Hãy đảm bảo khơng có bất cứ rủi ro nào bị bỏ sót.
 
Thiết lập quy trình bảo mật API xuyên suốt và bền vững
 
Ngoài việc thực hiện hai bước nếu trên, các tổ chức, doanh nghiệp cũng
cần cân nhắc triển khai các giải pháp hỗ trợ giám sát chương trình bảo mật API
liên tục, qua đó tạo ra một quy trình bảo mật API tồn diện và mạnh mẽ, đồng
thời hỗ trợ khả năng phát triển và thích ứng khi số lượng API rộng và thay đổi.
 
Khả năng hiển thị và kiểm kê tập trung tất cả API, chế độ xem chi tiết về
các mẫu lưu lượng API, giám sát API truyền dữ liệu nhạy cảm, đánh giá sự phù
hợp đặc điểm kỹ thuật API liên tục, có các chương trình xác thực, kiểm sốt truy
cập tại chỗ và chạy phân tích rủi ro tự động dựa trên các tiêu chí được xác định
trước như ai đang truy cập API, vị trí của chúng và cách chúng được sử dụng… là
những chìa khóa để xây dựng một quy trình bảo mật API đủ linh hoạt để theo kịp
mọi thay đổi.
 
Khi các tổ chức, doanh nghiệp tiếp tục mở rộng việc sử dụng API để thúc
đẩy hoạt động kinh doanh, điều quan trọng là cần phải xem xét mọi con đường mà
tội phạm mạng có thể thực hiện để tấn cơng dữ liệu quan trọng của mình, từ đó
xây dựng chiến lược và hệ thống phịng thủ phù hợp.
Mã hóa API – API Encryption
Dữ liệu API phải được bảo vệ khỏi xem lén (và truy cập trái

phép khác) thông qua mã hóa. Tùy thuộc vào giao thức API cụ thể mà
bạn làm việc với và cách thức triển khai, bạn có thể sử dụng một
trong các phương pháp sau để mã hóa API:
HTTP: Nên được thực hiện để bảo vệ yêu cầu chuyển tiếp, để các tin
nhắn được bảo mật và được mã hóa bằng TLS.
JSON WEB TOKEN: Đối với dữ liệu phản hồi JSON, mã thông báo
web JSON (JWT) là một tiêu chuẩn mở xác định các cách để truyền
thông tin một cách an toàn dưới dạng đối tượng JSON giữa các bên.
JWT có thể được ký bằng cách sử dụng một bí mật (với thuật tốn
HMAC) hoặc cặp khóa cơng khai / riêng bằng RSA.
PASSWORD HASH: Điều này là cần thiết để bảo vệ hệ thống (hoặc
giảm thiểu thiệt hại), ngay cả khi có sự thỏa hiệp do nỗ lực hack. Các
thuật toán băm bao gồm MD5, SHA, PBKDF2,…
8


Tấn công vào các điểm cuối API là một phương thức phổ biến để các
ứng dụng hài hịa thơng qua API. Việc bảo vệ chống lại kiểu tấn công
này là triển khai bảo mật ở cấp ứng dụng, sử dụng các kỹ thuật như
sau:
 Ross-site scripting – Các tập lệnh độc hại được đẩy vào một trong các
tham số yêu cầu.
 Code injection – Nạp code vào các dịch vụ, chẳng hạn như SQL (SQL
injection) hoặc XQuery, để mở giao diện cho người dùng kiểm soát.
 Business logic  – Cho phép kẻ tấn công phá vỡ các quy tắc kinh doanh
 Parameter pollution attacks – Khai thác dữ liệu được gửi trong yêu cầu
API bằng cách sửa đổi các tham số của yêu cầu API
 Input Validation – Áp dụng xác thực đầu vào nghiêm ngặt của người
dùng

3.

Nâng cao đặc quyền
Sự leo thang đặc quyền 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 phép và việc nâng cấp hoặc
thay đổi như vậy phải được ứng dụng ngăn chặn. Điều này thường do một lỗ hổng
trong ứng dụng gây ra. Kết quả là ứng dụng thực hiện các hành động với nhiều
đặc quyền hơn so với dự định của nhà phát triển hoặc quản trị viên hệ thống.
Mức độ leo thang phụ thuộc vào những đặc quyền mà kẻ tấn công được phép sở
hữu và những đặc quyền nào có thể nhận được khi khai thác thành cơng. Ví dụ:
một lỗi lập trình cho phép người dùng có thêm đặc quyền sau khi xác thực thành
cơng sẽ giới hạn mức độ leo thang, vì người dùng đã được ủy quyền để giữ một số
đặc quyền. Tương tự như vậy, kẻ tấn công từ xa giành được đặc quyền người
quản trị mà không cần bất kỳ xác thực nào sẽ có mức độ leo thang lớn hơn.
 leo thang theo chiều dọc khi có thể truy cập tài nguyên được cấp cho các tài
khoản đặc quyền hơn
ví dụ: có được đặc quyền quản trị cho ứng dụng
leo thang theo chiều ngang khi có thể truy cập tài nguyên được cấp cho tài khoản
được định cấu hình tương tự
ví dụ: trong một ứng dụng ngân hàng trực tuyến, truy cập thông tin liên quan đến
một người dùng khác.
Tấn công
Trong mọi phần của ứng dụng nơi người dùng có thể tạo thơng tin trong cơ sở dữ
liệu (ví dụ: thanh tốn, thêm liên hệ hoặc gửi tin nhắn), có thể nhận thông tin (sao
9


kê tài khoản, chi tiết đơn đặt hàng, v.v.) hoặc xóa thơng tin (thả người dùng, tin
nhắn, v.v.), cần phải ghi lại chức năng đó. Người thử nghiệm nên cố gắng truy
cập các chức năng đó với tư cách là người dùng khác để xác minh xem có thể truy

cập vào chức năng mà vai trò / đặc quyền của người dùng khơng cho phép hay
khơng (nhưng có thể được cho phép với tư cách người dùng khác).
Ví dụ :
Thao túng nhóm người dùng
Ví dụ: HTTP POST sau cho phép người dùng thuộc về grp001thứ tự truy cập #
0001:
POST /user/viewOrder.jsp HTTP/1.1
Host: www.example.com
...
groupID=grp001&orderID=0001
Xác minh xem người dùng khơng thuộc quyền sở hữu grp001có thể sửa đổi giá trị
của các tham số groupIDvà orderIDcó quyền truy cập vào dữ liệu đặc quyền đó
hay khơng.
4.

Cấu hình sai CORS cho phép truy cập API trái phép
Hoàn cảnh ra đời
Từng có tiêu chuẩn SOP - Same-origin Policy giới hạn việc chia sẻ thông tin giữa
các ứng dụng trong cùng 1 domain giúp tăng mức độ bảo mật cho website. Tuy
nhiên với sự phát triển của ứng dụng web đặc biệt là kiến trúc microservice - chia
nhỏ một ứng dụng lớn ra thành nhiều phần nhỏ độc lập, lượng thông tin lúc này
cần được chia sẻ nhiều hơn giữa các trang với nhau. Do đó để tăng múc độ bảo
mật trong việc di chuyển thông tin giữa các domain khác nhau, tiêu chuẩn CORS
- Cross-origin resource sharing được ra đời.

10


Khái niệm chung
CORS hay chia sẻ tài nguyên đa nguồn là một cơ chế cho phép trình duyệt web

thực hiện các yêu cầu với các miền khác nhau qua việc sử dụng API HttpRequest
một cách có kiểm sốt qua việc kiểm tra nguồn gốc, miền khởi tạo yêu cầu,
giao thức sử dụng giữa trình duyệt và server để xác định cho phép truy cập

Có nhiều key trong HTTP headers liên quan đến CORS nhưng 3 trường sau đây
có ảnh hưởng lớn nhất để bảo mật thôn tin
 Access-Control-Allow-Origin: Phân loại những domain nào có thể truy
cập vào resource của domain.
 Access-Control-Allow-Credentials: quyết định trình duyệt có thể (true)
hoặc khơng thể (false) gửi cookies với request

11




Access-Control-Allow-Methods quyết định phương thức HTTP nào (GET,
PUT, ...) có thể truy cập được vào tài nguyên.

Những sai lầm trong khi cấu hình và cách thức khia thác
1/ Đặt giá trị * - giá trị mặc định cho trường Access-Control-Allow-Origin
Đây là một trong những sai lầm phổ biến nhất. Việc cấu hình như vậy cho phép
domain bất kỳ có thể gửi request đến resources.
Giải pháp
Cấu hình CORS cẩn thận
Chỉ tin tưởng các domain đáng tin cậy
Không sử dụng giá trị null cho origin header
Áp dụng việc xác thực ngay cả với các domain nội bộ
Nếu có thể hãy sử dụng cookie và TLS để tăng tính bảo mật
Đừng tin bất cứ thứ gì người dùng gửi lên, kể cả mấy cái header

5.

Tấn công mã thông báo web JSON (JWT)
Khái niệm chung
JWT - Json Web Token là một chuẩn mở định nghĩa một dạng truyền thông tin rút
gọn và bảo mật thông tin dưới dạng đối tượng JSON. Thông tin này được xác
thực bằng chữ ký số, có thể được ký bằng một thuật tốn bí mật ( với thuật tốn
HMAC ) hoặc với một cặp mã cơng khai / bí mật với RSA.
JWT thường được sử dụng với 2 mục đích phổ biến:

12


1/ Authorization - Ủy quyền: Một khi người dùng đã đăng nhập, mỗi yêu cầu
gửi lên máy chủ sẽ bao gồm cả JWT, cho phép người dùng có thể truy cập tài
nguyên và sử dụng dịch vụ từ máy chủ. Single Sign On - Đăng nhập một lần
cũng là tính năng phổ biến hiện nay có tính ứng dụng từ JWT, do sự nhỏ gọn và
dễ dàng trong việc truyền qua lại giữa các miền khác nhau.
2/ Trao đổi thông tin: JWT có thể giúp việc trao đổi thơng tin trở nên an toàn và
hiệu quả hơn. Do việc JWT sử dụng chữ ký số giúp xác thực người gửi và tính
trọn vẹn của nội dung thơn điệp gửi đi.
Cấu trúc
Gồm 3 phần: header, payload, signature theo dạng xxx.yyy.zzz
Header: thường gồm 2 phần: loại của token và thuật toán được sử dụng để kí số
như HMAC, RSA, … 

Payload: chứa các claims - các biểu thức về 1 thực thể (ví dụ: user,...) và một số
metadata phụ trợ. Có 3 loại claims phổ biến
- Reverse Claim: Đây là một tập hợp các xác nhận quyền sở hữu được xác định
trước, không bắt buộc nhưng được khuyến nghị, để cung cấp một tập hợp các xác

nhận quyền sở hữu hữu ích, có thể tương tác. Một số trong số đó là: Iss (nhà phát
hành), exp (thời gian hết hạn), sub (chủ đề), aud (khán giả)...
- Public Claims: những claim được công nhận và sử dụng rộng rãi
- Private Claims: những claim tự định nghĩa, xác nhận quyền sở hữu để chia sẻ
thông tin giữa những bên đã đăng ký trước đó

Signature: Chữ ký trong JWT là một chuỗi được mã hóa bởi header, payload,
cùng 1 chuỗi bí mật theo nguyên tắc

13


Ba phần được mã hóa riêng bằng Base64Url và được nối với nhau bằng dấu chấm
để tạo ra JWT

Ví dụ về JWT

Lỗ hổng bảo mật phổ biến
Không xác thực chữ kí số
Nhiều thư viện JWT cung cấp 1 phương thức để giải mã và 1 phương thức khác
để xác thực
 decode(): Chỉ giải mã token từ đoạn mã hóa base64url nhưng không xác
thực chữ ký số
 verify(): Giải mã token và xác thực chữ ký số 
Một số lập trình viên có thể lẫn lộn giữa các phương thức. Nếu chữ ký số không
được xác thực, ứng dụng sẽ chấp nhận bất cứ token nào (dựa trên đúng cấu trúc).
Lập Trình viên có thể tắt đi tính năng xác thực chữ ký để kiểm tra trong quá trình
phát triển và quên khơng bật lại. Rất nhiều sai lầm khác có thể dẫn tới việc truy
cập trái phép hay leo thang đặc quyền.
Ví dụ, đoạn token dưới đây khơng được xác thực

14


Kẻ tấn cơng có thể gửi token với chữ ký tùy ý để leo thang đặc quyền

Lỗ hổng None-Algorithm
Chuẩn JWT cho phép nhiều loại thuật toán khác nhau để tạo ra chữ kí số như
RSA, HMAC, Elliptic Curve, None
Việc khơng sử dụng thuật tốn nghĩa là token sẽ khơng được ký. Khi đó, kẻ tấn
cơng có thể bỏ qua việc kiểm tra chữ ký bằng cách thay đổi một thuật tốn hiện có
thành khơng và hủy đi chữ kí đó. Ví dụ ta có đoạn token dưới đây

Sau khi được mã hóa và kí, token sẽ chuyển thành dạng sau (chữ kí được in đậm)

15


Nếu giá trị của trường “alg” là none, kẻ tấn cơng có thể thay thế giá trị đó bằng
các thuật tốn cho phép sau đó loại bỏ chữ ký

Giờ đây, token sau khi bị chỉnh sửa cũng sẽ được ứng dụng chấp nhận

Sự nhầm lẫn thuật toán(Algorithm confusion)
Trong JWT chấp nhận cả thuật tốn mã hóa đối xứng và mã hóa bất đối
xứng. Tùy thuộc vào loại mã hóa, bạn cần sử dụng một shared secret hoặc 1 cặp
khóa public-private
Thuật tốn

Chìa khóa dùng để ký

Khóa được sử dụng để xác minh

Không đối xứng (RSA)

Private key

Public key

Đối xứng (HMAC)

Shared secret

Shared secret

Khi một ứng dụng sử dụng mã hóa bất đối xứng, nó có thể cơng khai khóa cơng
khai và giữ bí mật khóa riêng tư. Điều này cho phép ứng dụng ký mã thơng báo
bằng khóa riêng của nó và bất kỳ ai cũng có thể xác minh mã thơng báo này bằng
khóa cơng khai của nó. Lỗ hổng nhầm lẫn thuật tốn phát sinh khi một ứng dụng
không kiểm tra xem thuật tốn của mã thơng báo nhận được có khớp với thuật
tốn mong đợi hay khơng.
Trong nhiều thư viện JWT, phương pháp để xác minh chữ ký là:
16




verify(token, secret) - nếu mã thông báo được ký với HMAC



verify(token, publicKey) - nếu mã thông báo được ký bằng RSA hoặc
tương tự

Thật không may, trong một số thư viện, phương pháp này tự nó khơng kiểm tra
xem mã thơng báo nhận được có được ký hay khơng bằng cách sử dụng thuật tốn
mong đợi của ứng dụng. Đó là lý do tại sao trong trường hợp HMAC, phương
pháp này sẽ coi đối số thứ hai là bí mật được chia sẻ và trong trường hợp RSA là
khóa cơng khai.
Nếu khóa cơng khai có thể truy cập được trong ứng dụng, kẻ tấn cơng có thể giả
mạo mã thơng báo độc hại bằng cách:
1.
2.
3.
4.

Thay đổi thuật tốn của mã thơng báo thành HMAC
Giả mạo trọng tải để có được kết quả mong muốn
Ký mã độc hại bằng khóa cơng khai được tìm thấy trong ứng dụng
Gửi JWT trở lại ứng dụng

Ứng dụng mong đợi mã hóa RSA, vì vậy khi kẻ tấn cơng cung cấp HMAC thay
thế, verify() phương pháp sẽ coi khóa cơng khai như một bí mật được chia sẻ
HMAC và sử dụng mã hóa đối xứng thay vì bất đối xứng. Điều này có nghĩa là
mã thơng báo sẽ được ký bằng khóa cơng khai khơng bí mật của ứng dụng và sau
đó được xác minh bằng cùng một khóa cơng khai.
Để tránh lỗ hổng này, các ứng dụng phải kiểm tra xem thuật tốn của mã thơng
báo nhận được có phải là thuật tốn mong đợi hay khơng trước khi chuyển mã
thông báo cho verify() phương thức.
Ngắn gọn hơn là: máy chủ đang mong đợi một token được ký bằng RSA, nhưng

thực chất lại nhận được một token đã ký với HMAC, máy chủ sẽ nghĩ rằng
khóa cơng khai thực sự là một khóa bí mật HMAC

Using trivial secrets
Đơn giản là do người lập trình chọn jwt secret dễ đốn hoặc khơng đủ mạnh mẽ.
giúp cho hacker có thể bẻ khóa một cách dễ dàng
kid parameter injections
Kid ? (Key Identifier)
- Chứa id về khóa được sử dụng để mã hóa
- ứng dụng sử dụng để biết được khóa nào được sử dụng và xác minh chữ kí .

17


- Điều này cho phép người gửi báo hiệu sự thay đổi khóa cho người nhận

{
"alg": "HS256",
"typ": "JWT",
"kid": "key1"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}
Tấn công : key |Paramater

Nếu paramater được đưa vào, nó có thể mở ra cách để bỏ qua chữ ký hoặc thậm
chí các cuộc tấn cơng như RCE, SQLi và LFI.

Nếu tham số kid dễ bị chèn lệnh, sửa đổi sau có thể dẫn đến thực thi mã từ xa:
{
"alg": "HS256",
"typ": "JWT",
"kid": "key1|/usr/bin/uname"
}.
{
"name": "John Doe",
"user_name": "john.doe",
"is_admin": false
}

18


kid parameter injection + directory traversal = signature bypass:
Nếu một ứng dụng sử dụng kid tham số để truy xuất khóa từ hệ thống tệp, ứng
dụng đó có thể dễ bị truyền qua thư mục . Sau đó, kẻ tấn cơng có thể buộc ứng
dụng sử dụng tệp có giá trị mà kẻ tấn cơng có thể dự đốn làm khóa để xác
minh. Điều này có thể được thực hiện bằng cách sử dụng bất kỳ tệp tĩnh nào trong
ứng dụng. Biết được giá trị tệp chính, kẻ tấn cơng có thể tạo mã thơng báo độc hại
và ký nó bằng cách sử dụng khóa đã biết.
Kẻ tấn cơng có thể cố gắng chèn /dev/null làm nguồn khóa để buộc ứng dụng sử
dụng khóa trống:

Nếu truyền qua thư mục /dev/null thành cơng, kẻ tấn cơng sẽ có thể ký
một mã thông báo độc hại bằng cách sử dụng một chuỗi trống. 

kid parameter injection + SQL injection = signature bypass

Nếu một ứng dụng sử dụng “kid” tham số để truy xuất khóa từ cơ sở dữ liệu, nó
có thể dễ bị chèn sql . Nếu thành cơng, kẻ tấn cơng có thể kiểm sốt giá trị trả
về “kid” tham số từ truy vấn SQL và sử dụng nó để ký mã thơng báo độc hại.
Một lần nữa sử dụng cùng một mã thơng báo ví dụ, giả sử ứng dụng sử dụng truy
vấn SQL dễ bị tấn cơng sau đây để lấy khóa JWT của nó thơng qua “kid” tham số:

Sau đó, kẻ tấn cơng có thể đưa một “UNION SELECT” câu lệnh vào “kid” tham
số để kiểm soát giá trị khóa:

19


Nếu SQL injection thành công, ứng dụng sẽ sử dụng truy vấn sau để truy xuất
khóa chữ ký:

Truy vấn này trở lại “aaa” vào “kid” tham số, cho phép kẻ tấn công để ký một mã
thông báo độc hại chỉ đơn giản với “aaa”. 
Để tránh các cuộc tấn công này và các cuộc tấn công tiêm khác, các ứng dụng
phải luôn làm sạch giá trị của “kid”tham số trước khi sử dụng nó.

Giai pháp cho mã thơng báo JWT
Xóa mã thơng báo đã lưu trữ khỏi phía máy khách khi đăng xuất
Khi đăng xuất từ phía khách hàng, cách dễ nhất là xóa mã thơng báo khỏi bộ lưu
trữ của trình duyệt.
Nhưng, Điều gì sẽ xảy ra nếu bạn muốn hủy mã thông báo trên Node server Vấn đề với gói JWT là nó không cung cấp bất kỳ phương pháp hay cách thức nào
để phá hủy mã thơng báo.
Vì vậy, để hủy mã thơng báo trên máy chủ, bạn có thể sử dụng gói jwt-redis thay
vì JWT
Thư viện này (jwt-redis) lặp lại hồn tồn toàn bộ chức năng của thư viện
jsonwebtoken, với một bổ sung quan trọng. Jwt-redis cho phép bạn lưu trữ nhãn

mã thơng báo trong redis để xác minh tính hợp lệ. làm cho mã thông báo không
hợp lệ. Để hủy mã thơng báo trong jwt-redis, có một phương thức hủy
nó hoạt động theo cách này:
20


1) Cài đặt jwt-redis từ npm

21