BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT TP HỒ CHÍ MINH

KHOA KINH TẾ
------- c&d -------

TIỂU LUẬN
MÔN: BẢO MẬT THƯƠNG MẠI ĐIỆN TỬ
ĐỀ TÀI
CROSS SITE REQUEST FORGERY

Giảng viên hướng dẫn :Th.S Trần Kim Toại

Thực hiện: Nhóm 10
Lớp: ECOS431508_22_2_02
Khóa: 2020-2024

Thành Phố Hồ Chí Minh, tháng 3 năm 2023

 DANH SÁCH THÀNH VIÊN THAM GIA

STT Tên MSSV Tỉ lệ hoàn thành

1 Cao Phúc Hậu 20126112 100%
2 Hồ Ngọc Diễm Mi 20126146 100%
3 Nguyễn Thị Thu Hiền 20126115 100%
4 Hồ Mạnh Tuấn 20126211 100%
5 Phạm Hoàng Tuấn 20126212 100%

NHẬN XÉT CỦA GIÁO VIÊN

….
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………………………………………………………………………………
………………………………….

Ngày…tháng…năm…

Giáo viên hướng dẫn

KẾ HOẠCH THỰC HIỆN DỰ ÁN

1
ĐỀ TÀI: Cross Site Request ForgeryFile
Tuần Ngày Nội dung
1 (27/02/2023 - 5/03/2023) Nghiên cứu setup Lab

2 (6/03/2023 - 12/03/2023) Web Security & Nghiên cứu Cross-Site

Request Forgery

3 (13/03/2023 - 19/03/2023) Thực hiện các task của Cross-Site

Request Forgery
4 (20/03/2023 - 26/03/2023) Hoàn thành bản word và powerpoint

2
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
THÀNH PHỐ HỒ CHÍ MINH Độc lập - Tự do - Hạnh phúc
KHOA KINH TẾ

TP. Hồ Chí Minh, ngày 27 tháng 02 năm 2023

BIÊN BẢN HỌP NHÓM

(Buổi họp lần thứ 1)
Tên đề tài Cross-Site Request Forgery
Người hướng dẫn ThS. Trần Kim Địa Trường ĐH Sư phạm Kỹ thuật TP
Toại điểm Hồ Chí Minh
1. Mục tiêu cuộc họp
Set up the SEED VM and set up the SEED Labs 2.0
2. Thành viên
Họ và tên MSSV E-MAIL
Cao Phúc Hậu 20126112 20126112@student.hcmute.edu.vn
Hồ Ngọc Diễm Mi 20126146 20126146@student.hcmute.edu.vn
Nguyễn Thị Thu Hiền 20126115 20126115@student.hcmute.edu.vn
Hồ Mạnh Tuấn 20126211 20126211@student.hcmute.edu.vn
Phạm Hoàng Tuấn 20126212 20126212@student.hcmute.edu.vn
3. Tóm tắt quá trình của cuộc họp
Chủ đề Người đưa ra ý kiến
Set up the SEED VM and set up the SEED Hồ Mạnh Tuấn
Labs 2.0 Nguyễn Thị Thu Hiền
Nghiên cứu cài đặt Lab Hồ Ngọc Diễm Mi
Cao Phúc Hậu
Phân công trả lời các câu hỏi của Web Phạm Hoàng Tuấn
Security

Qua buổi làm việc đã thống nhất được cách làm việc, những mục tiêu đặt ra. Tìm hiểu
được sơ bộ được đề tài từ đó triển khai phân công công việc cho từng cá nhân, từ đó tạo
tiền đề cho các cuộc họp lần sau sẽ đi vào phân tích từng chi tiết của từng người.

3
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
THÀNH PHỐ HỒ CHÍ MINH Độc lập - Tự do - Hạnh phúc
KHOA KINH TẾ

TP. Hồ Chí Minh, ngày 6 tháng 03 năm 2023

BIÊN BẢN HỌP NHÓM NGÀY

(Buổi họp lần thứ 2)

Tên đề tài Cross-Site Request Forgery

Người hướng dẫn ThS. Trần Kim Địa Trường ĐH Sư phạm Kỹ thuật TP
Toại điểm Hồ Chí Minh
1. Mục tiêu cuộc họp
Hoàn thành Web Security
2. Thành viên
Họ và tên MSSV E-MAIL
Cao Phúc Hậu 20126112 20126112@student.hcmute.edu.vn
Hồ Ngọc Diễm Mi 20126146 20126146@student.hcmute.edu.vn
Nguyễn Thị Thu Hiền 20126115 20126115@student.hcmute.edu.vn
Hồ Mạnh Tuấn 20126211 20126211@student.hcmute.edu.vn
Phạm Hoàng Tuấn 20126212 20126212@student.hcmute.edu.vn
3. Tóm tắt quá trình của cuộc họp
Chủ đề Người đưa ra ý kiến
Nghiên cứu Cross-Site Request Forgery Hồ Mạnh Tuấn
Cao Phúc Hậu
Nguyễn Thị Thu Hiền
Phân công trả lời các câu hỏi ở các task Hồ Ngọc Diễm Mi

Kiểm tra lại các câu trả lời phần Web Phạm Hoàng Tuấn
Security
Làm powerpoint Web Security Tất cả thành viên

Nghiên cứu chi tiết chủ đề, tổng quát lại những gì đã làm được, và tiến hành bắt tay vào
chuẩn bị cho báo cáo tiến độ.
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
THÀNH PHỐ HỒ CHÍ MINH Độc lập - Tự do - Hạnh phúc
KHOA KINH TẾ

TP. Hồ Chí Minh, ngày 13 tháng 03 năm 2023

BIÊN BẢN HỌP NHÓM NGÀY

(Buổi họp lần thứ 3)
Tên đề tài Cross-Site Request Forgery
Người hướng dẫn ThS. Trần Kim Địa Trường ĐH Sư phạm Kỹ thuật TP
Toại điểm Hồ Chí Minh
1. Mục tiêu cuộc họp
Chạy từng task của đề tài Cross-Site Request Forgery
2. Thành viên
Họ và tên MSSV E-MAIL
Cao Phúc Hậu 20126112 20126112@student.hcmute.edu.vn
Hồ Ngọc Diễm Mi 20126146 20126146@student.hcmute.edu.vn
Nguyễn Thị Thu Hiền 20126115 20126115@student.hcmute.edu.vn
Hồ Mạnh Tuấn 20126211 20126211@student.hcmute.edu.vn
Phạm Hoàng Tuấn 20126212 20126212@student.hcmute.edu.vn
3. Tóm tắt quá trình của cuộc họp
Chủ đề Người đưa ra ý kiến
Chạy thử các task Hồ Mạnh Tuấn
Nguyễn Thị Thu Hiền
Hoàn thành các câu hỏi ở từng task Hồ Ngọc Diễm Mi
Cao Phúc Hậu
Phạm Hoàng Tuấn

Done lại những gì đã làm và tiến hành chạy lại các task nhằm đảm bảo các thành viên đều
nằm được nội dung của cuộc tấn công chéo Csrf
TRƯỜNG ĐẠI HỌC SƯ PHẠM KỸ THUẬT CỘNG HOÀ XÃ HỘI CHỦ NGHĨA VIỆT NAM
THÀNH PHỐ HỒ CHÍ MINH Độc lập - Tự do - Hạnh phúc
KHOA KINH TẾ

TP. Hồ Chí Minh, ngày 20 tháng 03 năm 2023

BIÊN BẢN HỌP NHÓM NGÀY

(Buổi họp lần thứ 4)
Tên đề tài Cross-Site Request Forgery
Người hướng dẫn ThS. Trần Kim Địa Trường ĐH Sư phạm Kỹ thuật TP
Toại điểm Hồ Chí Minh
1. Mục tiêu cuộc họp
Hoàn thành đề tài Cross-Site Request Forgery
2. Thành viên
Họ và tên MSSV E-MAIL
Cao Phúc Hậu 20126112 20126112@student.hcmute.edu.vn
Hồ Ngọc Diễm Mi 20126146 20126146@student.hcmute.edu.vn
Nguyễn Thị Thu Hiền 20126115 20126115@student.hcmute.edu.vn
Hồ Mạnh Tuấn 20126211 20126211@student.hcmute.edu.vn
Phạm Hoàng Tuấn 20126212 20126212@student.hcmute.edu.vn
3. Tóm tắt quá trình của cuộc họp
Chủ đề Người đưa ra ý kiến
Hoàn thành bản powerpoint Tất cả thành viên
Quay video từng task, làm sơ đồ khối Hồ Ngọc Diễm Mi
Cao Phúc Hậu
Hồ Mạnh Tuấn
Hoàn thành bản word Phạm Hoàng Tuấn
Nguyễn Thị Thu Hiền

Hoàn thiện bàn tiểu luận, tổng kết lại các kiến thức đã học, qua phòng thi nhiệm lab Cross-
Site Request Forgery hiểu được tấn công chéo là gì? Cách thức vận hành cũng như cách
khắc phục tấn công. nắm được các kiến thức. Trong quá trình nghiên cứu đề tài, nhóm đã
tiếp cận được rất nhiều kiến thức mới vừa lý thuyết vừa thực tiễn. Với những kiến thức về
khoa học, công nghệ, kỹ thuật số hay cả những kỹ năng mềm đều được cải thiện như khả
năng thuyết trình, tổng hợp thông tin, hệ thống kiến thức,... Sau hơn 1 tháng thực hiện đề
tài cộng với kiến thức học được trên lớp từ thầy cũng như các nhóm, với những mục tiêu đề
ra, nhóm đã hoàn thành với hiệu quả 90% so với mục tiêu ban đầu.
10% còn lại là những kiến thức đang trong quá trình tìm hiểu, chúng em sẽ bổ sung sớm
trong tương lai.

MỤC LỤC
A. PHẦN CHUNG: WEB SECURITY.......................................................................1
Câu 1: What are the main differences between the GET and POST requests?.......1
Câu 2: What are the main purposes of HTTP cookies?...........................................2
Câu 3: Please explain how cookies can be used to track users...............................3
Câu 4: Please explain why disabling third-part cookies can help prevent tracking.4
Câu 5: Can JavaScript code access the user’s fifiles? If not, how can we upload fifiles
to web servers?.........................................................................................................4
Câu 6: Why Ajax and normal HTTP have different policy?...................................5
Câu 7: Why is the same-origin policy required for Ajax request?..........................5
Câu 8. If web server A wants to allow a page from web server B to get nhits data via
the Aja request, who should set up the corresponding policy and what policy?.....6
Câu 9. Please describe the cable haunt attack? If the server is not a WebSocket server,
is the attack still possible?........................................................................................6
B. PHẦN RIÊNG...........................................................................................................8
PHẦN 1: CROSS SITE REQUEST FORGERY....................................................8
Câu 1: Giải thích tại sao cookie cùng trang web có thể giúp ngăn chặn các cuộc tấn
công CSRF?.............................................................................................................9
Câu 2: Giải thích cách một trang web có thể sử dụng mã thông báo bí mật để ngăn chặn
các cuộc tấn công CSRF và tại sao nó hoạt động?................................................11
Câu 3: Ngày nay, hầu hết các trang web đều sử dụng HTTPS thay vì HTTP. Chúng ta
vẫn cần phải lo lắng về các cuộc tấn công CSRF?................................................11
Câu 4: Sử dụng LiveHTTPHeader, chúng tôi phát hiện ra rằng yêu cầu GET sau đây
được sử dụng để gửi yêu cầu HTTP tới www.example.com để xóa trang do người dùng
sở hữu (chỉ chủ sở hữu của trang mới có thể xóa trang)........................................12
Câu 5: Sử dụng LiveHTTPHeader, chúng tôi phát hiện ra rằng yêu cầu POST sau được
sử dụng để gửi yêu cầu HTTP tới www.example.com để xóa trang do người dùng sở
hữu (chỉ chủ sở hữu của trang mới có thể xóa trang)............................................14
Câu 6: Yêu cầu HTTP giả mạo chống lại Elgg trong chương này cần id người dùng
(hướng dẫn) của Bobby để hoạt động bình thường. Nếu Alice nhắm mục tiêu cụ thể vào
Bobby, trước cuộc tấn công, cô ấy cần tìm cách lấy id người dùng của Bobby. Alice
không biết mật khẩu Elgg của Bobby nên cô ấy không thể đăng nhập vào tài khoản của
Bobby để lấy thông tin. Vui lòng mô tả cách Alice có thể tìm ra id người dùng của
Bobby.....................................................................................................................16
Câu 7: Trong một yêu cầu, có một id người dùng, là một số ngẫu nhiên do máy chủ tạo
ra. Thông tin ID có thể được tìm thấy từ trang của người dùng từ máy chủ. Nếu kẻ tấn
công không biết ID người dùng này, anh ta/cô ta vẫn có thể khởi động một cuộc tấn
công CSRF vào dịch vụ này chứ?..........................................................................16
Câu 8: Nếu Alice muốn khởi động cuộc tấn công vào bất kỳ ai truy cập trang web độc
hại của cô ấy. Trong trường hợp này, cô ấy không biết ai đang truy cập trang web trước
đó. (1) Cô ấy vẫn có thể khởi động một cuộc tấn công CSRF để sửa đổi hồ sơ Elgg của
nạn nhân chứ? Vui lòng giải thích. (2) Cô ấy có thể khởi động một cuộc tấn công CSRF
để thêm cô ấy vào danh sách bạn bè của nạn nhân không? Vui lòng giải thích....17
Câu 9: Khi một trang web gửi yêu cầu đến máy chủ của nó, ID phiên luôn được đính
kèm trong phần cookie của tiêu đề HTTP. Một ứng dụng web yêu cầu tất cả các yêu
cầu từ trang riêng của nó phải đính kèm ID phiên trong phần dữ liệu của nó (đối với các
yêu cầu GET, ID phiên được đính kèm trong URL, trong khi đối với các yêu cầu
POST, ID phiên được bao gồm trong tải trọng). Điều này nghe có vẻ dư thừa vì ID
phiên đã được bao gồm trong yêu cầu. Tuy nhiên, bằng cách kiểm tra xem một yêu cầu
có ID phiên trong phần dữ liệu của nó hay không, máy chủ web có thể biết liệu một yêu
cầu có phải là yêu cầu trên nhiều trang web hay không. Hãy giải thích tại sao?...18
Câu 10. Các trình duyệt có biết liệu một yêu cầu HTTP có phải là trang chéo hay
không?....................................................................................................................19
Câu 11: Các máy chủ có biết liệu một yêu cầu HTTP có phải là trang chéo hay không?
................................................................................................................................19
Câu 12: Tại sao máy chủ web không thể sử dụng tiêu đề người giới thiệu để cho biết
liệu yêu cầu có phải là trang chéo hay không?......................................................20
Câu 13: Tại sao điều quan trọng là máy chủ phải biết liệu yêu cầu có phải là trang web
chéo hay không?....................................................................................................21
Câu 14: Chúng tôi có thể yêu cầu các trình duyệt không đính kèm bất kỳ cookie nào
cho các yêu cầu trên nhiều trang không?...............................................................21
Câu 15: Nếu một trang từ www.example.com chứa iframe, bên trong đó trang facebook
được hiển thị. Nếu một yêu cầu được gửi từ bên trong iframe, thì yêu cầu đó có được
 coi là yêu cầu trên nhiều trang web hay không? Nếu không, làm thế nào có thể được
bảo đảm này?.........................................................................................................22
PHẦN 2: THỰC HÀNH 5 TASK...........................................................................23
2.1 Task 1: Observing HTTP Request...................................................................23
2.2 Task 2: CSRF Attack using GET Request.......................................................28
2.3 Task 3: CSRF Attack using POST Request.....................................................36
2.4 Task 4: Enabling Elgg’s Countermeasure........................................................47
2.5 Task 5: Experimenting with the SameSite Cookie Method.............................49
TÀI LIỆU THAM KHẢO..........................................................................................55
 A. PHẦN CHUNG: WEB SECURITY

Câu 1: What are the main differences between the GET and POST requests?
GET và POST là hai phương thức yêu cầu HTTP được sử dụng phổ biến nhất. Mặc dù
chúng được gọi là các phương thức HTTP, nhưng cả GET và POST cũng được sử dụng
trong HTTPS. Thông thường, các yêu cầu GET được sử dụng để yêu cầu các trang web
trong khi POST được sử dụng để gửi dữ liệu đến máy chủ web, chẳng hạn như thông qua
biểu mẫu web.

Một trong những điểm khác biệt quan trọng là bất kỳ tham số nào có trong yêu cầu
GET đều được bao gồm trong chính URL, trong khi tham số trong yêu cầu POST là một
phần của nội dung yêu cầu.

Các điểm khác biệt khác giữa GET và POST bao gồm thực tế là các yêu cầu GET có
thể được lưu vào bộ đệm của trình duyệt hoặc bộ nhớ cache của bên thứ ba, các yêu cầu
GET được bao gồm trong lịch sử trình duyệt và có thể được đánh dấu trang. Các yêu cầu
POST trong so sánh không bao giờ được lưu vào bộ nhớ cache, không được lưu vào lịch
sử trình duyệt và không thể được đánh dấu trang.

Sự khác nhau giữa phương thức GET và POST trong API:

Get Post

.
Dữ liệu hiển thị trên URL yêu cầu Dữ liệu không hiển thị trong yêu cầu để
GET. bạn có thể chuyển dữ liệu nhạy cảm như
mật khẩu, v.v.

Không có giới hạn về độ dài dữ liệu trong

Độ dài dữ liệu phải được duy trì để yêu cầu POST.
tránh vượt quá giới hạn độ dài URL.

1
 Nó chỉ hỗ trợ các kiểu dữ liệu chuỗi Nó hỗ trợ các loại dữ liệu khác nhau
như chuỗi, boolean, số nguyên, v.v.

Nhận yêu cầu có thể được đánh dấu Không thể đánh dấu yêu cầu bài viết

Get rất đơn giản để sử dụng vì bản Post yêu cầu thông tin tiêu đề, nội dung,
chất của nó là chỉ thêm dữ liệu vào v.v. nên khó sử dụng so với Nhận yêu
URL. cầu.

POST requests yêu cầu không thể

Get requests yêu cầu có thể được lưu
được lưu trữ.
trữ.

Câu 2: What are the main purposes of HTTP cookies?

Theo MDN, HTTP Cookie được định nghĩa như sau:
HTTP Cookie (web cookie, browser cookie) là dữ liệu được gửi từ server tới trình
duyệt của người dùng. Trình duyệt sẽ lưu dữ liệu cookie này và gửi lại theo mỗi HTTP
request về cho cù8ng server đó. Về cơ bản, cookie dùng để nói cho server biết các
request đến từ một trình duyệt, ví dụ để giữ lại trạng thái đăng nhập...
Đúng vậy, HTTP là stateless. Do đó, mọi request đến server đều giống nhau. Vì vậy,
server không thể phân biệt được request được gửi đến là từ một client đã thực hiện
request trước đó, đã đăng nhập,... hay từ một client mới.
Vì vậy, HTTP Cookie đã ra đời để giải quyết vấn đề này.
Các tác dụng của cookie
Các tác dụng chính của cookie là:
 Quản lý phiên: Cookie có thể được sử dụng để theo dõi phiên của người dùng trên
một trang web.

Ví dụ: khi người dùng đăng nhập vào một trang web, cookie có thể được tạo để
ghi nhớ thông tin đăng nhập của họ, vì vậy họ không phải nhập lại mỗi khi truy
cập trang web.

2
  Lưu thông tin cài đặt của người dùng: theme (dark mode hay light mode), ngôn
ngữ (tiếng việt, tiếng anh), thông tin username/email trong mục bình luận,...
 Theo dõi và phân tích hành vi người dùng: các trang đã truy cập, truy cập bao
nhiêu lần, thời gian ở lại mỗi trang là bao nhiêu, dữ liệu này có thể được sử dụng
để cải thiện trải nghiệm người dùng và tối ưu hóa hiệu suất của trang web.
 Bảo mật: Cookie có thể được sử dụng để giúp bảo vệ chống lại hoạt động gian lận,
chẳng hạn như bằng cách phát hiện và ngăn chặn nhiều lần đăng nhập từ các thiết
bị khác nhau.
 Quảng cáo: Cookies có thể được sử dụng để theo dõi hành vi duyệt web của người
dùng và phục vụ họ quảng cáo được nhắm mục tiêu dựa trên sở thích của họ.

Câu 3: Please explain how cookies can be used to track users.

Khi bất kỳ ai truy cập trang web hoặc thực hiện bất kỳ hành động nào trên trang web,
một tệp văn bản nhỏ sẽ được chuyển từ trang web và được lưu trữ trên trình duyệt web
của khách truy cập. Khi khách truy cập quay lại trang web lần nữa, máy chủ có thể đọc
cookie được lưu trữ trong trình duyệt của họ và nhớ lại thông tin về khách truy cập,
chẳng hạn như các hoạt động duyệt trước đó của họ trên trang web.

Cookie có thể được sử dụng để theo dõi người dùng theo nhiều cách. Dưới đây là một
số ví dụ:

 Cookie liên tục: Khi một trang web đặt cookie liên tục, cookie này vẫn còn trên
thiết bị của người dùng ngay cả sau khi họ đóng trình duyệt. Điều này có nghĩa là
trang web có thể tiếp tục theo dõi hoạt động của người dùng trong nhiều phiên
duyệt web. Ví dụ: một trang web có thể sử dụng cookie liên tục để ghi nhớ thông
tin đăng nhập hoặc tùy chọn của người dùng.
 Cookie của bên thứ ba: Khi người dùng truy cập một trang web, trang web đó
cũng có thể đặt cookie từ các nhà quảng cáo hoặc nhà cung cấp phân tích bên thứ
ba. Những cookie này có thể được sử dụng để theo dõi hành vi duyệt web của
người dùng trên nhiều trang web và xây dựng hồ sơ về sở thích và hành vi của họ.
 Theo dõi trên nhiều trang web: Một số trang web sử dụng cookie để theo dõi
người dùng trên nhiều trang web. Ví dụ: trang web truyền thông xã hội có thể đặt
cookie khi người dùng nhấp vào liên kết đến trang web bên ngoài, cho phép họ
theo dõi hoạt động của người dùng trên trang web đó.
 Lấy dấu vân tay: Ngoài cookie, các trang web có thể sử dụng các phương pháp
khác để theo dõi người dùng, chẳng hạn như lấy dấu vân tay của trình duyệt. Điều
này liên quan đến việc thu thập thông tin về cấu hình trình duyệt và thiết bị của
người dùng (chẳng hạn như độ phân giải màn hình, plugin trình duyệt và phông

3
 chữ), có thể được sử dụng để tạo mã định danh duy nhất có thể được sử dụng để
theo dõi người dùng trên nhiều trang web.

Câu 4: Please explain why disabling third-part cookies can help prevent
tracking.
Cookie của bên thứ ba được tạo bởi một miền khác với miền mà người dùng đang
truy cập. Các nhà quảng cáo và nhà môi giới dữ liệu thường sử dụng cookie của bên thứ
ba để theo dõi người dùng trên các trang web khác nhau, cho phép họ thu thập thông tin
về hành vi và sở thích trực tuyến của người dùng. Loại theo dõi này có thể được sử dụng
để nhắm mục tiêu người dùng bằng quảng cáo được cá nhân hóa hoặc thậm chí để bán dữ
liệu của họ cho các công ty khác.
Vô hiệu hóa cookie của bên thứ ba có thể giúp ngăn chặn loại theo dõi này bằng cách
ngăn các công ty này thu thập dữ liệu về hành vi duyệt web của bạn trên các trang web
khác nhau. Khi cookie của bên thứ ba bị tắt, các trang web bạn truy cập chỉ có thể sử
dụng cookie dành riêng cho miền của họ, điều này hạn chế khả năng theo dõi bạn trên
web của họ.
Tuy nhiên, cần lưu ý rằng việc tắt cookie của bên thứ ba có thể không ngăn chặn hoàn
toàn tất cả các hình thức theo dõi trực tuyến. Một số công ty sử dụng các phương pháp
theo dõi thay thế, chẳng hạn như lấy dấu vân tay hoặc nhận dạng thiết bị, không dựa vào
cookie. Ngoài ra, cookie của bên thứ nhất vẫn có thể được sử dụng để theo dõi người
dùng trong một trang web hoặc dịch vụ.
Nhìn chung, vô hiệu hóa cookie của bên thứ ba là một trong số các bước có thể thực
hiện để giúp bảo vệ quyền riêng tư trực tuyến của bạn, nhưng đó không phải là giải pháp
hoàn hảo. Điều quan trọng là phải biết các phương pháp theo dõi khác có thể vẫn đang
được sử dụng và thực hiện các bước bổ sung, chẳng hạn như sử dụng VPN hoặc tiện ích
mở rộng trình duyệt tập trung vào quyền riêng tư, để nâng cao hơn nữa quyền riêng tư và
bảo mật trực tuyến của bạn.

Câu 5: Can JavaScript code access the user’s fifiles? If not, how can we
upload fifiles to web servers?
Mã JavaScript chạy trong trình duyệt web không có quyền truy cập trực tiếp vào tệp
của người dùng trên thiết bị cục bộ của họ. Đây là một biện pháp bảo mật để ngăn chặn
các trang web độc hại lấy cắp thông tin nhạy cảm từ máy tính của người dùng.

Để tải tệp lên máy chủ web, có thể sử dụng biểu mẫu web có phần tử <input
type="file">. Khi người dùng chọn một tệp bằng đầu vào tệp, dữ liệu tệp có thể được gửi
tới máy chủ như một phần của việc gửi biểu mẫu. Về phía máy chủ, dữ liệu tệp có thể
được xử lý và lưu trữ ở một vị trí mong muốn.

4
 Cũng có thể thực hiện tải lên tệp không đồng bộ bằng JavaScript và XMLHttpRequest
hoặc thư viện như jQuery, nhưng điều này vẫn không cho phép truy cập trực tiếp vào tệp
cục bộ của người dùng. Dữ liệu tệp phải được chọn thông qua đầu vào tệp và chuyển đến
mã JavaScript, mã này sau đó có thể gửi dữ liệu đến máy chủ bằng yêu cầu HTTP.

Câu 6: Why Ajax and normal HTTP have different policy?

Các yêu cầu Ajax (JavaScript và XML không đồng bộ) và HTTP thông thường (Giao
thức truyền siêu văn bản) có các chính sách khác nhau vì chúng được trình duyệt xử lý
khác nhau. Các yêu cầu HTTP thông thường thường được gửi dưới dạng tải lại toàn bộ
trang, trong đó toàn bộ trang được tải lại và hiển thị lại. Đây là thao tác chặn, nghĩa là
trình duyệt phải chờ phản hồi của máy chủ trước khi có thể hiển thị nội dung cập nhật.
Ngược lại, các yêu cầu Ajax được gửi dưới dạng các yêu cầu nền, nghĩa là chúng không
chặn trình duyệt. Trình duyệt có thể tiếp tục tương tác với người dùng trong khi yêu cầu
đang được xử lý và chỉ phần có liên quan của trang được cập nhật khi nhận được phản
hồi. Điều này cho phép trải nghiệm người dùng mượt mà và năng động hơn.

Các cơ chế xử lý khác nhau của Ajax và các yêu cầu HTTP thông thường cũng dẫn
đến các chính sách bảo mật khác nhau. Ví dụ: các yêu cầu HTTP thông thường phải tuân
theo chính sách cùng nguồn gốc, hạn chế quyền truy cập vào tài nguyên dựa trên nguồn
gốc của yêu cầu. Ngược lại, các yêu cầu Ajax có thể được gửi chéo nếu chúng được cấu
hình đúng với các tiêu đề thích hợp.

Câu 7: Why is the same-origin policy required for Ajax request?

Chính sách cùng nguồn gốc là một hạn chế bảo mật giới hạn khả năng truy cập tài
nguyên từ các miền khác nhau của một trang web. Chính sách này là bắt buộc đối với
các yêu cầu Ajax vì chính sách này giúp ngăn chặn các cuộc tấn công kịch bản chéo trang
(XSS). Bằng cách thực thi chính sách cùng nguồn gốc, trình duyệt đảm bảo rằng dữ liệu
nhạy cảm, chẳng hạn như thông tin xác thực của người dùng, không thể bị chặn và đánh
cắp bởi những kẻ độc hại có khả năng đưa các tập lệnh lừa đảo vào trang web. Điều này
giúp duy trì tính bảo mật và quyền riêng tư của người dùng và dữ liệu của họ.

Câu 8. If web server A wants to allow a page from web server B to get nhits
data via the Aja request, who should set up the corresponding policy and
what policy?
Máy chủ web A phải thiết lập một chính sách có tên là "Chia sẻ tài nguyên nguồn gốc
chéo (CORS)" để cho phép một trang từ máy chủ web B thực hiện yêu cầu Ajax đến máy
chủ web A. CORS là một cơ chế cung cấp một cách an toàn cho máy chủ để cấp quyền
truy cập vào tài nguyên của nó cho khách hàng từ một miền khác.
5
 Để thiết lập CORS trên máy chủ web A, máy chủ cần trả về các tiêu đề HTTP cụ thể
trong phản hồi của nó, chẳng hạn như.

Access-Control-Allow-Origin,

Access-Control-Allow-Methods,

Access-Control-Allow-Headers.

Các tiêu đề này chỉ định các miền được phép thực hiện các yêu cầu gốc chéo tới máy
chủ, các loại yêu cầu được phép (chẳng hạn như GET, POST, v.v.) và bất kỳ tiêu đề bổ
sung nào được phép trong yêu cầu.

Bằng cách thiết lập CORS trên máy chủ web A, máy chủ web B có thể tạo các yêu
cầu Ajax có nguồn gốc chéo tới máy chủ web A và trình duyệt sẽ cho phép các yêu cầu
được xử lý miễn là chúng tuân thủ chính sách được chỉ định trong tiêu đề CORS.

Câu 9. Please describe the cable haunt attack? If the server is not a
WebSocket server, is the attack still possible?
Cable Haunt được khai thác theo hai bước. Đầu tiên, quyền truy cập vào điểm cuối dễ
bị tổn thương có được thông qua một ứng dụng khách trên mạng cục bộ, chẳng hạn như
trình duyệt. Thứ hai, điểm cuối dễ bị tổn thương bị tấn công bằng một cuộc tấn công tràn
bộ đệm, cho phép kẻ tấn công kiểm soát modem.

Thứ nhất, truy cập điểm cuối

Điểm cuối, phục vụ một công cụ có tên là Spectrum Analyzer, sử dụng WebSocket để
giao tiếp với giao diện người dùng đồ họa được hiển thị trong trình duyệt. Trong khi
CORS sẽ hạn chế quyền truy cập vào một điểm cuối như vậy đối với các yêu cầu HTTP,
WebSocket không được bảo vệ bởi giao thức này. Do đó, tùy thuộc vào máy chủ để xác
minh các tham số yêu cầu có liên quan do trình duyệt thêm vào. Bởi vì các tham số này
không bao giờ được kiểm tra bởi modem cáp, WebSocket sẽ chấp nhận các yêu cầu do
javascript chạy trong trình duyệt thực hiện bất kể nguồn gốc, do đó cho phép kẻ tấn công
tiếp cận điểm cuối. Cần lưu ý rằng việc khai thác không bị giới hạn khi chạy trên trình
duyệt. Bất kỳ nơi nào mà mã đang chạy có thể tiếp cận IP trên mạng cục bộ, đều có thể
được sử dụng để khai thác Cable Haunt.

Thứ hai, kiểm soát

Khi đã đạt được WebSocket, lỗ hổng tràn bộ đệm có thể bị khai thác. Các yêu cầu
WebSocket được cung cấp dưới dạng JSON. Trình phân tích cú pháp diễn giải yêu cầu
JSON này, sẽ sao chép các tham số đầu vào vào bộ đệm, bất kể độ dài, cho phép ghi đè
các giá trị trên ngăn xếp. Trong số các giá trị này có các thanh ghi đã lưu, chẳng hạn như
6
bộ đếm chương trình và địa chỉ trả về. Với một thông báo được tạo cẩn thận, modem có
thể bị thao túng để thực thi mã tùy ý do kẻ tấn công từ xa chỉ định. Khi kẻ tấn công đã đạt
được quyền kiểm soát, nó có thể bị lạm dụng theo nhiều cách.

Không, cuộc tấn công không thể thực hiện được nếu máy chủ không phải là máy chủ
WebSocket, vì nó đặc biệt khai thác lỗ hổng trong quá trình triển khai WebSockets của
chipset modem cáp bị ảnh hưởng.

7
 B. PHẦN RIÊNG
PHẦN 1: CROSS SITE REQUEST FORGERY
1. Explain why the same-site cookie can help prevent CSRF attacks.
2. Explain how a website can use secret token to prevent CSRF attacks, and why
does itwork?
3. These days, most of the websites use HTTPS, instead of HTTP. Do we still need to
worry about CSRF attacks?
4. Using LiveHTTPHeader, we find out that the following GET request is used to
send an HTTP request to www.example.com to delete a page owned by a user (only
the owner of a page can delete the page).
http://www.example.com/delete.php?pageid=5
GET /delete.php?pageid=5
Host: www.example.com
...
Please construct a simple malicious web page, so when a victim visits this web page,
a
forged request will be launched against www.example.com to delete a page
belonging
to the user.
5. Using LiveHTTPHeader, we find out that the following POST request is used to
send an HTTP request to www.example.com to delete a page owned by a user (only
the owner of a page can delete the page).
http://www.example.com/delete.php
POST /delete.php HTTP/1.1
Host: www.example.com
...
Content-Length: 8
pageid=5
Please construct a simple malicious web page, so when a victim visits this web page,
a
forged request will be launched against www.example.com to delete a page
belonging
to the user.
6. The forged HTTP request against Elgg in this chapter needs Boby’s user id (guid)
to work properly. If Alice targets Boby specifically, before the attack, she needs to
find ways to get Boby’s user id. Alice does not know Boby’s Elgg password, so she
cannot log into Boby’s account to get the information. Please describe how Alice can
find out Boby’s user id.
7. In a request, there is an user id, which is a random number generated by the
server. The ID information can be found from the user’s page from the server. If an
attacker does not know this user ID, can he/she still launch an CSRF attack on this
service?
8. If Alice would like to launch the attack on anybody who visits her malicious web
page. In this case, she does not know who is visiting the web page before hand. (1)
8
Can she still launch a CSRF attack to modify the victim’s Elgg profile? Please
explain. (2) Can she launch a CSRF attack to add her to the victim’s friend list?
Please explain.
9. When a web page sends a request to its server, the session ID is always attached in
the cookie section of the HTTP header. A web application requires all the requests
from its own page to also attach the session ID in its data part (for GET requests,
the session ID is attached in the URL, while for POST requests, the session ID is
included in the payload). This sounds redundant, because the session ID is already
included in the request. However, by checking whether a request has the session ID
in its data part, then web server can tell whether a request is a cross-site request or
not. Please explain why.
10. Do browsers know whether an HTTP request is cross-site or not?
11. Do servers know whether an HTTP request is cross-site or not?
12. Why cannot a web server use the referer header to tell whether a request is
cross-site or not?
13. Why is it important for a server to know whether a request is cross-site or not?
14. Can we simply ask browsers not to attach any cookie for cross-site requests?
15. If a page from www.example.com contains an iframe, inside which a facebook
page is displayed. If a request is sent from inside the iframe, is it considered as a
cross-site request or not? If not, how can be this secured?

Câu 1: Giải thích tại sao cookie cùng trang web có thể giúp ngăn chặn các
cuộc tấn công CSRF?
Thuộc tính cookie cùng trang có thể được sử dụng để vô hiệu hóa việc sử dụng của
bên thứ ba đối với một cookie cụ thể. Nó được đặt bởi máy chủ khi đặt cookie và yêu cầu
trình duyệt chỉ gửi cookie trong ngữ cảnh của bên thứ nhất, nghĩa là khi bạn đang sử
dụng ứng dụng web trực tiếp. Khi một trang web khác cố gắng yêu cầu điều gì đó từ ứng
dụng web, cookie sẽ không được gửi. Điều này thực sự khiến CSRF không thể thực hiện
được vì kẻ tấn công không thể sử dụng phiên của người dùng từ trang web của anh ta
nữa.
Máy chủ có thể đặt cookie cùng trang bằng cách thêm thuộc SameSite=…tính vào Set-
Cookie Tiêu đề:
Set-Cookie: key=value; HttpOnly; SameSite=strict
Có hai giá trị có thể có cho thuộc tính cùng trang web:

 lỏng lẻo
 Nghiêm ngặt

Ở chế độ nghiêm ngặt, cookie được giữ lại với mọi hoạt động sử dụng trên nhiều
trang web. Ngay cả khi người dùng theo một liên kết đến một trang web khác, cookie
cũng không được gửi.

9
 Trong chế độ lỏng lẻo, một số sử dụng chéo trang được cho phép. Cụ thể nếu yêu cầu
là yêu cầu NHẬN và yêu cầu ở cấp cao nhất. Cấp cao nhất có nghĩa là URL trong thanh
địa chỉ thay đổi do điều hướng này. Đây không phải là trường hợp của iframe, hình ảnh
hoặc XMLHttpRequest.
Bảng này hiển thị những cookie nào được gửi với yêu cầu nhiều nguồn gốc. Như bạn
có thể thấy các cookie không có thuộc tính cùng trang web (được biểu thị bằng 'bình
thường') luôn được gửi. Cookie nghiêm ngặt không bao giờ được gửi. Lax cookie chỉ
được gửi với yêu cầu nhận cấp cao nhất.

Loại yêu Mã ví dụ, Đã gửi cookie

cầu,

liên kết <a href="…"> bình thường, lỏng lẻo

kết xuất trước <link rel="prerender" href="…"> bình thường, lỏng lẻo

lấy mẫu <form method="get" action="…"> bình thường, lỏng lẻo

mẫu bài <form method="post" action="…"> Bình thường

iframe <iframe src="…"> Bình thường

ajax $.get('…') Bình thường

hình ảnh <img src="…"> Bình thường

Như bạn mong đợi, chế độ nghiêm ngặt mang lại khả năng bảo mật tốt hơn nhưng lại
phá vỡ một số chức năng. Liên kết đến các tài nguyên được bảo vệ (ví dụ:
https://github.com/Sjord/privateProject) sẽ không hoạt động từ các trang web khác. Ngay
cả khi bạn đã đăng nhập vào GitHub và sẽ có quyền truy cập vào dự án riêng tư này, các
cookie nghiêm ngặt của bạn sẽ không được gửi tới GitHub khi đến từ một trang web
khác. Với chế độ lỏng lẻo, điều này vẫn hoạt động, đồng thời cung cấp bảo mật tốt bằng
cách chặn các yêu cầu đăng trên nhiều trang.
“Khi người dùng truy cập vào trang web, cookie sẽ được gửi đến máy chủ để xác thực
phiên làm việc. Các trang web có thể sử dụng cookie để xác nhận rằng một yêu cầu đến
từ người dùng đã được chứng thực và đến từ cùng một nguồn, bằng cách chèn một mã
token bảo mật vào trong cookie. Khi người dùng gửi một yêu cầu từ trình duyệt web, mã
token sẽ được gửi cùng với yêu cầu đến máy chủ, và máy chủ sẽ kiểm tra xem mã token
có khớp với mã token đã được lưu trữ trong cookie hay không. Nếu khớp, yêu cầu sẽ
được chấp nhận và thực hiện, nếu không, yêu cầu sẽ bị từ chối. Với cơ chế này, người
10
dùng không thể bị lừa để gửi các yêu cầu từ một trang web khác mà họ không mong
muốn hoặc không có quyền truy cập, bởi vì trang web đó sẽ không có mã token bảo mật
được chèn vào cookie của người dùng. Do đó, sử dụng cookie là một biện pháp hiệu quả
để ngăn chặn các cuộc tấn công CSRF.”
=> Thuộc tính cùng trang cung cấp khả năng vô hiệu hóa việc sử dụng của bên thứ ba đối
với bất kỳ cookie nào. Đây là một phương pháp tốt để bảo vệ chống lại các cuộc tấn công
CSRF, bởi vì kẻ tấn công có vẻ như bạn không còn đăng nhập vào trang web đang bị tấn
công nữa.
Câu 2: Giải thích cách một trang web có thể sử dụng mã thông báo bí mật để
ngăn chặn các cuộc tấn công CSRF và tại sao nó hoạt động?
CSRF (Giả mạo yêu cầu trên nhiều trang web) là một kỹ thuật tấn công thông thường
được sử dụng để lừa đảo người dùng truy cập vào một trang web và thực hiện các hành
động không mong muốn. Khi người dùng đăng nhập vào một trang web, trang web sẽ lưu
trữ một mã thông báo bí mật (mã thông báo CSRF) trong phiên đăng nhập của người
dùng.
Mã thông báo bí mật này được sử dụng để xác thực các yêu cầu từ người dùng và đảm
bảo rằng yêu cầu được gửi từ trình duyệt của người dùng là hợp lệ và không bị giả mạo
bởi các bên thứ ba. Mỗi lần người dùng thực hiện một hành động trên trang web, mã
thông báo bí mật này sẽ được gửi kèm theo yêu cầu.
Khi một cuộc tấn công CSRF được thực hiện, kẻ tấn công sẽ cố gắng gửi yêu cầu giả
mạo từ trang web khác đến trang web mục tiêu bằng cách sử dụng thông tin đăng nhập
của người dùng. Tuy nhiên, mã thông báo bí mật chỉ có thể được tạo bởi trang web mục
tiêu và được lưu trữ trong phiên đăng nhập của người dùng, nên kẻ tấn công không thể có
được mã thông báo này.
Do đó, sử dụng mã thông báo bí mật là một cách hiệu quả để ngăn chặn các cuộc tấn
công CSRF trên trang web. Khi người dùng thực hiện một hành động trên trang web,
trang web sẽ kiểm tra xem mã thông báo bí mật được gửi kèm theo yêu cầu có khớp với
mã thông báo được lưu trữ trong phiên bản đăng nhập hay không. Nếu không phù hợp,
yêu cầu sẽ bị từ chối và người dùng sẽ không thể thực hiện hành động đó. Bằng cách sử
dụng mã thông báo bí mật, các trang web có thể ngăn chặn các cuộc tấn công CSRF và
đảm bảo rằng các yêu cầu chỉ được thực hiện bởi những người dùng có quyền truy cập
hợp pháp vào trang web.
Câu 3: Ngày nay, hầu hết các trang web đều sử dụng HTTPS thay vì HTTP.
Chúng ta vẫn cần phải lo lắng về các cuộc tấn công CSRF?
Mặc dù việc sử dụng HTTPS giúp tăng cường bảo mật trên mạng, nhưng vẫn cần phải
lắng nghe về các cuộc tấn công CSRF (Cross-Site Request Forgery) vì nó là một loại tấn
công không liên quan đến việc sử dụng HTTP hoặc HTTPS.

11
CSRF là một kỹ thuật tấn công bằng cách lợi dụng sự tin tưởng của một trang web ứng
dụng trong quá trình xác thực người dùng. Kẻ tấn công sẽ cố gắng thực hiện các hoạt
động không mong muốn trên tài khoản của người dùng mà không cần biết mật khẩu hoặc
thông tin đăng nhập của họ. Khi người dùng đăng nhập vào một trang web và tiếp tục
thực hiện các hành động khác trên cùng một trình duyệt mà không đăng xuất, thì người
dùng có thể trở thành nạn nhân của cuộc tấn công CSRF.
Tuy nhiên, HTTPS có thể giúp hạn chế rủi ro của các cuộc tấn công CSRF bằng cách
sử dụng chứng chỉ SSL/TLS chỉ để mã hóa dữ liệu và cung cấp một kênh an toàn để
truyền thông tin giữa trình duyệt của người dùng và máy tính chủ web. Khi các yêu cầu
HTTP được gửi qua HTTPS, chúng sẽ bị mã hóa và những kẻ tấn công sẽ không thể đọc
được các thông tin gửi đi.
Vẫn có những cách để kẻ tấn công thực hiện cuộc tấn công CSRF trên các trang web
HTTPS. Vì vậy, các nhà phát triển vẫn cần phải khai thác các biện pháp bảo mật để ngăn
chặn các cuộc tấn công CSRF, bao gồm cách thức sử dụng mã thông báo xác thực, thực
thi thuộc tính Same Site trên cookie và sử dụng Chính sách bảo mật nội dung (CSP)
nghiêm ngặt để hạn chế thực thi của mã không đáng tin cậy.
Do đó, vẫn cần phải đề phòng các cuộc tấn công CSRF, ngay cả khi sử dụng HTTPS,
để đảm bảo tính bảo mật và tính toàn vẹn của dữ liệu người dùng trên web.
Câu 4: Sử dụng LiveHTTPHeader, chúng tôi phát hiện ra rằng yêu cầu GET
sau đây được sử dụng để gửi yêu cầu HTTP tới www.example.com để xóa
trang do người dùng sở hữu (chỉ chủ sở hữu của trang mới có thể xóa trang).

http://www.example.com/delete.php?pageid=5

GET /delete.php?pageid=5

Host: www.example.com ...

Vui lòng tạo một trang web độc hại đơn giản để khi nạn nhân truy cập trang này
trang web, một yêu cầu giả mạo sẽ được đưa ra đối với www.example.com để xóa
một trang thuộc về người dùng.

Câu Lệnh :

//malicious.php

<html>

<body>

12
 <script src= “https://code.jquery.com/jquery-1.12.4.min.js><” /script>

<script>

//after malicious page loaded:

$( document ).ready(function(){

//Get request.

$.ajax({

url: ‘www.example.com/delete.php?pageid=5’;

type: ‘get’,

success: function(data){

alert(“success”)

});

});

</script>

</body>

</html>

Đoạn mã trên là một đoạn mã JavaScript được sử dụng để gửi yêu cầu HTTP tới một
trang web khác để xóa một trang có ID là 5.

Các dòng mã cụ thể của đoạn mã là:

1. window.onload = function () {...}: đoạn mã này sẽ được thực thi khi trang web
được tải hoàn tất.
2. var Ajax=null;: Khai báo một biến để lưu trữ đối tượng XMLHttpRequest.
13
 3. var sendurl="http://www.example.com/delete.php?pageid=5";: Khai báo biến
sendurl để lưu trữ URL của trang web mà yêu cầu HTTP sẽ được gửi đến.
4. Ajax=new XMLHttpRequest();: Tạo một đối tượng XMLHttpRequest.
5. Ajax.open("GET",sendurl,true);: Thiết lập yêu cầu HTTP và URL cho phương
thức GET.
6. Ajax.setRequestHeader("Host","www.example.com");: Thiết lập tiêu đề Host cho
yêu cầu HTTP.
7. Ajax.setRequestHeader("Content-Type","application/x-www-form-urlencoded");:
Thiết lập kiểu nội dung của yêu cầu HTTP là "application/x-www-form-
urlencoded".
8. Ajax.send();: Gửi yêu cầu HTTP đến URL được chỉ định.
Tóm lại, đoạn mã trên được sử dụng để gửi yêu cầu HTTP đến URL được chỉ định để xóa
trang web có ID là 5.

Câu 5: Sử dụng LiveHTTPHeader, chúng tôi phát hiện ra rằng yêu cầu
POST sau được sử dụng để gửi yêu cầu HTTP tới www.example.com để xóa
trang do người dùng sở hữu (chỉ chủ sở hữu của trang mới có thể xóa trang).

http://www.example.com/delete.php

POST /delete.php HTTP/1.1

Host: www.example.com

... Content-Length: 8

pageid=5

Vui lòng xây dựng một trang web độc hại đơn giản để khi nạn nhân truy cập trang
web này, một yêu cầu giả mạo sẽ được đưa ra đối với www.example.com để xóa một
trang thuộc về người dùng.

Câu Lệnh :

//malicious.php

<html>

<body>

<script src=“https://code.jquery.com/jquery-1.12.4.min.js><” /script>

14
 <script>

//after malicious page loaded:

$( document ).ready(function(){

$.post(“www.example.com/delete.php”, { json_string:JSON.stringify({pageid:
“5”})

});

});

</script>

</body>

</html>

Đoạn mã JavaScript trên được sử dụng để thực hiện một cuộc tấn công CSRF (Cross-Site
Request Forgery) bằng cách gửi một yêu cầu HTTP POST đến trang web
www.example.com để xóa một trang có ID là 5.

Đoạn mã trên được sử dụng để thực hiện một cuộc tấn công CSRF bằng cách sử dụng các
thông tin bảo mật của Elgg để giả mạo yêu cầu HTTP và xóa một trang cụ thể trên trang
web www.example.com.

15
 Câu 6: Yêu cầu HTTP giả mạo chống lại Elgg trong chương này cần id người
dùng (hướng dẫn) của Bobby để hoạt động bình thường. Nếu Alice nhắm mục
tiêu cụ thể vào Bobby, trước cuộc tấn công, cô ấy cần tìm cách lấy id người
dùng của Bobby. Alice không biết mật khẩu Elgg của Bobby nên cô ấy không
thể đăng nhập vào tài khoản của Bobby để lấy thông tin. Vui lòng mô tả cách
Alice có thể tìm ra id người dùng của Bobby.

Kẻ tấn công CSRF khai thác phiên hiện tại của người dùng, Do đó, nếu kẻ tấn công
không thể lấy phiên hiện tại, sẽ không có cuộc tấn công CSRF nào. Ngoài ra, không thể
thực hiện cuộc tấn công này trên một trang khác. Ngoài ra, Alice có thể sử dụng mã
nguồn của trang thành viên để tìm ra id người dùng của Body. Bằng cách giả mạo một
yêu cầu GET, được kích hoạt khi liên kết của alice của bobby truy cập.
Câu 7: Trong một yêu cầu, có một id người dùng, là một số ngẫu nhiên do
máy chủ tạo ra. Thông tin ID có thể được tìm thấy từ trang của người dùng
từ máy chủ. Nếu kẻ tấn công không biết ID người dùng này, anh ta/cô ta vẫn
có thể khởi động một cuộc tấn công CSRF vào dịch vụ này chứ?

Có, kẻ tấn công vẫn có thể thực hiện cuộc tấn công CSRF vào dịch vụ này ngay cả khi
chúng không biết ID người dùng. Các cuộc tấn công CSRF thường được thực hiện bằng
cách lừa người dùng thực hiện một hành động trên ứng dụng web mà họ không có ý định
thực hiện. Kẻ tấn công thực hiện điều này bằng cách tạo một trang web hoặc email độc
hại có chứa một liên kết hoặc biểu mẫu sẽ tự động thực thi hành động mong muốn khi
người dùng tương tác với nó.
ID người dùng không cần thiết để kẻ tấn công thực hiện kiểu tấn công này. Thay vào
đó, kẻ tấn công có thể chỉ cần tạo một yêu cầu không yêu cầu bất kỳ ID người dùng cụ
16
thể nào được đưa vào hoặc họ có thể cố gắng đoán hoặc cưỡng bức ID người dùng để
thực hiện cuộc tấn công. Ngoài ra, kẻ tấn công có thể sử dụng các phương tiện khác,
chẳng hạn như kỹ thuật xã hội, để lừa người dùng tiết lộ ID người dùng của họ hoặc thay
mặt họ thực hiện một hành động.
Do đó, ngay cả khi kẻ tấn công không biết ID người dùng, họ vẫn có thể khởi chạy
một cuộc tấn công CSRF thành công vào dịch vụ bằng cách khai thác các lỗ hổng hoặc
điểm yếu khác trong ứng dụng hoặc hành vi của người dùng.

Câu 8: Nếu Alice muốn khởi động cuộc tấn công vào bất kỳ ai truy cập trang
web độc hại của cô ấy. Trong trường hợp này, cô ấy không biết ai đang truy
cập trang web trước đó. (1) Cô ấy vẫn có thể khởi động một cuộc tấn công
CSRF để sửa đổi hồ sơ Elgg của nạn nhân chứ? Vui lòng giải thích. (2) Cô ấy
có thể khởi động một cuộc tấn công CSRF để thêm cô ấy vào danh sách bạn
bè của nạn nhân không? Vui lòng giải thích.

8.1. Alice có thể khởi động một cuộc tấn công CSRF để sửa đổi hồ sơ Elgg của nạn
nhân không?
Có, Alice có thể khởi động một cuộc tấn công CSRF để sửa đổi hồ sơ Elgg của nạn
nhân ngay cả khi không biết trước danh tính của khách truy cập. Trong một cuộc tấn công
CSRF, Alice sẽ tạo một trang web độc hại chứa một biểu mẫu ẩn gửi yêu cầu sửa đổi hồ
sơ Elgg của nạn nhân khi khách truy cập tải trang.
Khi nạn nhân tải trang web độc hại, trình duyệt của họ sẽ tự động gửi yêu cầu sửa đổi
hồ sơ Elgg của họ mà họ không hề hay biết hoặc đồng ý, vì yêu cầu được thực hiện từ
trình duyệt của nạn nhân. Nếu nạn nhân hiện đang đăng nhập vào tài khoản Elgg của họ
trong cùng một phiên trình duyệt, yêu cầu sẽ được xác thực bằng cookie phiên của nạn
nhân và việc sửa đổi hồ sơ sẽ thành công.

8.2. Alice có thể khởi động một cuộc tấn công CSRF để thêm mình vào danh sách bạn
bè của nạn nhân không?
Có, Alice cũng có thể khởi động một cuộc tấn công CSRF để thêm mình vào danh
sách bạn bè của nạn nhân. Trong trường hợp này, Alice sẽ tạo một trang web độc hại
chứa một biểu mẫu ẩn gửi yêu cầu thêm Alice vào danh sách bạn bè của nạn nhân khi
khách truy cập tải trang.
Khi nạn nhân tải trang web độc hại, trình duyệt của họ sẽ tự động gửi yêu cầu thêm
Alice vào danh sách bạn bè của họ mà họ không hề hay biết hoặc đồng ý, vì yêu cầu được
thực hiện từ trình duyệt của nạn nhân. Nếu nạn nhân hiện đang đăng nhập vào tài khoản
Elgg của họ trong cùng một phiên trình duyệt, yêu cầu sẽ được xác thực bằng cookie
phiên của nạn nhân và Alice sẽ được thêm vào danh sách bạn bè của nạn nhân.

17
 Điều quan trọng cần lưu ý là có thể ngăn chặn các cuộc tấn công CSRF bằng cách
triển khai các biện pháp như mã thông báo CSRF, là mã thông báo duy nhất do máy chủ
tạo và được đưa vào mọi yêu cầu của khách hàng. Máy chủ xác minh tính hợp lệ của mã
thông báo trước khi xử lý yêu cầu, điều này có thể ngăn các yêu cầu trái phép được xử lý.
Câu 9: Khi một trang web gửi yêu cầu đến máy chủ của nó, ID phiên luôn
được đính kèm trong phần cookie của tiêu đề HTTP. Một ứng dụng web yêu
cầu tất cả các yêu cầu từ trang riêng của nó phải đính kèm ID phiên trong
phần dữ liệu của nó (đối với các yêu cầu GET, ID phiên được đính kèm trong
URL, trong khi đối với các yêu cầu POST, ID phiên được bao gồm trong tải
trọng). Điều này nghe có vẻ dư thừa vì ID phiên đã được bao gồm trong yêu
cầu. Tuy nhiên, bằng cách kiểm tra xem một yêu cầu có ID phiên trong phần
dữ liệu của nó hay không, máy chủ web có thể biết liệu một yêu cầu có phải là
yêu cầu trên nhiều trang web hay không. Hãy giải thích tại sao?

Lý do tại sao việc kiểm tra sự hiện diện của ID phiên trong phần dữ liệu của yêu cầu
giúp xác định xem yêu cầu có phải là yêu cầu trên nhiều trang hay không là do cách thức
hoạt động của cookie và các cuộc tấn công tập lệnh chéo trang (XSS).
Khi người dùng truy cập một trang web, máy chủ sẽ tạo một ID phiên duy nhất và lưu trữ
nó trong cookie trên trình duyệt của người dùng. ID phiên này được sử dụng để xác định
phiên của người dùng và duy trì trạng thái giữa các yêu cầu. Bất cứ khi nào người dùng
gửi yêu cầu đến máy chủ, trình duyệt sẽ tự động đính kèm cookie chứa ID phiên trong
tiêu đề HTTP.
Tuy nhiên, nếu kẻ tấn công đưa mã độc hại vào một trang web, chẳng hạn như thông
qua tấn công lừa đảo hoặc lỗ hổng XSS, thì chúng có khả năng đánh cắp ID phiên của
người dùng và sử dụng nó để thay mặt người dùng thực hiện các yêu cầu tới máy chủ.
Các yêu cầu này được gọi là yêu cầu trên nhiều trang vì chúng bắt nguồn từ một miền
khác với miền mà người dùng hiện đang truy cập.
Để ngăn chặn các cuộc tấn công như vậy, các ứng dụng web sử dụng các biện pháp
bảo mật khác nhau, bao gồm kiểm tra xem yêu cầu có phải là yêu cầu chéo trang hay
không. Một cách để làm điều này là yêu cầu ID phiên cũng được đưa vào phần dữ liệu
của yêu cầu, ngoài cookie. Điều này khiến kẻ tấn công khó chiếm đoạt ID phiên hơn vì
chúng cần biết cả ID phiên và định dạng cụ thể mà nó được bao gồm trong yêu cầu.
Bằng cách kiểm tra xem ID phiên có được bao gồm trong phần dữ liệu của yêu cầu
hay không, máy chủ có thể xác định xem yêu cầu đó có phải là yêu cầu trên nhiều trang
web hay không. Nếu ID phiên được bao gồm trong phần dữ liệu, điều đó có nghĩa là yêu
cầu rất có thể được bắt đầu từ cùng một miền với trang hiện tại và do đó không phải là
yêu cầu trên nhiều trang. Nếu ID phiên không được bao gồm trong phần dữ liệu, thì máy
chủ có thể cho rằng yêu cầu đó có thể là yêu cầu trên nhiều trang web và thực hiện các
biện pháp thích hợp để xác thực và bảo mật yêu cầu đó.

18
 Câu 10. Các trình duyệt có biết liệu một yêu cầu HTTP có phải là trang chéo
hay không?

Có, các trình duyệt web hiện đại có sẵn các cơ chế để xác định xem một yêu cầu
HTTP có phải là trang chéo hay không.
Khi một trang web yêu cầu tài nguyên từ một tên miền khác (nghĩa là một tên miền khác
với tên miền lưu trữ trang web), nó được coi là một yêu cầu trên nhiều trang web. Các
yêu cầu như vậy thường bị hạn chế theo mặc định do các lo ngại về bảo mật, chẳng hạn
như tạo kịch bản chéo trang (XSS) và giả mạo yêu cầu giữa các trang (CSRF).
Một cách mà các trình duyệt xác định xem một yêu cầu có phải là trang chéo hay
không bằng cách so sánh miền của trang web đưa ra yêu cầu với miền của tài nguyên
được yêu cầu. Nếu hai miền khác nhau, yêu cầu được coi là trang chéo.
Các trình duyệt cũng sử dụng các kỹ thuật như Chính sách cùng nguồn gốc (SOP) để
thực thi các hạn chế trên nhiều trang web. SOP hạn chế các trang web truy cập tài nguyên
từ một miền khác trừ khi miền đó cho phép rõ ràng thông qua các cơ chế nhất định, chẳng
hạn như tiêu đề Chia sẻ tài nguyên nguồn gốc chéo (CORS).
Câu 11: Các máy chủ có biết liệu một yêu cầu HTTP có phải là trang chéo
hay không?

Có, các máy chủ có thể xác định xem một yêu cầu HTTP có phải là trang chéo hay
không.
Yêu cầu HTTP giữa các trang web, còn được gọi là yêu cầu CORS (Chia tài nguyên
nguồn gốc chéo), là các yêu cầu được thực hiện bởi một trang web tới một máy chủ có
tên miền hoặc nguồn gốc khác với chính trang web đó. Ví dụ: nếu một trang web được
phân phối từ "example.com" đưa ra yêu cầu tới máy chủ tại "api.example.net", thì đây
được coi là yêu cầu trên nhiều trang web.
Khi trình duyệt đưa ra yêu cầu trên nhiều trang web, nó sẽ bao gồm tiêu đề "Xuất xứ"
trong yêu cầu xác định nguồn gốc của trang web đưa ra yêu cầu. Sau đó, máy chủ có thể
sử dụng tiêu đề này để xác định xem có cho phép yêu cầu hay không.
Một cơ chế bảo mật khác mà các máy chủ có thể sử dụng để bảo vệ chống lại các
cuộc tấn công giữa các trang web là bảo vệ CSRF (Cross-Site Request Forgery). Bảo vệ
CSRF liên quan đến việc thêm mã thông báo duy nhất vào từng biểu mẫu hoặc yêu cầu
được gửi tới máy chủ. Khi máy chủ nhận được yêu cầu, nó sẽ kiểm tra mã thông báo để
đảm bảo rằng nó khớp với mã được gửi ban đầu cùng với biểu mẫu hoặc yêu cầu. Nếu
các mã thông báo không khớp, thì máy chủ có thể từ chối yêu cầu, vì đó có thể là nỗ lực
giả mạo yêu cầu trên nhiều trang web.
Tóm lại, các máy chủ có thể xác định xem một yêu cầu HTTP có phải là trang chéo
hay không bằng cách kiểm tra tiêu đề "Xuất xứ" có trong yêu cầu. Thông tin này có thể

19
được sử dụng để áp dụng các cơ chế bảo mật, chẳng hạn như bảo vệ CORS hoặc CSRF,
để bảo vệ chống lại các cuộc tấn công trên nhiều trang
Ví dụ : web.https://dev.to/lydiahallie/cs-visualized-cors-5b8h
Câu 12: Tại sao máy chủ web không thể sử dụng tiêu đề người giới thiệu để
cho biết liệu yêu cầu có phải là trang chéo hay không?

Tiêu đề "Người giới thiệu" trong yêu cầu HTTP cung cấp thông tin về URL của trang
web đã bắt đầu yêu cầu. Mặc dù có vẻ như tiêu đề này có thể được sử dụng để xác định
xem một yêu cầu có phải là trang chéo hay không, nhưng có một số lý do tại sao nó
không phải là một phương pháp đáng tin cậy:
Tiêu đề "Người giới thiệu" không phải lúc nào cũng xuất hiện: Một số trình duyệt
hoặc tiện ích mở rộng của trình duyệt có thể chặn hoặc xóa tiêu đề "Người giới thiệu"
khỏi các yêu cầu, điều đó có nghĩa là máy chủ sẽ không thể dựa vào tiêu đề đó để xác
định nguồn gốc của yêu cầu.
Giá trị của tiêu đề "Người giới thiệu" có thể được sửa đổi hoặc xóa bởi người dùng
hoặc bởi phần mềm như tiện ích mở rộng trình duyệt, tường lửa hoặc proxy. Các tác nhân
độc hại cũng có thể thao túng tiêu đề "Người giới thiệu" để che giấu nguồn gốc của yêu
cầu và làm cho nó có vẻ như đến từ một trang web khác. Kỹ thuật này được gọi là "Giả
mạo người giới thiệu" và thường được sử dụng trong các cuộc tấn công lừa đảo hoặc để
phá vỡ các biện pháp kiểm soát bảo mật.
Tiêu đề "Người giới thiệu" có thể bị giả mạo: Kẻ tấn công có thể thao túng tiêu đề
"Người giới thiệu" trong yêu cầu để làm cho nó xuất hiện như thể yêu cầu đến từ một
nguồn đáng tin cậy. Điều này có thể cho phép kẻ tấn công bỏ qua cơ chế bảo mật dựa trên
tiêu đề "Người giới thiệu".
Tiêu đề "Người giới thiệu" có thể làm rò rỉ thông tin nhạy cảm: Tiêu đề "Người giới
thiệu" có thể bao gồm thông tin nhạy cảm về người dùng, chẳng hạn như URL của trang
họ đã truy cập trước khi đưa ra yêu cầu. Thông tin này có thể bị kẻ tấn công chặn lại hoặc
bị lộ trong nhật ký máy chủ, điều này có thể ảnh hưởng đến quyền riêng tư của người
dùng
Vì những lý do này, việc dựa vào tiêu đề "Người giới thiệu" để xác định xem yêu cầu
có phải là trang chéo hay không không phải là phương pháp đáng tin cậy. Thay vào đó,
các máy chủ thường dựa vào tiêu đề "Xuất xứ" hoặc các cơ chế bảo mật khác, chẳng hạn
như bảo vệ CORS hoặc CSRF, để bảo vệ chống lại các cuộc tấn công trên nhiều trang
web.
Câu 13: Tại sao điều quan trọng là máy chủ phải biết liệu yêu cầu có phải là
trang web chéo hay không?

20
 Điều quan trọng là máy chủ phải biết liệu một yêu cầu có phải là trang web chéo hay
không vì yêu cầu trang web chéo có thể gây ra rủi ro bảo mật cho máy chủ và ứng dụng
web mà nó đang lưu trữ.
Yêu cầu trên nhiều trang web là yêu cầu bắt nguồn từ một miền khác với miền của
máy chủ đang nhận yêu cầu. Những kẻ tấn công có thể bắt đầu yêu cầu trên nhiều trang
thông qua nhiều phương tiện khác nhau, chẳng hạn như bằng cách khai thác các lỗ hổng
trong ứng dụng web hoặc bằng cách lừa người dùng nhấp vào các liên kết độc hại.
Nếu một máy chủ không thể phân biệt giữa các yêu cầu trên nhiều trang web và các
yêu cầu được bắt đầu từ miền của chính nó, thì máy chủ đó có thể dễ bị tấn công bởi
nhiều loại tấn công khác nhau, bao gồm các cuộc tấn công tạo kịch bản trên nhiều trang
web (XSS), các cuộc tấn công giả mạo yêu cầu trên nhiều trang web (CSRF), và những
người khác.
Ví dụ: nếu máy chủ không xác thực đúng nguồn gốc của yêu cầu, kẻ tấn công có thể
thực hiện cuộc tấn công CSRF, trong đó người dùng vô tình gửi yêu cầu đến máy chủ có
vẻ hợp pháp nhưng thực ra là do kẻ tấn công tạo ra . Điều này có thể cho phép kẻ tấn
công thực hiện các hành động trái phép thay mặt cho người dùng, chẳng hạn như chuyển
tiền, thay đổi mật khẩu hoặc xóa dữ liệu.
Bằng cách xác định và phân biệt chính xác giữa các yêu cầu trên nhiều trang web và
yêu cầu bắt nguồn từ miền của chính nó, máy chủ có thể triển khai các biện pháp bảo mật
thích hợp để bảo vệ chống lại các kiểu tấn công này và đảm bảo tính toàn vẹn cũng như
tính bảo mật của dữ liệu và tài nguyên mà nó đang phục vụ.
Câu 14: Chúng tôi có thể yêu cầu các trình duyệt không đính kèm bất kỳ
cookie nào cho các yêu cầu trên nhiều trang không?
Có, bạn có thể yêu cầu các trình duyệt không đính kèm bất kỳ cookie nào cho các yêu
cầu trên nhiều trang bằng cách sử dụng Same Site thuộc tính trong Set-Cookie Tiêu đề.
Thuộc tính này Same Site là một tính năng tương đối mới cho phép các nhà phát triển
web kiểm soát cách sử dụng và chia sẻ cookie giữa các trang web khác nhau. Nó có thể
được đặt thành một trong ba giá trị có thể:

 SameSite=Lax: Cookie chỉ được gửi với các yêu cầu trên nhiều trang web "an
toàn", chẳng hạn như những yêu cầu được bắt đầu bởi một liên kết hoặc gửi biểu
mẫu, chứ không phải với các yêu cầu được khởi xướng bởi tập lệnh.
 SameSite=Strict: Cookie chỉ được gửi cùng với các yêu cầu đến cùng một trang
web đã đặt cookie.


SameSite=None: Cookie được gửi cùng với tất cả các yêu cầu trên nhiều trang web.

21
Để ngăn cookie được gửi cùng với các yêu cầu trên nhiều trang web, bạn có thể đặt thuộc
Same Site tính thành Lax Hoặc Strict. Ví dụ: nếu bạn muốn đặt cookie chỉ được gửi đến
cùng một trang web, bạn có thể sử dụng cú pháp sau:
vbnet
Sao chép mã
Set-Cookie: mycookie=myvalue; SameSite=Strict;

Bằng cách đặt thuộc Same Site tính thành Strict, cookie sẽ chỉ được gửi đến cùng một
trang web đã đặt cookie. Tương tự, nếu bạn đặt thuộc Same Site tính thành Lax, thì
cookie sẽ được gửi cùng với các yêu cầu trên nhiều trang được bắt đầu bằng các phương
tiện "an toàn", chẳng hạn như các yêu cầu được bắt đầu bằng liên kết hoặc gửi biểu mẫu.
Điều quan trọng cần lưu ý là không phải tất cả các trình duyệt đều hỗ trợ Same Site thuộc
tính này, vì vậy bạn nên kiểm tra trang web của mình bằng các trình duyệt khác nhau để
đảm bảo rằng trang web hoạt động chính xác. Ngoài ra, một số trình duyệt cũ hơn có thể
bỏ qua thuộc Same Site tính hoặc diễn giải nó không chính xác, vì vậy bạn nên biết
những hạn chế này khi sử dụng tính năng này.
Câu 15: Nếu một trang từ www.example.com chứa iframe, bên trong đó trang
facebook được hiển thị. Nếu một yêu cầu được gửi từ bên trong iframe, thì
yêu cầu đó có được coi là yêu cầu trên nhiều trang web hay không? Nếu
không, làm thế nào có thể được bảo đảm này?

Có, yêu cầu được gửi từ bên trong iframe đến miền khác, chẳng hạn như Facebook, được
coi là yêu cầu trên nhiều trang web. Điều này là do nguồn gốc của trang mẹ
( www.example.com ) khác với nguồn gốc của nội dung iframe (Facebook).
Để đảm bảo điều này, bạn có thể sử dụng thuộc tính Same Site trong cookie. Thuộc
tính này yêu cầu trình duyệt chỉ gửi cookie khi yêu cầu đến từ cùng một trang với yêu cầu
ban đầu. Bạn có thể đặt thuộc tính Same Site thành "Strict" để chỉ cho phép gửi cookie
cho các yêu cầu bắt đầu từ cùng một trang hoặc "Lax" để cho phép một số yêu cầu trên
nhiều trang được bắt đầu bằng cách nhấp vào liên kết hoặc tải iframe .
Ngoài ra, bạn có thể sử dụng tiêu đề Chia sẻ tài nguyên nguồn gốc chéo (CORS) để
kiểm soát miền nào được phép thực hiện yêu cầu đối với máy chủ của bạn. Bạn có thể
định cấu hình máy chủ của mình để chỉ cho phép yêu cầu từ các miền cụ thể và từ chối
yêu cầu từ những miền khác.
Cuối cùng, bạn cũng có thể sử dụng tiêu đề Chính sách bảo mật nội dung (CSP) để
kiểm soát những tài nguyên nào được phép tải trên trang của mình, bao gồm tập lệnh,
biểu định kiểu và iframe. Bạn có thể định cấu hình CSP của mình để chỉ cho phép tài
nguyên từ các nguồn đáng tin cậy và chặn bất kỳ tài nguyên nào không được phép rõ
ràng.

22
 PHẦN 2: THỰC HÀNH 5 TASK
2.1 Task 1: Observing HTTP Request
Observing HTTP Request. In Cross-Site Request Forget attacks, we need to forge HTTP
requests. Therefore, we need to know what a legitimate HTTP request looks like and
what parameters it uses, etc. We can use a Firefox add-on called "HTTP Header Live" for
this purpose. The goal of this task is to get familiar with this tool. Instructions on how to
use this tool is given in the Guideline section (§ 5.1). Please use this tool to capture an
HTTP GET request and an HTTP POST request in Elgg. In your report, please identify
the parameters used in this these requests, if any.

Sơ đồ khối task 1:

Hướng dẫn:
Vào terminal gõ lệnh sudo gedit /etc/hosts &>/dev/null &

23
Sau đó sẽ hiển thị bảng hosts

24
Đây là 3 trang web, truy cập vào website: www.seed-server.com
Trước khi làm mới trang web, bạn có thể mở dòng tiêu đề HTTP Header Live này sau đó
có thể nắm bắt các yêu cầu ban đầu tới máy chủ này

Ví dụ nếu bạn muốn nắm bắt tên người dùng và mật khẩu của Alice, để bắt mật khẩu của
Alice mở HTTP Header Live thì tất cả các yêu cầu HTTP được kích hoạt sẽ được ghi lại
và khi thao tác bấm vào đăng nhập với tư cách là Alice và dò tìm mật khẩu bị bắt.

25
Nhấp vào kiểm tra tiện ích mở rộng tiêu đề trước khi đăng nhập vào tài khoản để mở
Thêm thông tin đăng nhập
Người dùng:
Alice
Mật khẩu
Aliceseed

Nhấp vào phần đầu tiên, bạn sẽ nhận được POST request và phần thứ hai để GET
request.

26
Bên cạnh tên người dùng và mật khẩu nắm bắt được còn có thể thấy bất kì các thông tin
khác ví dụ như cookie.

27
 2.2 Task 2: CSRF Attack using GET Request
Task 2: CSRF Attack using GET Request
In this task, we need two people in the Elgg social network: Alice and Samy. Samy wants
to become a friend to Alice, but Alice refuses to add him to her Elgg friend list. Samy
decides to use the CSRF attack to achieve his goal. He sends Alice an URL (via an email
or a posting in Elgg); Alice, curious about it, clicks on the URL, which leads her to
Samy’s web site: www.attacker32.com. Pretend that you are Samy, describe how you can
construct the content of the web page, so as soon as Alice visits the web page, Samy
is added to the friend list of Alice (assuming Alice has an active session with Elgg).
Sơ đồ khối task 2:

Hướng dẫn:
Bước 1: Đăng nhập vào bằng tài khoản Samy.

28
Bước 2: Vào menu More, chọn Members. Sau đó, bấm vào tên Alice.

Bước 3: nhấn nút Add Friend và dùng Live HTTP headers để bắt thông tin.

29
Từ hình này, chúng ta biết được Alice sẽ có Guid = 56.

Bước 4: xác định Guid của Samy. Nhấp chuột phải lên màn hình và chọn View
Page
Source hoặc bấm tổ hợp phím Ctrl + U. Chúng ta sẽ tìm thấy một đoạn script như sau.
<script type="text/javascript">
…
elgg.session.user = new
elgg.ElggUser({"guid":59,"type":"user","subtype":false,"time_created":"1410961820","
time_updated":"1506304518","container_guid":"0","owner_guid":"0","site_guid":"1","n
ame":"Samy","username":"Samy","language":"en","url":"http:\/\/www.csrflabelgg.com
\/profile\/Samy","admin":false});
…
</script>
Xác định được Guid của Samy là 59.

Bước 5: Xác định HTTP request để Add Samy vào danh sách bạn của Alice. Như
quan sát tại bước 3, dạng cửa HTTP request để Add Friend :

30
Dựa vào đây xác định được dạng HTTP request để thêm Samy. Nếu request này được gửi
từ hoạt động trên Elgg của Alice thì Samy sẽ được thêm vào danh sách bạn của cô ấy.

Bước 6: chuẩn bị một trang web độc nhằm thu hút Alice vào xem. Trang web chỉ
cần chứa request ở bước 5. Chúng ta có thể thêm request này vào thuộc tính src của thẻ
img. Khi Alice vào xem trang web thì request này sẽ được thực hiện và Samy đã được
thêm
vào danh sách bạn của Alice.

Bước 7: hoàn thành kết bạn

Đăng nhập alice, vào link attack32 nhấn addfriend rồi reset
31
Khi vào lại danh sách bạn bè của Alice, chúng ta sẽ thấy Samy đã được thêm vào.

Cách tạo trang web độc hại

Vào lại teminal: nhập tiếp: ls-> cd attacker/ -> cop cái id attacker -> mở tab mới nhập
docksh rồi cop id vào

32
Xong nhập ls /var/www/attacker -> cd /var/www/attacker -> nano addfriend.html

Xong quay quay lại trang attacker số 2:

Nhập cd attacker -> ls -> docker cp addfriend.html + “id attacker”: /var/www/attacker.
Ví dụ: 5bc4e4de9960:/var/www/attacker

33
Mở file attack đã download -> dán dòng addfriend vào text note

Copy link id attacker vào khúc scr rồi lưu

34
Tiếp theo kiểm tra đã lưu chưa: vào trang 3 nhập: cat addfriend.html

Đăng nhập alice, vào link attack32 nhấn addfriend rồi reset

35
Vào friend của alice sẽ thấy Samy-> kết bạn thành công

2.3 Task 3: CSRF Attack using POST Request

Task 3: CSRF Attack using POST Request
After adding himself to Alice’s friend list, Samy wants to do something more. He wants
Alice to say “Samy is my Hero” in her profile, so everybody knows about that. Alice
does not like Samy, let alone putting that statement in her profile. Samy plans to use a
CSRF attack to achieve that goal. That is the purpose of this task.
Sơ đồ khối Task 3

36
Đầu tiên, để bắt đầu cuộc tấn công, cần dán editprofile vào Text Editor.

Bước 1: Đăng nhập vào Samy

37
Bước 2: Nhấn vào nút Edit profile và sửa profile

 Nhập “Samy is my hero” vào mục About me và nhập tiếp “Samy is my hero” vào
Brief description

38
  Bật HTTP Header live, sau đó nhấn Save

Sau khi nhấn Save, bạn sẽ kiểm tra Samy đã có mô tả “Samy is my hero” trên trang của
mình hay chưa.

39
  Chúng ta thấy ID của Samy là 59. Bây giờ muốn tấn công Alice thì chúng tôi phải
thay đổi ID thành của Alice.

Bước 3: Ở Editprofile, sửa dòng 21 từ “http://www.example.com” thành

“http://www.seed-server.com/action/profile/edit”

40
Bước 4: Để tấn công Alice thì chúng ta sẽ thay đổi ở dòng 12 trong editprofile, sửa thành
tên Alice: value= ‘Alice’

Bước 5: Sửa tại dòng 13 thành dòng mô tả mình muốn. Chúng tôi sẽ sửa value thành
‘Samy is my hero’.

41
Bước 6: Nếu bạn muốn thêm mô tả thì ta sẽ Crl C dòng 13: fields += “<input type=
‘hidden’ name= ‘description’ value= ‘samy is my hero’ >”;
Dán Ctrl V vào dòng số 14.

Bước 7: Bởi vì đối tượng bị tấn công là Alice nên chúng ta cần có ID guid của Alice, đó
là 56.

42
Tại dòng 16 của editprofile, sửa ID guid thành ID của đối tượng tấn công (tức Alice) là
56.

Sau khi sửa đổi xong thì chúng ta sẽ Save cái mẫu này.

43
Bước 8: Chúng ta vào trang seed@VM: ~/…/attacker nhập dòng sau: docker cp
editprofile.html 5bc4e4de9960:/var/www/attacker/ và nhấn enter.

44
Bước 9: Vào trang root@65c38cbdca74: /var/www/attcker nhập dòng: cat
editprofile.html để kiểm tra cái take note đã lưu lúc nãy ở bước 5.

Sau khi enter, nó hiện như hình ảnh bên dưới => đã ổn, qua bước tiếp theo.

45
Bước 10: Bây giờ, chúng ta cần đăng nhập với tư cách là Alice bởi vì đó là đối tượng tấn
công. Ban đầu hồ sơ trang cô ấy hoàn toàn trống rỗng.

Tu
y nhiên, bây giờ cô ấy đã bị tấn công bởi Samy.
Vào trang attacker32.com, nhấp vào chọn Edit-Profile Attack.

Sau khi nhấp vào, sẽ thấy hồ sơ của chúng tôi đã được lưu thành công, có nghĩa là Alice
đã bị tấn công.

46
 2.4 Task 4: Enabling Elgg’s Countermeasure
Sơ đồ khối task 4:

Hướng dẫn:
Vào Elgg container

47
Mởi đường đẫn chứa file và tiến hành sửa đổi

Kiểm tra

48
Đã ngăn chặn được cuộc tấn công

2.5 Task 5: Experimenting with the SameSite Cookie Method

Sơ đồ khối task 5:

49
Hướng dẫn:
- Truy cập vào trang web có tên là http://www.example32.com để đặt 3 cookie lên trình
duyệt bao gồm cookie-normal, cookie-lax, and cookie-strict. Trong đó cookie thứ nhất
bình thường, cookie 2 và 3 thuộc hai loại khác nhau (Lax và Strict)

50
- Sau đó liên kết A trỏ đến một trang trên example32.com, liên kết B trỏ đến trang trên
attacker32.com. Cả hai trang đều giống nhau (ngoại trừ màu nền) và cả hai đều gửi ba
loại yêu cầu khác nhau tới www.example32.com/showcookies.php, trang này chỉ hiển thị
các cookie do trình duyệt gửi. Bằng cách nhìn vào kết quả
hiển thị, thể biết cookie nào được gửi bởi trình duyệt.

Kết quả thí nghiệm:

Thử nghiệm A (Liên kết A): Khi nhấp vào Liên kết A, ta được đưa đến một trang trên
example32.com, trang này sẽ gửi ba yêu cầu tới www.example32.com/showcookies.php .
Kết quả cho thấy rằng cả ba cookie (cookie bình thường, cookie lỏng lẻo và cookie
nghiêm ngặt) đều được gửi đến máy chủ.

51
Thử nghiệm B (Liên kết B): Khi nhấp vào Liên kết B, ta được đưa đến một trang trên
attack32.com, trang này sẽ gửi ba yêu cầu tới www.example32.com/showcookies.php .
Kết quả cho thấy chỉ có cookie bình thường được gửi đến máy chủ; các cookie Lax và
Strict không được gửi.

52
Giải thích:

Thuộc tính SameSite chỉ định liệu cookie có nên được giới hạn trong ngữ cảnh của bên
thứ nhất hoặc cùng trang web hay không. Trong các thử nghiệm trên, cookie thông
thường không có thuộc tính SameSite được đặt, có nghĩa là cookie đó là cookie của bên
thứ nhất và được đính kèm với tất cả các yêu cầu được gửi tới www.example32.com , bất
kể nguồn gốc. Các cookie Lax và Strict có thuộc tính SameSite được đặt tương ứng thành
Lax và Strict, điều đó có nghĩa là chúng sẽ không được đính kèm vào các yêu cầu trên
nhiều trang.

53
Cookie SameSite giúp máy chủ phát hiện xem yêu cầu là yêu cầu trên nhiều trang web
hay cùng một trang web vì chúng cho phép máy chủ phân biệt giữa các cookie chỉ dành
cho ngữ cảnh của bên thứ nhất và những cookie không dành cho ngữ cảnh của bên thứ
nhất. Điều này hữu ích trong việc ngăn chặn các cuộc tấn công CSRF vì điều đó có nghĩa
là kẻ tấn công không thể sử dụng cookie phiên để khởi chạy một cuộc tấn công CSRF từ
một nguồn gốc khác.

Việc sử dụng cookie SameSite để giúp Elgg chống lại các cuộc tấn công CSRF sẽ liên
quan đến việc đặt thuộc tính SameSite trên cookie phiên thành Nghiêm ngặt. Điều này sẽ
đảm bảo rằng cookie phiên không được đính kèm với các yêu cầu trên nhiều trang web,
ngăn chặn những kẻ tấn công sử dụng nó để khởi chạy các cuộc tấn công CSRF. Ngoài
ra, Elgg có thể sử dụng các biện pháp chống CSRF khác như sử dụng mã thông báo để
xác thực yêu cầu, triển khai cookie chỉ HTTP và triển khai tiêu đề Chính sách liên kết
giới thiệu để ngăn rò rỉ nguồn gốc của yêu cầu.

54
 TÀI LIỆU THAM KHẢO
1. Oreilly, Chapter 4. Transport Layer Security (TLS), truy cập tại:
https://www.oreilly.com/library/view/high-performance-browser/9781449344757/
ch04.html.

2. Thu Uyên, Giao thức TLS là gì? TLS hoạt động như thế nào, truy cập tại:
https://khotenmien.vn/giao-thuc-tls-la-gi-tls-hoat-dong-nhu-the-nao/.

3. Ngô Đắc Du, 27/9/2016, Tìm hiểu về giao thức TLS - Transport Layer Security, mô
hình thuật toán RSA, truy cập tại: https://viblo.asia/p/tim-hieu-ve-giao-thuc-tls-transport-
layer-security-mo-hinh-thuat-toan-rsa-ZDEvLYNJGJb,

4. Giang, 29/04/2021, TLS là gì? Chức năng và cách hoạt động của giao thức TLS, truy
cập tại: https://bizflycloud.vn/tin-tuc/tls-la-gi-20210629100932951.htm

5. Kiên Đinh (2/10/2022), HTTPS là gì? Giải thích chi tiết SSl/ TLS bằng chuyện tình
Chó và Mèo, truy cập tại: https://viblo.asia/p/https-la-gi-giai-thich-chi-tiet-ssltls-bang-
chuyen-tinh-cho-va-meo-2oKLn2Q1LQO.

6. KirstenS, CROSS SITE REQUEST FORGERY (CSRF) truy cập tại:

https://owasp.org/www-community/attacks/csrf

55
56