Bạn có biết rằng chỉ bằng một “cách chèn mã độc” đơn giản, tài khoản của bạn trên mạng xã hội có thể bị xâm nhập? Nghe sai sai, nhưng đúng là thế! Đó chính là Reflected XSS – biến thể nguy hiểm của Cross-Site Scripting. Vậy reflected xss? Sau đây, chúng ta sẽ tìm hiểu khái niệm, mục tiêu và kịch bản của dạng tấn công này.
Xem thêm:
Reflected XSS là gì?
Reflected XSS (Reflected Cross-Site Scripting) là một loại tấn công XSS xảy ra khi dữ liệu được gửi lên máy chủ web được phản hồi trở lại người dùng mà không được kiểm tra hợp lệ. Điều này có nghĩa là kẻ tấn công có thể chèn mã JavaScript độc hại vào trong dữ liệu được gửi lên máy chủ, và khi dữ liệu này được phản hồi trở lại người dùng, mã JavaScript độc hại sẽ được thực thi trên trình duyệt của người dùng.
Ai là nạn nhân của cuộc tấn công này?
Chỉ người dùng nhấp vào URL chứa mã độc hại mới bị tấn công. Các người dùng khác truy cập vào cùng trang web sẽ không bị ảnh hưởng.
Mục tiêu của cuộc tấn công reflected cross-site scripting
Mục tiêu của cuộc tấn công XSS reflected là đánh cắp dữ liệu từ người dùng. Kẻ tấn công có thể sử dụng dữ liệu này để giả mạo danh tính người dùng, truy cập trái phép vào tài khoản của họ hoặc thậm chí bán dữ liệu này cho bên thứ ba.
Kịch bản tấn công reflected XSS thực tế
Bước 1: Người dùng đăng nhập vào trang web.
Bước 2: Kẻ tấn công sẽ gửi một URL chứa mã độc hại đến người dùng. URL này có thể được gửi qua email, tin nhắn hoặc được đăng tải trên một trang web giả mạo.
Bước 3: Người dùng nhấp vào URL và gửi yêu cầu đến máy chủ web.
Bước 4: Nếu máy chủ web dễ bị tấn công, nó sẽ phản hồi mã độc hại trong URL trở lại với người dùng.
Bước 5: Mã độc hại được thực thi bởi trình duyệt của người dùng.
Bước 6: Mã độc hại có thể thực hiện nhiều hành động khác nhau, chẳng hạn như đánh cắp cookie, phiên làm việc hoặc thậm chí là thông tin cá nhân của người dùng.
Ví dụ tấn công reflected XSS
Trong bài viết này, mình sẽ làm ví dụ trong môi trường thực hành DVWA. Lỗ hổng XSS này cho phép người dùng nhập vào một chuỗi và xuất ra màn hình.
Xem thêm:
- Hướng dẫn cách cài đặt DVWA trên Windows bằng Xampp
Mức độ 1: Security low
Chúng ta sẽ thử đoạn mã Javascript sau: <script>alert("Hacked")</script>. Mã javascript này sẽ thực hiện thông báo cookie của trang web bạn đang đăng nhập lên màn hình.
Mức độ 2: Security medium
Ở level này khi thực hiện đoạn mã: <script>alert("Hacked")</script>. Chúng ta bị xoá đoạn thẻ script và chỉ còn lại alert("Hacked").
Kiểm tra thử đoạn mã:
<?php
header ("X-XSS-Protection: 0");
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Get input
$name = str_replace( '<script>', '', $_GET[ 'name' ] );
// Feedback for end user
echo "<pre>Hello {$name}</pre>";
}
?>
Dựa theo đoạn mã trên, thẻ <script> đã bị thay thế. Vậy nên, cách khai thác của ở mức này chúng ta chỉ cần thêm 1 đoạn script nữa như sau: <sc<script>ript>alert("Hacked")</sc<script>ript>.
Mức độ 3: Security high
Với mức độ khó này, khi thực hiện đoạn mã ở trên thì những cái nào liên quan đến script đều sẽ bị xoá hết:
Chúng ta thử xem source:
<?php
header ("X-XSS-Protection: 0");
// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
// Get input
$name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] );
// Feedback for end user
echo "<pre>Hello {$name}</pre>";
}
?>
Đoạn mã trên đã bị thay thế một loạt các ký tự: preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] );. Vì vậy chúng ta không thể sử dụng trực tiếp đoạn script mà phải thử cách khác.
Có một cách để có thể thông báo alert() đó là sử dụng thẻ img như sau:
<img src=x onerror=alert("Hacked")>
Tác hại của lỗ hổng
Nếu kẻ tấn công có thể thực thi một đoạn mã trong trình duyệt của nạn nhân, về cơ bản chúng có thể:
- Thực hiện bất kỳ hành động nào trong ứng dụng mà người dùng có thể thực hiện.
- Xem bất kỳ thông tin nào mà người dùng có thể xem.
- Sửa đổi bất kỳ thông tin nào mà người dùng có thể sửa đổi.
XSS reflected thường ít nghiêm trọng hơn XSS stored, vì nó đòi hỏi nạn nhân phải nhấp vào một liên kết chứa mã JavaScript độc hại. Tuy nhiên, XSS reflected vẫn là một mối đe dọa nghiêm trọng và nên được phòng ngừa.
Cách tìm và kiểm tra lỗ hổng XSS reflected
– Kiểm tra mọi điểm nhập dữ liệu:
- Xác định tất cả các điểm trong ứng dụng mà người dùng có thể nhập dữ liệu: ô tìm kiếm, biểu mẫu nhập dữ liệu, errors page,…
- Các điểm nhập dữ liệu thường gặp bao gồm các tham số trong URL, nội dung tin nhắn, đường dẫn tệp URL và tiêu đề HTTP.
– Gửi các giá trị chữ và số ngẫu nhiên:
- Xác định xem dữ liệu được người dùng nhập vào có được phản hồi hay không.
- Giá trị ngẫu nhiên được sử dụng giúp phát hiện dễ dàng hơn.
- Một giá trị ngẫu nhiên khoảng 8 ký tự thường là lý tưởng.
– Kiểm tra xác thực đầu vào: Xác định xem nội dung bạn nhập có cần xác thực, bị sửa đổi hoặc bị chặn hoàn toàn hay không.
– Thực thi đoạn mã trong trình duyệt: Hãy thử thực thi một số JavaScript đơn giản như alert(document.domain). Nếu kích hoạt một cửa sổ bật lên có thể nhìn thấy trong trình duyệt thì ứng dụng đã bị lỗ hổng XSS reflected.
Các phòng tránh
Để chống lại các cuộc tấn công XSS reflected, hãy đảm bảo rằng bất kỳ nội dung nào đến từ yêu cầu HTTP không thể được sử dụng để chèn mã JavaScript vào trang.
Xác thực đầu vào nội dung (Escape Dynamic Content)
Việc thay thế các ký tự quan trọng bằng mã hóa:
| Ký tự | Mã hoá |
| < | < |
| > | > |
| & | & |
| “ | " |
| ‘ | ' |
Ví dụ: Nếu người dùng nhập <script>alert('Hello, world!')</script> vào trường biểu mẫu, thì bạn sẽ hiển thị nội dung thành <script>alert('Hello, world!')</script>. Điều này sẽ ngăn trình duyệt thực thi mã JavaScript độc hại.
Danh sách giá trị cho phép (Allowlist Values)
Danh sách giá trị cho phép là danh sách các giá trị được phê duyệt trước và được phép sử dụng cho một thông tin đầu vào cụ thể.
Ví dụ: Nếu một trang web có trường nơi người dùng có thể nhập quốc gia của họ thì giá trị danh sách cho phép cho trường đó có thể là danh sách mã quốc gia, chẳng hạn như “US”, “CA” và “UK”. Nếu người dùng nhập một giá trị không có trong danh sách cho phép, trang web sẽ từ chối thông tin nhập vào và ngăn người dùng gửi biểu mẫu.
Triển khai Chính sách bảo mật nội dung (Implement a Content-Security Policy)
Các trình duyệt hỗ trợ chính sách bảo mật nội dung cho phép tác giả của trang web kiểm soát nơi có thể tải và thực thi JavaScript (và các tài nguyên khác).
Với Implement a Content-Security Policy bạn có thể sử dụng thẻ <meta> trong <head> với nội dung sau:
<meta http-equiv="Content-Security-Policy" content="script-src 'self' https://apis.google.com">
Câu hỏi liên quan
Lý do tại sao XSS reflected được gọi là không dai dẳng
Vì cuộc tấn công chỉ xảy ra khi người dùng nhấp vào một URL cụ thể. Một khi người dùng rời khỏi trang web đó, mã độc hại sẽ không còn được thực thi.
Cách phòng ngừa XSS reflected
- Không nhấp vào các liên kết đáng ngờ.
- Giữ trình duyệt và các plugin của bạn được cập nhật.
- Sử dụng phần mềm diệt virus và phần mềm chống phần mềm độc hại.
- Sử dụng các trang web đáng tin cậy.
Sự khác biệt giữa reflected XSS và stored XSS là gì?
Reflected XSS nguy hiểm thông qua các tham số trên URL hoặc form, trong khi stored XSS lưu trữ mã nguy hiểm trực tiếp trên máy chủ và gửi cho mọi người dùng khi họ truy cập trang cụ thể.
Reflected XSS:
Trong reflected XSS, mã độc hại được chèn vào một yêu cầu HTTP và được “phản ánh” trực tiếp trở lại cho người dùng. Thông thường, điều này xảy ra khi người dùng click vào một liên kết chứa các tham số không được kiểm tra cẩn thận.
Stored XSS
Trong stored XSS, mã độc hại được lưu trữ trên máy chủ và sau đó được gửi đến người dùng mỗi khi họ truy cập một trang cụ thể. Thông thường, mã độc được lưu trữ trong cơ sở dữ liệu của ứng dụng web.
Sự khác biệt giữa reflected XSS và dom-based XSS là gì?
Reflected XSS:
Mã độc hại được chèn vào yêu cầu HTTP và được “phản ánh” trực tiếp từ máy chủ về trình duyệt của người dùng.
DOM-based XSS:
Mã độc hại được thực thi trong DOM của trang web, không nhất thiết phản ánh từ máy chủ như trong Reflected XSS. DOM-based XSS xảy ra khi mã độc hại tận dụng lỗ hổng trong việc xử lý client-side JavaScript và thay đổi DOM của trang web.
Lời kết
Tóm lại, Reflected XSS là một lỗ hổng bảo mật nguy hiểm có thể gây nên những hậu quả đáng sợ cho các ứng dụng web. Việc hiểu rõ về lỗ hổng này và áp dụng các biện pháp phòng ngừa thích hợp là rất quan trọng. Chúng ta cần xác định rõ các điểm yếu trong hệ thống, kiểm tra và lọc dữ liệu đầu vào, và nâng cao sự nhạy bén trong việc phát hiện và xử lý những tấn công XSS. Dừng chờ đợi và hãy bảo vệ ứng dụng web của bạn ngay từ bây giờ. Việc đảm bảo an toàn cho dữ liệu và thông tin của người dùng là trách nhiệm của chúng ta.
Bài viết liên quan:
