Nghiên cứu về kiểm thử xâm nhập trên website có mã hóa

Kiểm thử xâm nhập ứng dụng web không chỉ để phát hiên các lỗhổng kỹ thuật của hê thống mà còn giúp xác định tác đông tiềm tàng đối với các dữ liêu bảo mật trên hê thống nếu lỗ hổng thực

Trang 1

OC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THO

KHOA AN TOÀN THÔNG TIN

ĐỒ ÁN TỐT NGHIỆP

ĐỀ TÀI: NGHIÊN CỨU VỀ KIỂM THỬ XÂM NHẬP

TRÊN WEBSITE CÓ MÃ HÓA

Sinh viên thực hiện : Tran Anh Đức

Mã sinh viên : B19DCAT047 Lớp : D19CATO3-B Khóa : 2019-2024

Hệ : Dai học chính quy

Trang 2

Hà Nội, 01-2024

il

Trang 3

Đồ án tốt nghiệp Lời cam đoan

LỜI CAM ĐOAN

Tôi xin cam đoan rằng đồ án tốt nghiêp “Nghiên cứu về

kiểm thử xâm nhập trên website có mã hóa” là công trìnhnghiên cứu của bản thân mình Những phần nôi dung sử dụngtài liêu tham khảo có trong đồ án đã được liêt kê và nêu rõ tạiphần tài liêu tham khảo Đồng thời những kết quả trình bàytrong đồ án đều mang tính chất trung thực, không sao chép,

Trần Anh Đức

Trần Anh Đức — B1I9DCAT047 i

Trang 4

Đô án tôt nghiệp Lời cảm ơn

LỜI CẢM ƠN

Lời đầu tiên, em xin được gửi lời cảm ơn chân thành và

lòng biết ơn sâu sắc nhất đến Cô giáo ThS Ninh Thị Thu Trang,

đã nhận lời hỗ trợ em làm đồ án, đã luôn tận tình hướng dẫn,

chỉ dạy và đưa ra những góp ý quý báu để đề tài của em được

hoàn thiên hơn Trong thời gian học tập và làm việc với cô, em luôn nhận được sự giúp đỡ kịp thời giúp em vượt qua những khó khăn quá trình nghiên cứu.

Em xin được gửi lời cảm ơn chân thành nhất đến toàn thể

các thầy cô giáo bô môn, các thầy cô khoa Công nghê thông tinnói chung, các thầy cô trong khoa An toàn thông tin nói riêng

Em cảm ơn các thầy, cô đã giúp đỡ tận tình và tích cực truyền

tải nhiều kiến thức bổ ích về học tập và cả cuôc sống Nhữngkiến thức mà em tích lũy, tiếp thu được trong suốt những tháng

năm giảng đường sẽ là những kiến thức quý báu, bổ ích nhất

mà em luôn khắc ghi

Để hoàn thành đồ án này, em đã nhận được nhiều sự giúp

đỡ từ gia đình, bạn bè, những người đã luôn đông viên, đồng

hành và tạo điều kiên thuận lợi cho em trong suốt quãng thờigian học tập và làm đồ án tốt nghiêp

Trong suốt quá trình nghiên cứu, do kiến thức và khả năngcủa em còn hạn chế nên đồ án này không tránh khỏi những

thiếu sót Em rất mong nhận được những góp ý của thầy cô và

các bạn để kiến thức và đồ án tốt nghiêp của em được hoàn

thiên hơn nữa.

Môt lần nữa em xin chân thành cảm ơn!

Hà Nôi, tháng 01 năm 2024

Sinh viên thực hiên

Trần Anh Đức

Trần Anh Đức — B1I9DCAT047 ii

Trang 5

0969000 -ö- ,ÔỎ |CHƯƠNG 1: TONG QUAN VE KIEM THU XÂM NHẬP WEBSITE 2

1.1 Téng quan về kiểm thử xâm nhập - 2-2 s22 eEE+E+E+EzEerxzxees 2 1.1.1 Khái quát về kiểm thử xâm nhập +-+52+cecs+Eererszterszrereeree 2 1.1.2 Các hình thức kiểm thử xâm nhập - 2+ s+c2+s+c+eers+xeresrsreee 3 1.1.3 Giới thiệu về kiểm thử xâm nhập VU©ÌSifC - «s2 5

1.2 Quy trình kiểm thử xâm nhập website -¿- 2 sex Eerxerxrrees 51.2.1 Khảo sát, thu thập thông tin về mục tiÊM 5- s55 5s+cs+e+cs+se2 71.2.2 Dò quét điỂm VẾM + St SE+ESEEEEEEEEEEE3E1121E1111112111111111111 1x xe 91.2.3 Xác minh lỗ hồng và tấn công kiểm thủử - 2-52 5s+5s xe: 10

1.2.4 Đánh giá mức độ nguy hiểm các lỗ hỗng 5-2 c5s+cs+escssea II 1.2.5 Báo cáo và khuyẾn nghị 2-52 52 St+EEEEEEEEEEEEEEEErEerrkererrred 12

1.2.6 Tdi AANN Side n6 nốốốỐốỐốỐốỐẦốẦỐẦẦỐ ẮỐ 13

2.1.2 Qua trình mã hóa và giải mã trên ve SÏf€ «55s «<< ++s+++ 17

2.2 Quy trình kiểm thử xâm nhập website có mã hóa esses 202.3 Các phương pháp kiểm thử website có mã hóa 2 2555252 23

2.3.1 Phương pháp thu công với công cụ Burp 'ŠUÏÍ€ - ««++-«<+++s 23

2.3.2 Phương pháp sử dụng phan mém POstma :- 5252555: 28

Trần Anh Đức — B1I9DCAT047 iti

Trang 6

Đồ án tốt nghiệp Mục lục

2.3.3 Đánh giá phương pháp thủ công với công cụ Burp Suite và phương pháp sử dụng POSfIHGH - c5 E889 E3 ESEEEESseEErrkkerekerreeerkeeerevee 31

Kết luận ChUON go eeceeseessssssessesscssesscsscsscsecssessssecsrcsrsavsnseesecsssavssaveeeeveeees 32

CHUONG 3: XAY DUNG BURPSUITE EXTENSION UNG DUNG VAOKIEM THU XÂM NHẬP WEBSITE CO MÃ HÓA -: -:-c:+csc2 32

3.1 Xây dung Burp Suite extension ce ceceseeeseeeeceseceeeeneeeeeseeeneeeseeeeeeees 32

3.1.1 Xác định yOu CU ceecececescescesessesvsssesessessssesssssesessssssesessssssseesssseevseseees 32

y7 - A 32

h9» 33 3.2 Xây dung website có mã hóa - - + + 1v vvkEsikeerrerkrrrkee 44 3.2.1 Cai AGt FrONt-ENnd n nhe 13 44

3.3 Ứng dụng AutoPencrypt Extension trong kiểm thử website mã hóa 47

3.3.1 Kiểm thử website ngân hàng BID[ - 5+ c++ee+ee+xczxerrcrrercee 473.3.2 Kiểm thử website P.TIT-SCOF€ - -5cSe+t‡EEEEEEEEEEEEEEEEEEErrrkrkres 50

Trang 7

Đồ án tốt nghiệp Danh mục

DANH MỤC HÌNH ẢNH

Hình 1.1 Môt số loại kiểm thử xâm nhập phổ biến 2

Hình 1.2 Các hình thức kiểm thử xâm nhập - - +: 4

Hình 1.3 Quy trình kiểm thử xâm nhập website 6

Hình 1.4 Các phương pháp thu thập thông tin 7

Hình 1.5 Dò quét lỗ hổng bảo mật bằng công cụ Burp Suite 9

Hình 1.6 Phương diên đánh giá lỗ hổng bảo mật theo tiêu 301009117 3 11

Hình 1.7 Thang điểm CVSS va mức đô nghiêm trong tương ứng — A A 12

Hình 2.1 Giao thức truyền siêu văn bản an toàn HTTPS 16

Hình 2.2 Request va response ở dang bản rõ trên website (o] 0} amy ©) e160] 0 PA, 1 16

Hình 2.3 Request va response bi mã hóa trên website ngân hàng BIIDV L2 1 1212121111 101111111111 1010111010101 10101010101 HH Hư 17 Hình 2.4 Sơ đồ mã hóa giải mã request - response tổng quát .18 Hình 2.5 Sơ đồ chi tiết quá trình mã hóa - giải mã request body "THHa I1AaaaAaaÁAAAa 5S All am 18

Hình 2.6 Sơ đồ chi tiết quá trình mã hóa - giải mã response 00 2: :iliS 19

Hình 2.7 Source code JavaScript của website ngân hàng BIDV.21 Hình 2.8 Request body ở dạng bản rõ khi chạy chế đô debug .22 Hình 2.9 Khởi tạo cặp khóa bất đối xứng RSA - 25

Hình 2.10 Request body ở dạng đối tượng JSON 25

Hình 2.11 Kết quả thực thi script mã hóa request body 26

Hình 2.12 Request được mã hóa body và gửi tới server 27

Hình 2.13 Kết quả giải mã request body về dang bản rõ 27

Hình 2.14 Phần mềm Postman -. -¿5- 5222 2222EEzxeErrrrrrrrea 28 Hình 2.15 Xây dựng request trên ứng dụng Postman 29

Hình 2.16 Response do server trả về trên Postman 30

Hình 3.1 Luồng xử lý request - response của extension ˆ10i4e8i-)aiea/o0777 re 33 Hình 3.2 Giao diên của AutoPencrypt extension 34

Hình 3.3 Sơ đồ thành phần của LogTable - - - +s+s+s+sz¿ 35

Trần Anh Đức — B1I9DCAT047 Vv

Trang 8

Hình 3.4 Lớp đối tượng LogTable - ¿2 - + 2 2+s+E+xz£zzezxzeersrs 35 Hình 3.5 Lớp đối tượng LogEntry - - 2 2+s+E+EzEsEEzEzerrrersrs 36 Hình 3.6 Lớp đối tượng LogTableModel - =2 s+s+s+£zxzcs 37

Hình 3.7 Giao diên HTTPViewer được tạo bởi interface

re e2 1 38

Hình 3.8 Các thuôc tính để xây dựng HTTPViewer 38

Hình 3.9 Các thành phần thuôc Configuration Panel 39

Hình 3.10 Thiết kế JVM của thư viên Javet -5-scscss¿ 40 Hình 3.11 Biểu đồ so sánh hiêu năng thư viên Javet GraalJS -i12 [8] a 41

Hình 3.12 Triển khai ham handleHttpRequestToBeSent() 42

Hình 3.13 Triển khai hàm handleHttpResponseReceived() 43

Hình 3.14 Triển khai hàm loadLibrary() - 2-55: 43 Hình 3.15 Mô hình MERN Stack - 55552 S2 x+xzxzecrerrxreeea 44 Hình 3.16 Giao diên ứng dụng web PTIT-Score - 45

Hình 3.17 Script mã hóa - giải mã trên trình duyêt web 45

Hình 3.18 API được mã hóa request va response body 46

Hình 3.19 Script mã hóa - giải ma phía back-end server 46

Hình 3.20 Tích hợp extension AutoPencrypt vào BurpSuite 47

Hình 3.21 Viết script mã hóa cho website BIDV - 48

Hình 3.22 Viết script giải mã cho website BIDV 48

Hình 3.23 Import thư viên mã hóa node-forge 49

Hình 3.24 Kết quả gửi request thông qua Burp Repeater 49

Hình 3.25 AutoPencrypt ghi lại log các request đã được mã hóa ¬ A11BBBBBB Eset eA AAA GEEEEEES 50 Hình 3.26 Ung dung giới han loại file được upload trên giao 5-0 50

Hình 3.27 Request upload file bị mã hóa body 51

Hình 3.28 Viết script mã hóa cho website PTIT-Score 51

Hình 3.29 Viết script giải mã cho website PTIT-Score 52

Hình 3.30 Import thư viên mã hóa CryptoJS và Node-RSA 52

Hình 3.31 AutoPencrypt thực hiên mã hóa body request upload ¡II 53

Hình 3.32 Kết quả resposne body được giải mã về dạng bản rõ — äỐỐẼa 54

Hình 3.33 Thực hiên cài đặt tấn công Brute force password 54

Trần Anh Đức — B1I9DCAT047 vi

Trang 9

Hình 3.34 Các request brute force được xử lý bởi AutoPencrypt

HH Ẽ ẼäẼäẼA 55

Hình 3.35 Thực hiên rà quét tự đông bang Active Scan 56

Hình 3.36 Kết quả các request scan được AutoPencrypt mã hóa

Ha 56

Hình 3.37 Tạo file chứa request cần dò quét -. 5- 57

Hình 3.38 Dò quét bằng SQLMap với proxy server 58

Hình 3.39 Các request của SQLMap di qua Burp Suite được AutoPencrypt mã hóa - E222 1912121211112 8111121011111 ce 58

Forgery chéo miền

CVSS Common Hé thống Điểm đánh giá lỗ

Vulnerability Scoring hổng chung

System

DNS Domain Name Hê thống phân giải tên miền

Trần Anh Đức — B1I9DCAT047 vii

Trang 10

System

DoS Denial of Service Tấn công từ chối dịch vụ

HIPAA Health Insurance Luật Bảo vê Quyền riêng tư

Portability and và An ninh Y tế

Protocol Secure Văn bản An toàn

IDOR Insecure Direct Lỗ hổng tham chiếu đối

Object Reference tượng không an toàn

IDS Intrusion Detection | Hê thống Phát hiên tấn công

System xâm nhập

IP Internet Protocol Giao thức Internet

ISO International Tổ chức tiêu chuẩn hóa quốc

OSSTMM | Open Source Security | Hudng dẫn phương pháp

Testing Methodology | kiểm thử bảo mật mã nguồn

Manual mở

OWASP Open Web Dự án bảo mật Ứng dụng

Application Security Web mở

Project

PCI DSS Payment Card Tiêu chuẩn bảo mật dữ liêu

Industry Data ngành Thẻ thanh toán

Security Standard

PR Privileges Required Đặc quyền yêu cầu

PTES Penetration Testing | Tiêu chuẩn thực hiên kiểm

Execution Standard thử xâm nhập

PoC Proof of Concept Bang chứng thực nghiêm

Trang 11

RCE Remote Code Thực thi mã từ xa

Execution

RSA Rivest-Shamir- Thuật toán ma hóa khóa

Adleman công khai RSA

SQL Structured Query Ngôn ngữ truy vấn có cấu

Language trúc

SSL Secure Sockets Layer | Tiêu chuẩn công nghé bảo

mật, truyền thông mã hoaTLS Transport Layer Bảo mật lớp Vận chuyển

Security

UI User Interaction Tương tác người dung

URL Uniform Resource Định danh truy cập tài

Locator nguyên trên Internet

WEB World Wide Web Mạng toàn cầu

WSTG | Web Security Testing Hướng dẫn kiểm thử bảo

Guide mật Web

XSS Cross-Site Scripting Lỗ hổng chèn mã script

chéo miền

Trang 12

Đồ án tốt nghiệp Lời mở đầu

MỞ ĐẦU

Trong thời kỳ chuyển đổi số hiên nay, các ứng dụng web

được ra đời ngày càng nhiều nhằm phục vụ các lĩnh vực trong

đời sống như y tế, giáo dục, thương mại điên tử Tuy nhiên, với

các thủ đoạn ngày càng tinh vi của tin tặc, nguy cơ những

thông tin được truyền trên Internet có thể bị đánh cắp thật sự làvấn đề đáng quan tâm Do vậy, để đảm bảo an toàn cho các

thông tin truyền trên Internet, các ứng dụng web hiên đại đã

được triển khai cơ chế mã hóa các thông điêp trao đổi giữa phíawebserver và trình duyêt Điều này giúp đảm bảo chỉ phía trìnhduyêt và máy chủ ứng dụng web mới có thể giải mã thông điêp,

dù tin tặc có chặn bắt, đánh cắp thông điêp trên đường truyền

cũng không thể giải mã được

Tuy viêc mã hóa request - response body giúp đảm bảo an

toàn cho thông diép nhưng cũng gây không ít khó khăn cho

người kiểm thử trong quá trình kiểm thử xâm nhập đối vớinhững website có mã hóa Đây là lý do đề tài “Nghiên cứu về

kiểm thử xâm nhập trên website có mã hóa” cần được tiến

hành tìm hiểu và nghiên cứu Đồ án này sẽ tập trung nghiên

cứu về quy trình kiểm thử xâm nhập website có mã hóa mã hóa

và xây dựng BurpSuite Extension ứng dụng vào kiểm thử web

mã hóa.

Đồ án được xây dựng thành 3 chương:

Chương 1: Tổng quan về kiểm thử xâm nhập websiteChương 2: Quy trình kiểm thử xâm nhập trên website

có mã hóa

Chương 3: Xây dựng BurpSuite Extension ứng dụng

vào kiểm thử xâm nhập website có mã hóa

Trần Anh Đức — B1I9DCAT047 1

Trang 13

Đồ án tốt nghiệp Chương 1

CHƯƠNG 1: TỔNG QUAN VỀ KIỂM THỬ XÂM NHẬP

WEBSITE

Chương 1 giới thiệu tổng quan về kiểm thử xâm nhập ứng

dụng web: định nghĩa, mục tiêu, lợi ích của kiểm thử, các hình

thức kiểm thử xâm nhập phổ biến Bên cạnh đó, chương này

cũng đề cập đến các giai đoạn chính trong quy trình kiểm thử

xâm nhập ứng dụng web thông thường.

1.1 Tổng quan về kiểm thử xâm nhập

1.1.1 Khái quát về kiểm thử xâm nhập Kiểm thử xâm nhập (Penetration Testing hay

Pentest) là quá trình thực hành mô phỏng các cuôc tấn công

của kẻ tấn công vào hê thống nhằm mục đích xác định xem hê

thống, mạng hay ứng dụng có an toàn hay không Các cuôc tấn

công này được thực hiên bên trong hoặc bên ngoài hê thống

giúp cung cấp thông tin về hê thống mục tiêu, xác định các lỗ

hổng bảo mật và phát hiên các cách khai thác có thể gây tổn

hại đến hê thống, ứng dụng [1]

Người kiểm thử xâm nhập (Pentester) sẽ đóng vai trò là

người tấn công xâm nhập vào hê thống để phát hiên, xác định

những điểm yếu và các lỗ hổng bảo mật tiềm tàng của hê thống

mà tin tặc có thể khai thác va gây thiét hại Người kiểm thử xâmnhập cần có được sự cho phép, ủy quyền của chủ hê thống hoặcphần mềm mục tiêu để thực hiên kiểm thử Người kiểm thử còn

được gọi là hacker mũ trắng (white hat hacker hay ethical

hacker) [2].

Đối tượng kiểm thử (Pentest target) thường là các ứng

dụng web, mobile, các API, cơ sở hạ tầng mạng - Network hoặc

bất kỳ đối tượng, hê thống nào có kết nối tới Internet mà có khả

năng bị tấn công khai thác Mỗi đối tượng kiểm thử sẽ tương

ứng với môt loại kiểm thử xâm nhập

Trần Anh Đức — B19DCAT047 2

Trang 14

Mobile Web

application application

Penetration testing

Social Engineering

Hình 1.1 Một số loại kiểm thử xâm nhập phổ biến

Mục tiêu chính của kiểm thử xâm nhập là để cho tổ chứcthấy rằng lỗ hổng có thể được sử dụng bởi kẻ tấn công để

chống lại họ như thế nào Qua đó, chuyên gia bảo mật sẽ cung

cấp lời khuyên về các biên pháp khắc phục, đối phó cần thiếtcần được thực hiên để giảm thiểu các mối đe dọa của những lỗ

hổng được tìm thấy, loại trừ khả năng bị tấn công khai tháctrong tương lai [3] Kiểm thử xâm nhập không phải là môt quá

trình được thực hiên mot lần mà nó cần được thực hiên định kỳ

nhằm phát hiên và ngăn chặn những lỗ hổng bảo mật mới haynhững lỗ hổng Zero-day Trong một số tình huống như thay đổi

cấu trúc hê thống, cập nhật mã nguồn hay thêm chức năng mới

cho ứng dụng thì quá trình kiểm thử cần được thực hiên càng

sớm càng tốt nhằm đảm bảo tính bảo mật liên tục cho hê thống

hoặc ứng dụng.

Những lợi ích quan trọng mà kiểm thử xâm nhập mang lạiđối với tổ chức, doanh nghiép có thể kể đến như:

- Phat hiên kịp thời lỗ hổng bảo mật và điểm yếu tiềm ẩn

bên trong hê thống, giúp giảm thiểu thiêt hại cho hê thống

- _ Đánh giá nguy cơ và mức đô rủi ro mà các lỗ hổng bảo mật

có thể gây ra, giúp tổ chức xác định được các vấn đề nào

cần được ưu tiên khắc phục

- Kiểm tra các chính sách bảo mật đã được thiết lập, triển

khai có thực sự hiêu quả và an toàn hay không Nếu có sự

Trang 15

vi phạm hoặc bất kỳ điểm yếu nào trong thực hiên chínhsách, tổ chức có thể đối phó và cập nhật chính sách kịp

thời.

- Tăng cường nhận thức bảo mật của đôi ngũ phát triển ứng

dụng và người quản lý, giúp họ hiểu hơn về mức đô quan

trọng của viêc bảo vê thông tin và dữ liêu.

- Đảm bảo các hê thống ứng dụng tuân thủ theo các quy

định và tiêu chuẩn bảo mật của từng ngành cụ thể như cáctiêu chuẩn HIPAA, PCI DSS, ISO 27001

1.1.2 Các hình thức kiểm thử xâm nhập

Mặc dù có nhiều loại kiểm thử xâm nhập với các đối tượngkiểm thử khác nhau nhưng đều được triển khai áp dụng theocác hình thức kiểm thử sau: kiểm thử hôp trắng, kiểm thử hôpđen và kiểm thử hôp xám Các hình thức kiểm thử này chủ yếu

khác nhau về hướng tiếp cận đối tượng, viêc áp dụng các hình

thức kiểm thử xâm nhập khác nhau giúp cho tổ chức có thểđánh giá mức đô an toàn của hê thống môt cách đầy đủ và toàndiên nhất

wm © |

ZERO KNOWLEDGE SOME KNOWLEDGE FULL KNOWLEDGE

Hình 1.2 Các hình thức kiểm thử xâm nhập

- Kiểm thử hộp trắng (White box Testing) là hình thức

kiểm thử mà người kiểm thử sẽ được cung cấp mọi thông tin vềđối tượng mục tiêu trước khi họ tiến hành quá trình kiểm thử.Những thông tin này bao gồm: địa chỉ IP, sơ đồ hạ tầng mạng,các giao thức sử dụng, hoặc mã nguồn và các thành phần nôi

bô của ứng dụng.

Mục tiêu của kiểm thử hôp trắng nhằm xác định nguy cơ, lỗhổng tiềm tang trong nôi bô của hé thống, kiểm tra tính đúng

đắn của mã nguồn và xác định điểm yếu bên trong mã giúp

ngăn ngừa nguy cơ bị khai thác từ bên trong.

Trang 16

- Kiểm thử hộp đen (Black box Testing) còn được gọi là

“blind testing”, là hình thức kiểm thử dưới góc đô của môt kẻtấn công trong thực tế Người kiểm thử sẽ không nhận được bất

kỳ thông tin nào về hê thống trước khi tấn công mà phải tự tìm

kiếm và thu thập thông tin về đối tượng để tiến hành kiểm thử

Kiểm thử hôp đen là loại kiểm thử khó thực hiên nhất, đòi

hỏi người kiểm thử phải có trình đô cao và nhiều kinh nghiêm.Hình thức kiểm thử này yêu cầu môt lượng lớn thời gian để tìmhiểu về hê thống mục tiêu và nỗ lực tấn công, nên tốn nhiều chỉ

phí nhưng là hình thức tốt nhất để kiểm tra tính bảo mật tổng

thể của hê thống

- Kiểm thử hộp xám (Gray box Testing) là hình thức

kiểm thử kết hợp giữa kiểm thử hôp trang và kiểm thử hôp den

Người kiểm thử sẽ được cung cấp môt phần thông tin về đối

tượng kiểm thử, ví dụ địa chỉ IP, tài khoản đăng nhập, tài liêu

đặc tả và có quyền truy cập môt phần vào hê thống mục tiêu

Hình thức kiểm thử này thường được áp dụng trong kiểm

thử ứng dụng web, giúp đảm bảo cân bằng giữa tính bảo mật và

tiên ích của người dùng trên những ứng dụng này Tuy nhiên,

kiểm thử hôp xám cũng có hạn chế do không có kiến thức đầy

đủ, chi tiết về mã nguồn, người kiểm thử sẽ không thể kiểm tra

các lỗi cú pháp hoặc lỗi biên dịch của ứng dụng dẫn đến viêc bỏsót các lỗ hổng

1.1.3 Giới thiệu về kiểm thử xâm nhập website

Kể tử khi ra đời vào năm 1990 cho đến nay, công nghê Web

đã phát triển rất mạnh mẽ và là hạ tầng cung cấp các dịch vụ

phổ biến nhất trên Internet Ban đầu, các trang web được ra đời

là các trang web tĩnh, người dùng chỉ có thể đọc các nôi dung

của các trang web này mà không có tương tác nào khác Nhưng khi công nghê WEB 2.0 ra đời, các trang web đông được tạo ra

nhằm tăng khả năng tương tác giữa người dùng và trang web.Các trang web đông cho phép người dùng có thể thực hiên

nhiều thao tác hơn như thêm, sửa, xóa các dữ liêu trên trang

web, nôi dung của trang web có thể thay đổi tùy chỉnh bởi người

dùng Điều này giúp tăng trải nghiêm của người dùng, giúp cho

Trang 17

nôi dung của trang web trở nên sinh đông hơn và các trang web

từ đó cũng được ứng dụng vào nhiều ngành nghề khác nhau

trong thời kỳ chuyển đổi số Các website ngày càng lưu trữ

nhiều thông tin, dữ liêu về người dùng và dan trở thành mụctiêu khai thác của kẻ tấn công

Từ đó khái niêm kiểm thử xâm nhâp ứng dụng web được ra

đời Kiểm thử xâm nhập ứng dung web là mot loại kiểm tra xâm

nhập cụ thể, tập trung vào viêc xác định các lỗ hổng liên quan

đến web và đánh giá tác đông của chúng đối với chủ sở hữu hêthống Kiểm thử thâm nhập ứng dụng web được thực hiên bằngcách mô phỏng các cuôc tấn công trái phép từ bên trong hay

bên ngoài để có được quyền truy cập vào dữ liêu nhạy cảm

Kiểm thử xâm nhập ứng dụng web không chỉ để phát hiên các lỗhổng kỹ thuật của hê thống mà còn giúp xác định tác đông tiềm

tàng đối với các dữ liêu bảo mật trên hê thống nếu lỗ hổng thực

sự bị kẻ tấn công khai thác

Để dam bảo tính hiéu quả, chính xác và hạn chế việc bỏ sót

các lỗ hổng bảo mật trong quá trình kiểm thử xâm nhập web,

người kiểm thử cần phải thực hiên tuân theo môt quy trình kiểm

thử xâm nhập nhất định

1.2 Quy trình kiểm thử xâm nhập website

Hiên nay trên thế giới có môt vài mô hình, tiêu chuẩn đãđưa ra các quy trình kiểm thử xâm nhập khác nhau như tiêu

chuẩn Penetration Testing Execution Standard (PTES) là môt

tiêu chuẩn được sử dụng trong lĩnh vực kiểm thử xâm nhập,cung cấp môt khung làm viêc chi tiết và toàn diên gồm 7 giaiđoạn kiểm thử sau: Tương tác trước khi kiểm thử, Thu thậpthông tin, Mô hình hóa mối đe dọa, Phân tích lỗ hổng bảo mật,

Khai thác, Hậu khai thác, Lập báo cáo [4] Hay mô hình Open

Source Security Testing Methodology Manual (OSSTMM) đưa ra

quy trình kiểm thử gồm 10 giai đoạn chính [5]

Bảng 1 So sánh ưu nhược điểm của quy trình PTES và OSSTMM

Quy trình PTES Quy trình OSSTMM

Ưu điểm |- Cung cấp quy trình|- Tập trung vào việc

Trang 18

kiểm thử rõ rang, chi tiết

- Tập trung vào viéc áp

dụng phương pháp và kỹ

thuật kiểm thử bảo mật

chuyên sâu, giúp đảm

bảo chất lượng và hiêu

suất của quy trình kiểm

thử.

- Có thể được sử dụng

cho các hê thống phức

tạp và môi trường mạng lớn.

với các yêu cầu cụ thể

của dự án kiểm thử

Nhược

điểm

- Yêu cầu môt quá trình

kiểm thử chỉ tiết và tỉ mi,

do đó, nó có thể tốn

nhiều thời gian và nguồn

lực.

- Dodi hỏi kiến thức

chuyên sâu về bảo mật

để triển khai hiêu quả

được thực hiên theo môt trình tự gồm 6 giai đoạn chính:

Giai đoạn 2 Giai đoạn 4 Giai đoạn 6

Đánh giá mức độ nguy

Dò quét điểm yếu ec neehiểm các lỗ hổng Tái đánh giá

Giai đoạn 1 Giai đoạn 3 Giai đoạn 5

Xác minh lỗ hổng và

tấn công kiểm thử

Khảo sát, thu thập Báo cáo và khuyến nghị

thông tin về mục tiêu

Hình 1.3 Quy trình kiểm thử xâm nhập website

Trang 19

1.2.1 Khảo sát, thu thập thông tin về mục tiêuGiai đoạn Thu thập thông tin là giai đoạn nhằm thu thập

càng nhiều thông tin về mục tiêu càng tốt, viêc thu thập thông

tin day đủ và chính xác sẽ giúp rút ngắn thời gian kiểm thử di

nhiều lần Đây là giai đoạn đầu và cũng là giai đoạn quan trọng

nhất của quy trình kiểm thử xâm nhập

Trong giai đoạn này, người kiểm thử sẽ sử dụng các công cụ

để quét lỗ hổng, cổng mở và các dịch vụ chạy trên cổng hoặc

mọi thông tin được công khai trên internet để phục vụ kiểm thửnhư thông tin về phiên bản máy chủ ứng dụng, phiên bản ngôn

ngữ, framework, các đường dẫn ẩn, subdomain của ứng dụng.

Các thông tin này thường được thu thập theo 2 cách phổ biến:

thu thập thông tin thụ đông và thu thập thông tin chủ đông.

INFORMATION

ACTIVE GATHERING PASSIVE

h

@ lx :

Hình 1.4 Các phương pháp thu thập thông tin

1.2.1.1 Thu thập thông tin thụ động Thu thập thông tin thụ đông là viéc thu thập thông tin ma

không tương tác trực tiếp với đối tượng hoặc sử dụng thông tin

có sẵn được công khai hoặc có tương tác nhưng chỉ thực hiên

các thao tác sử dụng ứng dụng web như người dùng bình

thường Mục tiêu của thu thập thông tin thụ đông là tìm hiểu,

thu thập càng nhiều thông tin về ứng dụng càng tốt mà không

để lại bất kỳ dấu vết nào, không gây ra bất kỳ tác đông nào tớitưởng lửa hoặc hê thống phát hiên tấn công xâm nhập IDS

Môt số kỹ thuật thường được sử dụng để thu thập thông tin

thụ đông gồm:

Trang 20

- Xem mã nguồn HTML của trang web có thể cung cấp

thông tin về cấu trúc và các phần tử trong trang web,

qua đó có thể tìm thấy URL của các tài liêu, hình ảnh,

thư viên js hoặc các phần tử khác mà trang web sử

dụng.

- Kiểm tra tên miền và thông tin WHOIS để thu thập

thông tin về tên miền của trang web, thông tin về

người sở hữu, đăng ký và quản lý tên miền, tên đơn vịcung cấp dịch vụ tên miền

- Thu thập thông tin từ công cụ tìm kiếm như

GoogleHacking, Shodan Search Engine để lọc, tìm

kiếm và xác định được các lỗ hổng, các thông tin dữ

liêu nhạy cảm của mét trang web như địa chỉ IP, vị trí,

hê điều hành các cổng mở của các máy chủ web

Quá trình thu thập thông tin thụ đông sẽ giúp người kiểm

thử hiểu rõ hơn về ứng dụng web mục tiêu, thu thập thông tin

phục vụ cho giai đoạn tiếp theo của quá trình kiểm thử, giúp

nâng cao khả năng tấn công khai thác hiêu quả mà không tiết

lô dấu vết, sự tồn tại của mình đối với ứng dụng

1.2.1.2 Thu thập thông tin chủ động

Thu thập thông tin chủ đông trong kiểm thử xâm nhập làmôt phương pháp thu thập thông tin về mục tiêu bằng cách

tương tác trực tiếp với hê thống, ứng dụng hoặc mạng mục tiêu

Khác với phương pháp thu thập thông tin thụ đông, trong quá

trình thu thập thông tin chủ đông, người kiểm thử thực hiên các

hoạt đông tấn công nhằm khám phá và thu thập thông tin từ

mục tiêu Việc thu thập thông tin chủ đông sẽ giúp thu thập

được nhiều thông tin hơn về ứng dụng web và các lỗ hổng đang

tồn tại trên ứng dụng

Môt số kỹ thuật thường được sử dụng:

- Port Scanning để xác định các cổng mạng được mở

trên máy chủ web, từ đó tìm ra các dịch vụ đang chạy

trên các cổng đó

- Brute Force Attack: thử đăng nhập bằng cách sử dụng

các danh sách tên người dùng, mật khẩu phổ biến

Trang 21

(wordlists) để thực hiên liệt kê username (userenumeration), vét cạn mật khẩu và tìm ra mật khẩu

đăng nhập hợp lê.

- Application Fingerprinting: phát hiên và xác định các

ứng dụng sử dụng công nghê, ngôn ngữ hay thư viên

gì và các phiên bản tương ứng bằng công cụ

Wappalyzer.

- DNS Enumeration: xac dinh cac ban ghi DNS cua muc

tiêu để thu thâp thông tin về tên miền (domain) và

các tên miền con (subdomain) của hê thống ứng dụng

web.

Quá trình thu thập thông tin chủ đông sẽ giúp người kiểmthử đánh giá mức đô bảo mật của hê thống và xác định các

điểm yếu, lỗ hổng bảo mật có thể được khai thác Tuy nhiên,

việc thực hiên các hoạt đông thu thập thông tin chủ đông này

có thể tạo ra sự chấn đông hoặc ảnh hưởng đến hiêu suất của

hê thống mục tiêu, vì vậy nó phải được thực hiên cẩn thận vàcùng với sự chấp thuận của người quản lý hê thống hoặc chủ sở

hữu.

1.2.2 Dò quét điểm yếu

Dò quét điểm yếu là môt trong những giai đoạn quan trọng

trong quá trình kiểm thử bảo mật của môt hê thống hoặc ứngdụng Giai đoạn này giúp người kiểm thử xác định được các lỗhổng bảo mật tiềm tàng mà có thể bị khai thác trong tương lai

Giai đoạn này bao gồm viêc sử dụng các kỹ thuật và các

công cụ rà quét lỗ hổng như Acunetix, Nessus, OWASP ZAP,BurpSuite để dò tìm các lỗ hổng bảo mật, thiếu sót cấu hình và

các vấn đề liên quan khác trên hê thống hoặc ứng dụng đangđược kiểm thử

Trang 22

Đồ án tốt nghiệp Chương 1 '“ Burp Suite Professional | = |[ml mm

Burp Intruder Repeater Window Help

Results | Scan queue [Live scanning | Options |

/ @ Cross-site scripting (stored)

> @ addressbook @ HTTP header injection

> 1 admin | |

> @ cclookup > @ Cleartext submission of password [2]

» ? employees ! OS command injection

» j filestore ? LDAP injection

» 7 labs © Open redirection

> @ search » @ Password field with autocomplete enabled [2]

> @ settings » | Cross-domain Referer leakage [2] v

> © updates

> j https://0b7bd624bab7 mdseclabs net | Advisory [ Request | Response Ì

a

@ Cross-site scripting (reflected) )

Issue: Cross-site scripting (reflected)

Hình 1.5 Dò quét lỗ hổng bảo mật bằng công cu Burp Suite

Các công cụ dò quét bảo mật tự đông sẽ tạo ra các yêu cầu

(request) đến ứng dụng web và dựa vào phản hồi để kiểm tra

các lỗ hổng bảo mật, từ đó có thể xác định được các lỗ hổng

phổ biến như SQL injection, XSS, CSRF, clickjacking và phát hiênđược điểm yếu trong quá trình triển khai và cấu hình của ứng

dụng web Kết thúc quá trình dò quét, các công cụ sẽ đưa ra

danh sách mô tả chỉ tiết về các lỗ hổng kèm theo mức đô chắcchắn về lỗ hổng đã phát hiên được Người kiểm thử sẽ dựa vào

kết quả dò quét để thực hiên viêc xác minh lỗ hổng và tấn công

kiểm thử trong giai đoạn tiếp theo của quy trình kiểm thử xâm

nhập.

”^?

1.2.3 Xác minh lỗ hổng và tấn công kiểm thử

Xác minh lỗ hổng và tấn công kiểm thử là giai đoạn thực

hiên khai thác các lỗ hổng bảo mật đã được xác định để đảm

bảo rằng các lỗ hổng đó thực sự tồn tại và có thể bị khai thác.

Sau khi lỗ hổng đã được xác minh, người kiểm thử sẽ xây dựng

vector tấn công và sử dụng các kỹ thuật, công cụ để tấn công

Trang 23

ứng dụng web và khai thác các lỗ hổng bảo mật đã được xác

định.

Ngoài những lỗ hổng bảo mật được phát hiên trong giai

đoạn Dò quét điểm yếu, người kiểm thử cần thực hiên tấn công

kiểm thử theo môt số checklist như OWASP Top 10, OWASP

WSTG v4.2 để phát hiên và khai thác những lỗ hổng bảo mật

mà công cụ rà quét không thể xác định được Checklist

“OWASP WSTG v4.2” là môt trong những checklist chi tiết,

day đủ và được sử dụng phổ biến nhất hiên nay Trong checklist

đưa ra danh mục hướng dẫn đánh giá những lỗ hổng bảo mật

nghiêm trọng nhất trên các ứng dụng web [6]:

(1)Configuration and Deployment Management Testing

(Đánh giá cấu hình và quan ly triển khai)

(2)Identity Management Testing (Đánh giá quản lý định

danh)

(3) Authentication Testing (Đánh giá quá trình xác thực)

(4) Authorization Testing (Đánh giá quá trình phân quyền)

(5) Session Management Testing (Đánh giá quản lý phiên)

(6)Input Validation Testing (Đánh giá kiểm tra dữ liêu đầu

vào)

(7) Testing for Error Handling (Đánh giá quá trình xử lý lỗi)

(8)Testing for Weak Cryptography (Đánh giá điểm yếu

trong mã hóa) (9)Business Logic Testing (Đánh giá hoạt đông nghiệp vụ)

(10) Client-side Testing (Đánh giá phía máy khách) (11) API Testing (Đánh giá API).

Trong mỗi mục đánh gia, checklist đã xây dung vector tấn

công tương ứng của từng lỗ hổng bảo mật theo hai hình thức

kiểm thử chủ yếu là kiểm thử hôp đen và kiểm thử hôp xám.Người kiểm thử sẽ thực hiên tấn công, khai thác các lỗ hổng bảomật theo từng mục nhỏ trong checklist, để đảm bảo rằng ứng

dụng web đã được đánh giá kỹ lưỡng thông qua mọi vector tấn

công và xác định được mọi lỗ hổng bảo mật đang tồn tại trên

ứng dụng web.

Trang 24

1.2.4 Đánh giá mức độ nguy hiểm các lỗ hổngSau khi xác định, phát hiên được tất cả các lỗ hổng bảo mật

trên ứng dụng web, người kiểm thử sẽ thực hiên đánh giá mức

đô nguy hiểm và rủi ro của các lỗ hổng bảo mật đối với hê

thống ứng dụng Từ đó có thể xác định mức đô ưu tiên để giải

quyết các lỗ hổng này

Trong giai đoạn này, người kiểm thử đánh giá mức đô nguy

hiểm, tác đông của các lỗ hổng bảo mật dựa trên các yếu tố

như tính bí mật, tính toàn vẹn và tính sẵn dùng Viêc đánh giá

mức đô nguy hiểm của các lỗ hổng bảo mật trong kiểm thử xâm

nhập được thực hiên theo môt tiêu chuẩn chung là tiêu chuẩn

CVSS (Common Vulnerabiliy Scoring System - viết tắt của hê

thống đánh giá lỗ hổng bảo mật chung) Tiêu chuẩn này được

tạo ra nhằm đánh giá ảnh hưởng do lỗ hổng bảo mật gây ra cho

hê thống ứng dụng Dựa trên tiêu chuẩn này, người kiểm thử sẽ

đánh giá mức đô nghiêm trọng của lỗ hổng bảo mật trên hai

phương diên là "Mức đô khó của tấn công" và "Ảnh hưởng bởi

tấn công"

Mức độ khó của tấn công Ảnh hưởng bởi tấn công

Attacker có thể dễ dàng tấn oP Vi phạm C-I-A của thông tin ở

công System hay không? mức độ nào?

Hình 1.6 Phương diện đánh giá lỗ hổng bảo mật theo tiêu

chuẩn CVSS

“Mức đô khó của tấn công” sẽ được đánh giá dựa trên các

tiêu chí sau:

- Attack Vector (AV): Phân loại nguồn tấn công

- Attack Complexity (AC): Sự phức tạp của điều kiên

tấn công

- Privileges Required (PR): Mức đô đặc quyền cần thiết

- User Interaction (Ul): Mức đô yêu cầu tương tác từ

người dùng.

Trang 25

- Scope (S): Phạm vi ảnh hưởng của tấn công

“Ảnh hưởng bởi tấn công” nhằm xác định mức đô ảnh

hướng của lỗ hổng tới ba đặc tính của An toàn thông tin:

- Confidentiality Impact (C): Ảnh hưởng đến tính bí mật.

-_ Integrity Impact (I): Ảnh hưởng đến tính toàn vẹn.

- Availability Impact (A): Ảnh hưởng đến tính sẵn dùng.

Điểm CVSS cơ sở hay CVSS Base Score là mức điểm dựa

trên kết quả đánh giá của hai phương diên nêu trên Giá trị nàyđược dùng để đánh giá tầm quan trọng và mức đô nghiêm trọng

của lỗ hổng Mức đô nghiêm trọng của lỗ hổng được chia thành

4 mức chính: Nghiêm trọng (Critical), Nguy hiểm (High), Trung

bình (Medium) và Thấp (Low)

0 None

Hình 1.7 Thang điểm CVSS và mức độ nghiêm trọng tương ứng

Tổ chức hoặc chủ sở hữu của hê thống ứng dụng sẽ dựa vào

các mức đô nghiêm trọng của từng lỗ hổng để xác định lỗ hổng

nào cần được ưu tiên giải quyết và khắc phục

Trang 26

1.2.5 Báo cáo và khuyến nghị

Báo cáo và khuyến nghị là môt trong những giai đoạn quan

trọng nhất trong quy trình kiểm thử xâm nhập Trong giai đoạn

này, các kết quả kiểm thử từ các giai đoạn trước đó sẽ được

tổng hợp, phân tích và đưa ra các báo cáo chỉ tiết về các lỗ

hổng bảo mật, rủi ro, thiêt hại có thể xảy ra và đề xuất các biên

pháp giải quyết, khắc phục lỗ hổng Kết quả của quá trình kiểm

thử cần được trình bày chi tiết, rõ ràng và cần phải thể hiên

những nôi dung quan trọng sau:

Thông tin về phạm vi (scope) của hê thống ứng dụng đã

được kiểm thử xâm nhập

Tóm tắt tổng quan về kết quả kiểm thử: phần này baogồm số lượng của từng loại lỗ hổng được tìm thấy, mức

đô nghiêm trọng và ảnh hưởng dự kiến của các lỗ hổng

đối với hê thống

Danh sách chi tiết lỗ hổng: ở phần này, người kiểm thử

cần mô tả về kịch bản khai thác lỗ hổng, đưa ra bằngchứng khai thác (PoC) để chứng minh sự tồn tại của lỗhổng, giúp người đọc có thể hiểu rõ hơn về tình huống và

cách thức khai thác Bên cạnh đó, báo cáo cần đưa ra

mức đô nghiêm trọng và tác đông của từng lỗ hổng

Khuyến nghị: người kiểm thử đề xuất các giải pháp, biên

pháp khắc phục và cải thiên dựa trên từng lỗ hổng đã tìmthấy Mỗi khuyến nghị nên được mô tả chỉ tiết, bao gồm

cách thức thực hiên, các biên pháp bảo mật mới, cung

cấp thêm các tài liêu tham khảo và hướng dẫn để hỗ trợnhà phát triển hê thống trong quá trình khắc phục

Tổng kết về quá trình kiểm thử, nhấn mạnh về tầm quan

trọng của viêc khắc phục các lỗ hổng bảo mật và cải

thiên bảo mật cho ứng dụng web Ngoài ra báo cáo cần

đề cập đến thời gian, cách thức tiến hành kiểm tra tái

đánh giá sau khi triển khai biên pháp khắc phục để đảm

bảo rằng lỗ hổng đã được giải quyết môt cách hiéu quả

Báo cáo và khuyến nghị kiểm thử xâm nhập cung cấp môt

cái nhìn toàn diên về tình trạng bảo mật của ứng dụng web và

Trang 27

đóng góp quan trọng vào viêc nâng cao bảo mật và giảm thiểu

rủi ro của hê thống Do vậy, báo cáo nên được viết môt cách rõ

ràng, chi tiết và dễ hiểu để người đọc và các nha phát triển cóthể thực hiên các biên pháp khắc phục môt cách hiéu qua

1.2.6 Tái đánh giá

Sau khi các nhà phát triển hê thống ứng dụng web thực

hiên giải quyết, khắc phục các lỗ hổng bảo mật, người kiểm thử

sẽ tiến hành tái đánh giá lại ứng dụng web dựa trên những lỗ

hổng đã tìm thấy Giai đoạn này là giai đoạn cuối cùng trongquy trình kiểm thử, mục tiêu chính của giai đoạn này là xác

nhận rằng các lỗ hổng đã được khắc phục triêt để hoàn toàn và

không tạo ra các lỗ hổng bảo mật mới Người kiểm thử sẽ sửdụng các phương pháp và kỹ thuật kiểm thử xâm nhập tương tựnhư trong quá trình kiểm thử ban đầu để tiến hành đánh giá lại

lỗ hổng, xác minh rằng lỗ hổng không còn tồn tại Nếu các lỗ

hổng bảo mật đã được giải quyết không đúng cách hoặc còn tồntại các lỗ hổng bảo mật khác, người kiểm thử sẽ tiếp tục đề xuất

các biên pháp để giải quyết chúng

Tương tự như giai đoạn Báo cáo và khuyến nghị trong quy

trình kiểm thử, kết quả của quá trình tái đánh giá cũng được ghi

lại, mô tả chi tiết cách thức tái đánh giá và đánh giá hiêu quả

của các biên pháp khắc phục Nếu các lỗ hổng bảo mật đã đượckhắc phục hoàn toàn và không tìm thấy lỗ hổng mới, hê thống

ứng dụng web sẽ được ghi nhận là an toàn.

Kết luận chương

Chương 1 đã trình bày khái quát về kiểm thử xâm nhập:

định nghĩa, mục tiêu, lợi ích mà kiểm thử xâm nhập mang lại,các hình thức kiểm thử xâm nhập phổ biến Bên cạnh đó,

chương này cũng nêu rõ quy trình kiểm thử xâm nhập đối với

môt website thông thường.

Trang 28

CHƯƠNG 2: QUY TRÌNH KIỂM THỬ XÂM NHẬP TRÊN

WEBSITE CÓ MÃ HÓAChương 2 sử dụng website thực tế của ngân hàng BIDV để

làm ví dụ minh họa và làm cơ sở lý thuyết để trình bày tổngquan về website có mã hóa: đặt vấn đề, quá trình mã hóa và

giải mã request - response giữa máy chủ ứng dụng web và trình

duyệt Ngoài ra, trong chương này có đưa ra quy trình kiểm thử

xâm nhập trên website có mã hóa, các phương pháp kiểm thử

web mã hóa phổ biến Từ đó làm cơ sở đánh giá và đề xuất

phương pháp sử dụng BurpSuite Extension.

2.1 Tổng quan về website có mã hóa

2.1.1 Đặt vấn đề

Môi trường Internet ngày càng phát triển và được sử dụngrông rãi, đã mở ra môt thế giới kết nối toàn cau, cho phép

chúng ta truy cập vào hàng tỷ trang web, ứng dụng di đông và

dịch vụ trực tuyến Tuy nhiên, cùng với sự phát triển của

Internet và ứng dụng web, nguy cơ về bảo mật thông tin và tỷ

lê tôi phạm mạng ngày càng tăng cao Vì vậy viêc bảo mật dữ

liêu, an toàn thông tin trên đường truyền Internet ngày càng

được chú trọng hơn, đặc biêt là đảm bảo an toàn cho dữ liêu trên ứng dụng web.

Trước đây, các website được phát triển chủ yếu dựa trên

giao thức truyền tải siêu văn bản - HTTP (Hypertext Transfer

Protocol) để truyền dữ liêu dưới dạng văn bản, hình ảnh, âm

thanh, video từ máy chủ ứng dụng web tới trình duyêt phía người dùng và ngược lại HTTP hoạt đông theo mô hình Client (máy khách) - Server (máy chủ) Việc truy cập website được

tiến hành dựa trên các giao tiếp giữa 2 đối tượng trên Trong

quá suốt quá trình kết nối và trao đổi thông tin, giữa trình duyêt

người dùng và máy chủ ứng dụng web không có biên pháp xác

thực nào, các thông tin trao đổi được gửi qua giao thức HTTP(bao gồm địa chỉ IP, dữ liêu mà người dùng nhập vào websit)không được mã hóa và bảo mật Đây chính là kẽ hở mà nhiều kẻ

tấn công đã lợi dụng để đánh cắp thông tin người dùng, thường

Trang 29

được gọi là tấn công nghe lén (sniffing) hay tấn công Man in The

Middle [7].

Do đó, giao thức HTTPS được ra đời, là giao thức HTTP tích

hợp thêm Chứng chỉ bảo mật SSL nhằm mã hóa các thông điêp

để tăng tính bảo mật cho thông diép trên đường truyền

Internet HTTPS hoạt đông tương tự như HTTP, tuy nhiên được

bổ sung thêm chứng chỉ SSL (Secure Sockets) hoặc TLS(Transport Layer Security) Hiên tại, HTTPS là tiêu chuẩn bảo

mật hàng đầu cho hàng triêu website trên toàn thế giới, tiêu

chuẩn này giúp đảm bảo các nôi dung thông diép sẽ được mã

hóa trước khi truyền đi, và giải mã khi nhận Điều này khiến kẻ

tấn công dù có nghe lén hay chặn bắt gói được tin trên đường

truyền cũng không thể đọc được nôi dung của thông tin đó [7]

Khi thực hiện kiểm thử xâm nhập các website thông thường (website sửdụng giao thức HTTP hoặc HTTPS), người kiêm thử có thé chặn bắt và dé dàng

quan sát request, response của ứng dụng đó ở dạng bản rõ nhờ công cụ

BurpSuite Nếu website đó sử dụng giao thức HTTPS, công cụ BurpSuite sẽ tự

động bóc tách lớp mã hóa request, response được thực hiện bởi HTTPS và hiển thị cho người kiểm thử.

Trang 30

f ] = m Request Response

Raw Hex \n = Pretty Raw Hex =] =

1 POST /api/auth/login HTTP/1.1 uu) °°» »

2 Host: qldt.ptit.edu.vn 12 {

3 Accept: application/json, text/plain, */* "IDUser":@

4 Accept-Language: en-US,en;q=0.5 "Session":

5 Accept-Encoding: gzip, deflate, br "id" null

6 Content-Type: application/x-www-form-urlencoded “name” :null,

7 Ua: 8%MTcwNTQ5MDkwMDQzMg==%U2F SdGVkX1+5SHt@sROXe+x5ch/BYPp319DV6N7btog= "Eu11Name":nu11

8 Idpe: @ "error":nu11,

9 Content-Length: 58 “principal":null

1@ Origin: https://qldt.ptit.edu.vn “access token" :null

11 Referer: https://qldt.ptit.edu.vn/ "refresh_token":nu11

12 Sec-Fetch-Dest: empty "userName":nu11 ,

13 Sec-Fetch-Mode: cors "roles" :null

14 Sec-Fetch-Site: same-origin “info":null '

15 Te: trailers “IDDVPC":null

16 Connection: close "tatcape":false

các ứng dụng web còn triển khai thêm bước mã hóa request và

response body nữa như mot bước bảo mật bổ sung quan trọng.Viêc mã hóa request và response body nhằm bảo vê dữ liêu

trong lưu trữ, đảm bảo dữ liêu được an toàn ngay cả khi được

lưu trữ trên máy chủ Mặc dù dữ liêu có thể đã được mã hóa khi

truyền tải, nhưng nếu nó không được mã hóa trong quá trình

lưu trữ, nó có thể bị lô khi máy chủ bị tấn công hoặc bị truy cập

trái phép Ngoài ra, trong môt số ngành và lĩnh vực như ngânhàng, tài chính, tín dụng, y tế thì viêc thực hiên mã hóa request

và response body là bắt buôc, giúp đảm bảo tuân thủ các quy

định pháp luật và tiêu chuẩn bảo mật liên quan đến bảo mật

thông tin, dữ liêu người dùng như ISO 27001, PCI-DSS.

Đối với những website có mã hóa này, công cụ BurpSuite

cũng thực hiên việc bóc tách lớp mã hóa HTTPS nhưng bên

trong request body và response body được triển khai bổ sung

thêm môt lớp mã hóa nữa Điều này giúp tăng tính bảo mật củathông tin trên đường truyền nhưng gây không ít khó khăn đối

với người kiểm thử xâm nhập

Trang 31

= a

Request Response

Pretty Raw — Hex in = Pretty Raw Hex Bn =

Post /w2/auth HTTP/1.1 i HTTP/1.1 401 Unauthorized

Host: smartbanking idv com vn Date: Sun, 17 Dec 23 10

3 User-Agent: Mozi 0 (Windows NT 10.0; Winé4; x64; rv:120.0) 3 Content-Type: application/j

Gecko/20100101 Firefox/120.0 4 Connection: close

4 Accept: application/json 5 vary: Origin

5 Accept-Language: vi 6 Vary: Acc

6 Accept-Encoding: p 7 Vary: Acc

X-Request-Td Access-Control-Allow-o

tent -Type ntent-Type-Options

tent -Lengt $S-Protection: 1; m

1i Referer: http smartbanking bidv com vn/dang-nhap 2 Pragma: no-cache

¡2 Sec-Fetch-Dest: empty Expires: 0

3 Sec-Fetch-Mode: cors 4 X-Frame-Optior

Sec-Fetch-8ite: same-origin| 5 Server: BIDV

15 Te: trailers 16 Content-Length:

nection: close

ens

"'$q xgHwB xSWEYVHiMmu lad 4DCOCE gR3bGKHKGnV2aF nW2pF 6qH/2q3z8t ShoOgEePvy

OEUCULGE /t 7z5y1nRT2SEOhGSghBDyo=",

nan:

"V¥n68iimJoHuft Lvx363LdZsmnOcMNCW£Cdbkd+nIm3vadbOkaF fev7I£CnIbLbK1lsp

SGETnf q2HbSOaKkvVd pOvy 2xSKAiai VNMPqLASeGqzIZ10BZcUR tt SSZBb8CDK7Se6Kb71Di + U+qvMRIOeWNNEFen 1qE20Zqiol Saaa0xhNqvpéUMQunGVr

BzROVWCaxiwptHs/E/fTOWXOUmiyBxjpof vCSew4wo PyRgdg0/ d6kgwe 17CwdUCJ32aw8C3 Wiw4WbdJcxqEW+CLT SCnHje PCSYMg+ZdYyR7C/ TsmbA=="

E/ qnQ3aAc4T4m+ Sa ScRFudcJ INKZE1lyW3iJ1wGxZhn15B7bLVyEhzDGd1GSaGBnnSkwAv

"oPReLEJ7iLVGRpCjAKLY 1KjNSMz Laco P2upnadSYWMo f Le vShbB Zo DAo PDAXSEXvb4pLn

/$qj01Za5nwfzv4QuiAL/IASAIVCewkKCpoGAPGz8T/0oGDFs8Bb1YgduuLVAcWVt24t 6f#o

10T?vn4ZE5xD7hU2Bgu9zW jmamdzA£UEz£fktYvNsW12gWNyqhh0rii+A58U13)ZG£im3QyV.

3U8%85 OypsMTE90V2kz PgOKH4D1V5 PWhpw45 00Ao UpOWYRk 4AYLO PRwLyRZYUOfw}YH7Pu

nKW9 6B QOkwe Zd0 jsCx6nuS9s9EULsAryDEAOLBP7ekS2¥y9 0AGbnVnuvSn1opo=="

Hình 2.10 Request và response bị mã hóa trên website ngân

hàng BIDV

”2m ~

2.1.2 Quá trình mã hóa và giải mã trên website

Trong suốt quá trình gửi và nhận thông điêp giữa máy chủứng dụng (server) và trình duyêt (client), các thông điêp đềuđược mã hóa trước khi truyền đi và đảm bảo chỉ bên nhận mới

có thể thực hiên giải mã thông diép đó Mỗi khi trình duyêt gửiyêu cầu (request) tới máy chủ web, trình duyêt sẽ thực hiên

viêc mã hóa request body sau đó gửi thông điêp ở dạng bản mã

dung.

Tran Anh Đức — B19DCAT047 18

Trang 33

(1)Ở phía Client, request body ban đầu ở dạng bản rõ sẽ

được mã hóa bằng khóa bí mật AES được sinh bởi trình

duyêt.

(2)Khóa bí mật AES của client được mã hóa bằng khóa công

khai RSA của máy chủ ứng dụng web Khóa công khai

RSA này là khóa mặc định và được gửi cho Client mỗi khi

trang web được truy cập trên trình duyêt.

(3)Khi đó request body được gửi tới phía Server sẽ bao gồm

khóa AES được mã hóa và request body gốc được mã

hóa.

(4)Phía Server sau khi nhận được request sẽ sử dụng khóa

bí mật RSA để giải mã và có được khóa bí mật AES của

Client.

(5)Server dùng khóa AES này để giải mã phần còn lại trong

request body và có được request body ở dạng bản rõ ban

đầu

Trong request body nay sẽ chứa môt giá trị là khóa công khai RSA của Client Sau khi xử lý request, máy chủ web sẽ thực

hiên sinh khóa bí mật AES để mã hóa response body và dùng

khóa công khai RSA của Client để mã hóa khóa AES

Original —) Encrypted =) anginal

Response Body Response Body Response BodyEncrypt Decrypt

Webserver Client

Hình 2.13 So đồ chi tiết quá trình mã hóa - giải mã response

body

Trang 34

Quá trình mã hóa và giải mã response body được mô tả như

Sau:

(1)Ở phía Server, sau khi xử ly request thi response body

ban đầu ở dang ban rõ sẽ được ma hóa bằng khóa bi mật

AES được sinh bởi máy chủ web.

(2)Khóa bí mật AES của Server được mã hóa bằng khóa

công khai RSA của phía Client Khóa công khai RSA này

là khóa được phía Client gửi thông qua request body.

(3)Khi đó response body được gửi tới phía Client sẽ bao

gồm khóa AES được mã hóa và response body gốc được

mã hóa.

(4)Phía Client sau khi nhận được response sẽ sử dụng khóa

bí mật RSA để giải mã và có được khóa bí mật AES của

Server.

(5) Client dùng khóa AES này để giải mã phần còn lại trong

response body và có được response body ở dạng bản rõ.

2.2 Quy trình kiểm thử xâm nhập website có mã hóa

Khi thực hiên kiểm thử xâm nhập web, người kiểm thử cầnthực hiên sửa đổi các tham số được truyền trong request bodytrước khi gửi đến máy chủ ứng dụng web Từ đó, người kiểm thử

có thé dựa vào viéc quan sát response body do webserver trả

về để biết được chức năng hay API đó có thực sự tồn tại lỗ hổng

hay không Nhưng đối với những website có mã hóa, do request

body đã được mã hóa trước khi gửi đến server, người kiểm thử

sẽ không thể thực hiên dò quét hay tấn công nếu không có đượcrequest body ở dạng bản rõ Vì vậy, đồ án đưa ra môt quy trìnhkiểm thử xâm nhập cải tiến để người kiểm thử có thể thực hiênkiểm thử những website có mã hóa này Quy trình kiểm thử cảitiến sẽ thực hiên theo 6 giai đoạn tương tự với quy trình kiểm

thử thông thường:

- Giai đoạn 1: Khảo sát, thu thập thông tin về mục tiêu

- Giai đoạn 2: Dò quét điểm yếu

- Giai đoạn 3: Xác minh lỗ hổng và tấn công kiểm thử

- Giai đoạn 4: Đánh giá mức đô nguy hiểm các lỗ hổng

- Giai đoạn 5: Báo cáo và khuyến nghị

Trang 35

- Giai đoạn 6: Tái đánh gia

Tuy nhiên, trong các giai đoạn 1, 2, 3 do các request body trong API của website đã bị mã hóa nên các bước, cách thức thực hiên

kiểm thử trong ba giai đoạn này sẽ khác so với quy trình kiểm

thử thông thường.

Trong giai đoạn đầu tiên - Khảo sát, thu thập thôngtin về mục tiêu, ngoài những thông tin về phiên bản hê điều

hành webserver, ngôn ngữ của ứng dụng web, tên miền thì

người kiểm thử cần thực hiên thu thập thêm thông tin về thư

viên mã hóa, thuật toán mã hóa - giải mã, các khóa mã hóa và các request body ở dạng bản rõ mà ứng dụng web đó xử lý Đây

là những thông tin quan trọng, làm tiền dé giúp người kiểm thử

có thể thực hiên tiếp các giai đoạn còn lại trong quy trình kiểm

thử xâm nhập website có mã hóa.

Do các request body được mã hóa trước khi gửi đến

webserver nên có thể suy luận rằng: “việc mã hóa được thực

hiện bởi một hàm mã hóa JavaScript trên trình duyệt (phía

client) rồi gửi request tới server” Mỗi khi trình duyêt truy cậpđến trang web, phía server sẽ trả về cho trình duyêt các fileJavaScript để thực hiên viéc xử lý mã hóa - giải mã trên trình

duyêt Do vậy, để thu thập được các thông tin liên quan về mã

hóa như thư viên, thuật toán mã hóa, khóa mã hóa và request

body ở dạng bản rõ, người kiểm thử sẽ thực hiên theo các bước

sau:

- Bước 1.1: Đọc source code javascript của trang

web

Người kiểm thử sẽ thực hiên đọc source code JavaScript

của trang web trên trình duyêt và tìm kiếm các hàm mã

hóa, giải mã theo các từ khóa như encrypt, decrypt,

AES, RSA, encode để tìm vị trí của hàm mã hóa - giải

mã, thông tin về thuật toán mã hóa và khóa mã hóa mà

ứng dụng sử dụng.

Trang 36

GO Inspector Console © Debugger NN Network {} Style Editor (2) Performance 4 Memory € Storage Ff Accessibility 888 Application ú

Sources Outline Search [8] {) main-es2015.6 js?v=2.5.0.27 X main-es2015.6 js?v=2.5.0.27 143-es2015.f6 69cd1309985./s » BỊ

»›

0 = a.pki.publickeyFromPem(a.util.decode64(this.defaultPublickey)).encrypt(a.util.encode64(n));

return {

d: i.toString('base64"), k: a.util.encode64(o)

Hình 2.14 Source code JavaScript của website ngân hàng BIDV

- Bước 1.2: Đánh các breakpoint trên source code

JavaScript và chạy debug trên trình duyệt

Breakpoint là điểm đánh dấu tại các điểm, các dòng cụthể trong mã nguồn giúp dừng thực thi mã và người kiểmthử có thể kiểm tra trạng thái của mã tại vị trí đó và tiếp

tục thực thi từng dòng mã Trong hàm mã hóa request

body, người kiểm thử thực hiên đánh các breakpoint tại

các dòng code trên file script xử lý đầu vào để bật chế

đô debug trên trình duyệt Việc chạy debug sẽ giúp

người kiểm thử biết được đầu vào của hàm mã hóa ở

dạng bản rõ là gì, đầu ra là gì, cách xử lý thuật toán của

hàm.

Trang 37

[4] {}) main-es2015.6 js?v=2.5.027 X main-es2015.6 js?v=2.5.0.27 143-es2015.f6 69cd1309985.Js » BỊ]

encrypt(1) { try {

4507 const n = a.random.getBytesSync(32), n: "¿Í»ù¡Z\u9816}P\u9984*\u99844B\u9982\09817k+\u809e01u988f*Ï\u9886ÄX\U8985\u8989566£

4508 u = a.random.getBytesSync(16); u: "\u@@1d2« p\uee92\uee05+y6 'Ũuoú\u@ðec”

Hình 2.15 Request body ở dạng bản rõ khi chạy chế độ debug

- Bước 1.3: Tìm kiếm các thư viện mã hóa được sử

a2

dụng và viết lại script mã hóa - giải mã

Sau khi đã đọc và hiểu rõ luồng xử lý của hàm mã hóa,người kiểm thử cần tìm hiểu về thư viên mã hóa mà ứng

dụng sử dụng và tên của gói thư viên và thư viên thực

thi trên môi trường nào Do viêc mã hóa chủ yếu dựatrên sự kết hợp giữa thuật toán RSA và AES nên các thư

viên và script mã hóa sẽ thường chỉ thực thi được với

môi trường runtime của NodeJS Vì vậy người kiểm thử

cần tải về node_modules tương ứng với các thư viên mãhóa và sau đó thực hiên viết lại script mã hóa - giải mã

để phục vụ cho các giai đoạn kiểm thử sau này

Trong giai đoạn thứ 2 - Dò quét điểm yếu đối với

website thông thường, khi người kiểm thử sử dụng các công cụ

rà quét điểm yếu như Acunetix hay Nesuss thì các công cụ này

sẽ tự đông sửa đổi, chèn các đoạn payload khai thác vào trong

các param hoặc body của request sau đó gửi các request này

tới ứng dụng và dựa vào request body để xác định điểm yếu, lỗ

hổng Đối với website có mã hóa, các công cụ rà quét sẽ khôngthể xác định được vị trí, tham số để sửa đổi hoặc chèn payload

vào request Ứng dụng web sẽ không thể giải mã, xử lý và phản

hổi các request rà quét này do các giá trị trong request body

Trang 38

không được thực hiên mã hóa đúng cách Do đó, người kiểm thửkhông thể sử dụng các công cụ rà quét này để dò quét và pháthiên các lỗ hổng bảo mật Phương pháp thực hiên dò quét cácwebsite có mã hóa sẽ được đề cập đến trong nôi dung phần 2.3.Các phương pháp kiểm thử website có mã hóa

Trong giai đoạn 3 - Xác minh và tấn công kiểm thử,

người kiểm thử có thể thực hiên khai thác, kiểm thử các tínhnăng tại giao diên web trên để xác định tính năng đó có tồn tại

lỗ hổng bảo mật hay không Trong môt số trường hợp, ngườikiểm thử không thể khai thác lỗ hổng trên giao diên web nhưng

khi tấn công khai thác qua API thì có thể tấn công thành công lỗ

hổng Ví dụ đối với lỗi kiểm tra dữ liêu đầu vào, trên giao diênweb ứng dụng không cho phép người dùng nhập số âm nhưngkhi gọi qua API thì người dùng có thể nhập được số âm Vì vậykhi tấn công kiểm thử đối với web mã hóa, để có thể xác định lỗhổng thông qua API, người kiểm thử cần thực hiên các bước sau:

- Bước 3.1: Thực hiện sửa đổi, chèn payload vào

request body ở dạng bản rõ

- Bước 3.2: Mã hóa request body và gửi request tới

server

- Bước 3.3: Giải mã response body trả về từ server

- Bước 3.4: Quan sát response body bản rõ và phân

tích, xác định lỗ hổng

(Thông tin về thuật toán và script mã hóa - giải mã,

request body ở dạng bản rõ đã được thu thập trong Giai

đoạn Khai thác, thu thập thông tin về mục tiêu)

Đối với các giai đoạn 4, 5, 6 là giai đoạn hậu kiểm thử xâmnhập, người kiểm thử có thể thực hiên, triển khai các bước

tương tự như trong quy trình kiểm thử xâm nhập website thông

thường.

2.3 Các phương pháp kiểm thử website có mã hóa

Như đã đề cập trong quy trình kiểm thử xâm nhập cải tiến,

người kiểm thử sẽ không thể thực hiên rà quét hoặc tấn công lỗhổng trên website có mã hóa theo cách thông thường mà phải

kết hợp với môt số phương pháp kiểm thử web mã hóa khác

Trang 39

Hiên nay có 2 phương pháp phổ biến được sử dụng là phương

pháp thủ công với công cụ BurpSuite và phương pháp sử dụng ứng dụng Postman.

2.3.1 Phương pháp thủ công với công cụ Burp Suite

Sau giai đoạn Khảo sát, thu thập thông tin về mục tiêu,người kiểm thử đã viết được các đoạn script để thực hiên mã

hóa request body và giải mã response body Đối với phương

pháp này, người kiểm thử sẽ sử dụng công cụ Burp Suite để

thực hiên kiểm thử kết hợp với viêc thực hiên thủ công từng

bước chạy script mã hóa, giải mã trong giai đoạn Xác minh và

tấn công kiểm thử của quy trình kiểm thử xâm nhập cải tiến

Phương pháp này chủ yếu được sử dụng để tấn công khai thác,chưa phù hợp để rà quét lỗ hổng ứng dụng do không thể sửa

đổi, mã hóa - giải mã request hàng loạt

2.3.1.1 Giới thiệu về công cụ Burp SuiteBurp Suite là môt công cụ kiểm thử bảo mật phần mềm,phát triển bởi PortSwigger, được sử dụng rông rãi trong lĩnh vựckiểm thử bảo mật ứng dụng web Burp Suite cung cấp nhiều

tính năng mạnh mẽ giúp phân tích và tấn công khai thác lỗ

hổng trên ứng dụng web Công cụ này có thể được sử dụng đểthực hiên các hoạt đông như kiểm thử lỗ hổng bảo mật, rà quét,phát hiên và khai thác các lỗ hổng, theo dõi và ghi lại các yêu

cầu và phản hồi HTTP/S

Các tính năng chính của Burp Suite bao gồm:

- Proxy: cho phép người dùng chuyển hướng các yêu cầu

HTTP/S giữa trình duyêt và máy chủ ứng dụng để kiểm

tra và chỉnh sửa dữ liêu trước khi gửi đi Điều này giúp

phát hiên và khai thác các lỗ hổng bảo mật

- Scanner: công cụ Scanner của Burp Suite có thé tự đông

rà quét, phát hiên các lỗ hổng bảo mật trong ứng dụngweb, bao gồm các lỗ hổng phổ biến như XSS (Cross-Site

Scripting), SQL Injection, và CSRF (Cross-Site Request

Forgery).

- Intruder: tính năng này giúp thực hiên các cuôc tấn công

được tùy chỉnh trên các yêu cầu HTTP theo các kịch bản

Trang 40

khác nhau như tấn công Brute force theo từ điển, DoS

để kiểm tra tính bảo mật của ứng dụng

- Repeater: cho phép người kiểm thử tái tạo các yêu cầu

HTTP trước đó và thay đổi dữ liêu để thử nghiêm và

kiểm tra tác đông của các thay đổi này đến ứng dụng

- Decoder: gồm các công cụ giải mã để xem các thông tin

bảo mật đã được mã hóa, như Base64, URL-encoded,

HTML encoded và nhiều kiểu mã hóa khác

2.3.1.2 Thực hiện kiểm thử

Bước 3.1: Thực hiện sửa đổi, chèn payload vào

request body dạng bản rõ

Người kiểm thử thực hiên sửa đổi các trường của request

body ở dạng bản rõ dưới dạng 1 đối tượng JSON Trong requestbody có chứa môt tham số clientPubKey là khóa công khai RSA,

server sử dụng khóa này để mã hóa trong response trả về cho

client Phía người kiểm thử sẽ sử dụng khóa bí mật RSA để giải

mã response body được trả về Do vậy, người kiểm thử cần thực

hiên tạo 1 cặp khóa bất đối xứng RSA

1024 v Generate key pair

Private key Public key

-BEGIN RSA PRIVATE KEY = nn BEGIN PUBLIC

KEY -MITChiwIBAAKBgQDEc4MYex4vr72ieV2zCr2w7H4z3cLADIMxsOG1w6VUSC7Xj58C MIGFMAQGCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDECAMYex4vr72ieV2zCr2w7Haz

3c1ADTMxs@G1w6VUSC7Xj58CMw@UnBLiiTuNx3H/STDJ1VHhqg2k40dnqu13ChLJs

'VnR7121iTrE+oxJiYrBE1etcX3Z2Dkoaxk1tCAB28XGNFLGqUYdNsFJEZukK1h/p ALq1FrL8mkXeY@OtKQIDAQAB

END PUBLIC KEY.

nh END RSA PRIVATE

KEY -Hình 2.16 Khởi tạo cặp khóa bất đối xứng RSA

Khóa RSA công khai vừa tạo sẽ được truyền vào trong

request body Với request đăng nhập trên website, request

body sẽ chứa các tham số bắt buôc như tài khoản (user), mật

khẩu (pin), mã captcha, captcha token Người kiểm thử sẽ thực

hiên thay đổi giá trị của các tham số này để thực hiên tấn công

Tiêu đề	Nghiên cứu về kiểm thử xâm nhập trên website có mã hóa
Tác giả	Tran Anh Đức
Người hướng dẫn	ThS. Ninh Thị Thu Trang
Trường học	Viện Công Nghệ Bưu Chính Viễn Thông
Chuyên ngành	An Toàn Thông Tin
Thể loại	Đồ án tốt nghiệp
Năm xuất bản	2024
Thành phố	Hà Nội

Định dạng
Số trang	83
Dung lượng	26,28 MB