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. Trong bài
viết này tôi sẽ đề cập sơ lược tới XSS với một số kinh nghiệm của tôi qua kĩ
thuật tấn công này.
1. XSS là gì ?
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.
Kĩ thuật tấn công XSS đã
nhanh chóng trở thành một trong những lỗi phổ biến nhất của Web Applications và
mối đe doạ của chúng đối với người sử dụng ngày càng lớn. Người chiến thắng
trong cuộc thi eWeek OpenHack 2002 là người đã tìm ra 2 XSS mới. Phải chăng mối
nguy hiểm từ XSS đã ngày càng được mọi người chú ý hơn.
2. XSS hoạt động
như thế nào ?
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 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?qu...39;);</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 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 ..
3. Cảnh giác với
XSS
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 :
Trích:
--====_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>
<iframe>
</iframe></BODY></HTML>
--====_ABC0987654321DEF_====--
--====_ABC1234567890DEF_====
Content-Type:
audio/x-wav;
name="filename.ext.ext"
Content-Transfer-Encoding:
base64
Content-ID: <EA4DMGBP9p>
[/b]
Đô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:
Trích:
<form>
<input>
</form>
[/b]
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/search.cgi?query=<s...</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/search.cgi?%71%75%65%61...%72%69%70%74%3EĐó
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.
4. Phát hiện XSS bằng cách
nào ?
Nếu như các bạn sử dụng các mã nguồn của các chương trình có sẵn bạn có
thể tham khảo danh sách các lỗ hổng của chương trình bạn trên các trang web chứa
các thông tin về bảo mật như securityfocus.com, securiteam.com,... Tuy nhiên nếu
các website được tự viết mã nguồn thì bạn không thể áp dụng phương pháp trên.
Trong trường hợp này bạn cần đến các chương trình scanner tự động. Nếu như bạn
sử dụng trong môi trường Windows bạn có thể dùng N-Stealth hay AppScan, đó là
những chương trình scan khá tuyệt, bạn không chỉ kiểm tra được các lỗi XSS mà nó
còn cho phép bạn kiểm tra các lỗi khác trong Website đó, Server đó.
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.
5. Ngăn ngừa XSS như thế nào ?
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, đối với
các dữ liệu của người sử dụng bạn nên
+ 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 sữ
liệu.
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 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à :
Trích:
#!/usr/bin/perl
use
CGI;
my $cgi = CGI->new();
my $query =
$cgi->param('query');
print $cgi->header();
print "You entered
$query";
[/b]
Đâ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 :
Trích:
#!/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);
[/b]
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
trình từ
http://www.mricon.com/html/phpfilter.htmlLọc và mã hoá các
dữ liệu cho vấn là cách tốt nhất để chống XSS nhưng nếu bạn đang sử dụng
mod_perl trên Apache Server thì bạn có thể dùng ngay module
Apache::TaintRequest. Khi đó mã nguồn chương trình sẽ có dạng :
Trích:
use
Apache::TaintRequest;
my $apr =
Apache::TaintRequest->new(Apache->request);
my $text =
$apr->param('text');
$r->content_type("text/html");
$r->send_http_header;
$text
=~ s/[^A-Za-z0-9 ]//;
$r->print("You entered ", $text);
[/b]
Kĩ thuật XSS được mô tả lần đầu tiên cách
đây 2 năm 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.
Trang Chính 
Mon Jun 25, 2007 4:17 pm