Các vectơ tấn công có thể có cho kịch bản lệnh trang web được phản ánh là gì?

Question

Wikipedia cung cấp information about one of the most common scenarios khai thác một kịch bản tấn công qua trang web phản ánh - sử dụng một số mức độ kỹ thuật xã hội để tạo ra người dùng không nghi ngờ bấm vào một liên kết độc hại:

1. Alice thường đến thăm một trang web cụ thể, được tổ chức bởi Bob . Trang web của của Bob cho phép Alice đăng nhập bằng cặp tên người dùng/mật khẩu và lưu trữ dữ liệu nhạy cảm, chẳng hạn như thông tin thanh toán .
2. Mallory quan sát thấy trang web của Bob chứa một lỗ hổng XSS được phản ánh.
3. Hàng thủ công Mallory một URL để khai thác lỗ hổng bảo mật và gửi cho Alice một email , lôi kéo cô nhấp vào một liên kết cho URL theo cách giả mạo. URL này sẽ trỏ đến trang web của Bob, nhưng sẽ chứa mã độc hại của Mallory , trang web sẽ phản ánh.
4. Alice truy cập URL do Mallory cung cấp khi đăng nhập vào trang web của Bob.
5. Tập lệnh độc hại được nhúng trong URL thực hiện trong trình duyệt của Alice, như thể nó đến trực tiếp từ máy chủ của Bob (đây là lỗ hổng XSS thực tế). Có thể sử dụng tập lệnh để gửi cookie phiên của Alice tới Mallory. Mallory sau đó có thể sử dụng cookie phiên để ăn cắp thông tin nhạy cảm có sẵn cho Alice (thông tin xác thực, thanh toán thông tin, v.v.) mà không có kiến ​​thức của Alice.

Bây giờ, điều này thường có xu hướng được ví dụ rất tốt khi trang web sẽ xảy ra là một trang định hướng ứng dụng - các lỗ hổng được khai thác bằng cách người dùng phải nộp một payload độc hại đến các ứng dụng (quan trọng hơn , bằng cách đưa ra yêu cầu GET khi đăng nhập) được phản ánh lại trong phản hồi.

Có bất kỳ vector tấn công thú vị nào hơn, đặc biệt là các vectơ cần xem xét khi ứng dụng sử dụng rất nhiều AJAX với hầu hết các yêu cầu được thực hiện qua HTTP POST không?

EDIT

Trong trường hợp tôi đã không rõ ràng, tôi muốn biết các loại hình tấn công vector áp dụng đối với phản ánh các cuộc tấn công XSS, đặc biệt là khi lớp client-side của ứng dụng được thực hiện khác nhau . Các ứng dụng dựa trên trang sẽ có một vector tấn công liên quan đến các yêu cầu HTTP GET do người dùng cấp, nhưng sẽ rất thú vị khi biết điều này diễn ra như thế nào đối với các ứng dụng khách dày đặc biệt là các ứng dụng sử dụng các đối tượng XMLHttpRequest phát ra các yêu cầu HTTP POST. Các cơ chế khác nhau được sử dụng trong hiển thị phía máy khách rõ ràng sẽ đảm bảo nghiên cứu các vectơ tấn công khác nhau. Trong một số trường hợp, có thể không có bất kỳ vector tấn công thích hợp nào; câu hỏi được thể hiện để gợi ra phản ứng như vậy.

Answer 1

Có, trên thực tế, có một vài biến thể trong cuộc tấn công XSS phản chiếu. Chủ yếu là rõ ràng là Samy Worm. Trong ngắn hạn, Samy đã sử dụng XSS để kích hoạt XHR tới MySpace.com để đọc mã thông báo CSRF và giả mạo yêu cầu POST. Trên thực tế, đây là một mẫu tấn công chung hữu ích cho việc tấn công các trang web đang sử dụng httponly cookies. Vì việc sử dụng các cookie httponly trở nên phổ biến hơn, nên mẫu tấn công này sẽ như thế nào.

Tải trọng xss khác là XSS Shell. Điều này cung cấp cho kẻ tấn công một kênh tương tác với trình duyệt.

XSS được sử dụng để phân phối cuộc tấn công "Drive-By-Download".

Xss cũng có thể được sử dụng để fake the news. Với xss chống lại news sources thường xuyên được tìm thấy, đây là một vấn đề khá nghiêm trọng.

Chỉnh sửa: Bạn cũng có thể quan tâm cách nền tảng Apache got owned sử dụng xss và tinyurl. Here là một khai thác mà tôi đã viết trong đó sử dụng một cuộc tấn công kiểu Samy để có được CSRF.

Answer 2

XSS phản ánh xảy ra khi trang hiển thị đầu vào người dùng độc hại. Câu hỏi "vector tấn công là gì?" do đó đồng nghĩa với "trang đầu vào của người dùng có thể nhận được gì?"

Một số nguồn tin là:

• Chuỗi truy vấn của một yêu cầu GET mà có thể đến từ:
  • một URL trong một email
  • một chuyển hướng (thông qua js, 301 trả lời, hoặc meta) từ trang web bị tấn công hoặc độc hại
• Nội dung yêu cầu POST có thể đến từ:
  • yêu cầu AJAX POST từ bất kỳ tên miền nào (Chính sách gốc tương tự không dừng yêu cầu, chỉ phân tích cú pháp phản hồi)
  • Bất kỳ hình thức nào có phương thức = "POST" và hành động = "XSSed_site.com". Biểu mẫu có thể được đăng qua js hoặc bằng cách nhấp vào nút có thể được thực hiện bằng cách sử dụng tính năng nhấp chuột.
• Các hình thức đầu vào như:
  • js file bên ngoài như máy phân loại bảng hoặc thư viện mà các trang bị tấn công đang sử dụng
  • truyền thông máy chủ đến máy chủ đó sẽ được hiển thị trên trang tấn công
  • bất kỳ dữ liệu khác hiển thị trên trang bị tấn công có thể được thay đổi bởi những kẻ tấn công

Tôi nhận thấy rằng phần "Các hình thức đầu vào khác" trông giống như một lỗ hổng XSS được lưu trữ, nhưng mỗi ứng dụng là duy nhất và một số có thể dịch đầu vào của người dùng thành các phần bên ngoài được tạo thành trang (do đó được phản ánh).

Chuỗi truy vấn trong yêu cầu GET từ email bị lừa đảo chắc chắn không phải là vectơ duy nhất cho XSS được phản ánh (câu hỏi hay).

Answer 3

benlbroussard đã chạm vào điều này, nhưng tôi muốn nhắc lại nó vì tầm quan trọng. Khách hàng chất béo, khách hàng mỏng, POST, GET, PUT; không có vấn đề gì trong số này. Lỗ XSS dựa trên một trang web không chính xác hiển thị một số đầu vào cho ai đó.

Nếu bạn đang tìm kiếm một cuộc tấn công được phản ánh nghiêm ngặt thì tải trọng không được lưu trữ ở bất kỳ đâu trong ứng dụng đích.Trong trường hợp đó, tôi nghĩ bạn đúng rằng một khách hàng béo sẽ có xu hướng trở nên kháng cự hơn vì GET là cách dễ nhất để bắt đầu một cuộc tấn công XSS được phản ánh.

Về vectơ tấn công khác, một điều thú vị về kiến ​​trúc máy khách chất béo là mã hóa thực thể. Một khách hàng mỏng có thể mã hóa tất cả mọi thứ và được thực hiện với nó, với lợi ích to lớn. Một thực thể chất béo nên thực thể mã hóa phản hồi cho một GET ban đầu, nhưng các yêu cầu không đồng bộ với các câu trả lời cho JavaScript không thể được (hoàn toàn) được mã hóa và là JS hợp lệ. Điều này trở lại và ra làm tăng cơ hội không mã hóa một cái gì đó cần được, đó là một bước tiến lớn hướng tới việc tạo ra một vector XSS.

Có ý nghĩa?

Carl