Cross-Site Scripting (XSS)

Nhiều người nghĩ Cross-Site Scripting không hề nguy hiểm, có lẽ vì họ nghĩ XSS đơn giản chỉ là sử dụng javascript tạo ra một hộp thoại thông báo. Cũng vì lý do đó mà nhiều Web-master thường chủ quan khi không lọc dữ liệu vào – ra (input – output). Trong bài này mình sẽ tìm hiểu lỗ hổng XSS nó nguy hiểm như thế nào.

I. Cross-Site Scripting là gì

Cross-Site Scripting (hay còn gọi là XSS) là một trong những kĩ thuật tấn công phổ biến nhất hiện nay, được liệt vào danh sách những kỹ thuật tấn công nguy hiểm nhất với ứng dụng web.

Cross Site Scripting là một lỗi bảo mật cho phép người tấn công (Attacker, Hacker,…) chèn các đoạn script nguy hiểm vào trong source code ứng dụng web. Nhằm thực thi các đoạn mã độc Javascript để chiếm phiên đăng nhập của người dùng.

II. Các kiểu khai thác XSS

1. 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.

ví dụ như chức năng comment trong blog, website, message ... Ví dụ dưới đây minh họa cho Stored-XSS. Để demo mình tạo trang comment dính lỗ hổng bảo mật XSS như sau:

Giờ ta thử thay nội dung comment bằng đoạn JavaScript cơ bản để Test XSS:

Một hộp thoại thông báo hiện lên, như vậy hệ thống đã dính XSS

example 1: Thay đổi toàn bộ liên kết trong một trang web, link sang 1 trang web khác.

<a href="http://vnexpress.net/">Xiaomi ra smartphone trông giống Galaxy Note 7 </a><br>
<a href="http://vnexpress.net/">Galaxy Note 7 vẫn được chào bán ở Hong Kong</a><br>
<a href="http://vnexpress.net/">Lenovo A6600 Plus - smartphone 4G phổ thông</a><br>
<a href="http://vnexpress.net/">Hacker huy động webcam Trung Quốc để đánh sập Internet</a><br>
<a href="http://vnexpress.net/">Nghi phạm Nga ăn cắp 117 triệu mật khẩu LinkedIn bị bắt </a><br>
<a href="http://vnexpress.net/">Nhiều camera an ninh tại Việt Nam bị tấn công DDoS </a><br>

chèn mã javascript để thay đổi link

kết quả:

example 2: Deface website with XSS

Thay đổi background

kết quả sau khi thay đổi:

Mở rộng : Trường hợp nếu một trang đăng nhập bị dính lỗi bảo mật XSS sẽ nguy hiểm như nào? Hacker/Attacker có thể thay đổi action sang một tệp PHP khác xử lý các giá trị nhận được bao gồm tài khoản, mật khẩu thậm chí là các thông tin nhạy cảm khác tùy vào nơi dính lỗ hổng XSS là khu vực đăng nhập, đăng ký, thanh toán,… Hacker/Attacker hoàn toàn có thể lưu lại (log) sau đó giả mạo việc đăng nhập bằng cách gửi trả (POST) dữ liệu tới tệp tin xử lý thật của Form ban đầu.

2.Reflected XSS

Khác với Stored-XSS, Reflected-XSS đoạn mã khai thác sẽ không được lưu trữ trên server. Một ví dụ điển hình của Reflected-XSS là kết quả trả về của module search:

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 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.

Có nhiều hướng để khai thác thông qua lỗi Reflected XSS, một trong những cách được biết đến nhiều nhất là chiếm phiên làm việc (session) của người dùng, từ đó có thể truy cập được dữ liệu và chiếm được quyền của họ trên website.

Dạng tấn công bằng Reflected XSS được mô tả 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ụ:

http://victim.com/index.php?id=<script>alert(document.cookie)</script>

Để cho người dùng khó phát hiện 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%2

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.

Từ phía site của mình, hacker sẽ bắt được nội dung request trên và coi như session của người dùng sẽ bị chiếm. Đến lúc này, hacker có thể giả mạo với tư cách nạn nhân và thực hiện mọi quyền trên website mà nạn nhân có.

III. Ngăn ngừa, lọc và vá các lỗ hổng XSS

Đối với người dùng 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. Đặc biệt trên mạng xã hội. Cần cảnh giác trước khi click vào xem 1 link nào đó được chia sẻ.

Đố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

• 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

VD: sử dụng hàm Strip_tags hoặc htmlentities để chuyển tất cả những ký tự nguy hiểm thành các ký tự HTML an toàn..

<div class="comment_div">
            <p class="name">Posted By:<?php echo htmlentities($name);?></p>
            <p class="comment"><?php echo htmlentities($comment);?></p>
            <p class="time"><?php echo $time;?></p>
        </div>

Kết quả sau khi vá lỗ hổng XSS

Như các bạn đã thấy lỗi XSS nguy hiểm như thế nào, là các Web-master/Developer khi phát triển một Website không thể chủ quan, coi thường những lỗ hổng cơ bản như XSS, luôn cẩn trọng trong việc xử lý các nơi dữ liệu đầu vào từ người dùng như Form đăng nhập, đăng ký, tìm kiếm thông tin,… Lọc tất cả dữ liệu trước khi lưu vào cơ sở dữ liệu hoặc khi in ra trên trang web.

Nguồn Tham khảo

http://securitydaily.net http://tek.eten.vn http://phpcoban.com/