Cross-site scripting [XSS] là một kiểu tấn công có thể được thực hiện để xâm phạm người dùng của một trang web. Việc khai thác lỗ hổng XSS cho phép kẻ tấn công đưa các tập lệnh phía máy khách vào các trang web được người dùng xem. Được liệt kê là một trong 10 lỗ hổng hàng đầu của OWASP, XSS là lỗ hổng phổ biến nhất được gửi trên nền tảng Detectify Crowdsource, do đó, rủi ro bảo mật mà công cụ của chúng tôi liên tục kiểm tra.
Tập lệnh chéo trang. Điều gì có thể xảy ra?
Kẻ tấn công có thể
- có quyền truy cập vào cookie của người dùng, ID phiên, mật khẩu, tin nhắn riêng tư, v.v.
- đọc và truy cập nội dung của trang cho bất kỳ người dùng bị tấn công nào và do đó tất cả thông tin được hiển thị cho người dùng
- xâm phạm nội dung hiển thị cho người dùng
Một cuộc tấn công XSS đáng chú ý là sâu Tweetdeck XSS được xuất bản vào năm 2014. Nó cho phép kẻ tấn công phát tán tải trọng độc hại của mình tới tất cả người dùng Tweetdeck thông qua Twitter, do đó gây ra sự xâm phạm hàng loạt tài khoản Twitter
Video bằng chứng về khái niệm XSS
Ví dụ về Cross-site scripting [XSS]
Để cho thấy lỗ hổng hoạt động như thế nào, hãy xem một ví dụ. Giả sử bạn có một hộp tìm kiếm trên trang web của mình. Nếu không có kết quả, trang web sẽ thông báo “Không thể tìm thấy bất kỳ trang nào khi tìm kiếm [những gì người dùng đã tìm kiếm]. ”
Làm điều này trong PHP nó có thể trông giống như thế này
Nói cách khác, điều này sẽ xuất dữ liệu do người dùng cung cấp [truy vấn tìm kiếm] thẳng vào tài liệu HTML. Nếu truy vấn tìm kiếm chứa HTML, trình duyệt web của người dùng sẽ hiển thị nó. Hãy tưởng tượng kẻ tấn công gửi một liên kết như sau cho nạn nhân
//example.com/search.php?query=
Điều này sẽ khiến nạn nhân tìm kiếm
Vì không có xác thực dữ liệu nên trình duyệt mục tiêu sẽ hiển thị
Could not find any pages when searching for
HTML được chèn sẽ được thực thi. HTML chứa một thẻ script sẽ đánh giá JavaScript. JavaScript sẽ lấy cookie của người dùng và gửi nó vượt quá giới hạn tới miền của bên thứ ba do kẻ tấn công kiểm soát. Sau đó, kẻ tấn công sẽ có thể đặt cookie của riêng họ thành cookie bị đánh cắp của nạn nhân, do đó có quyền truy cập vào dữ liệu của nạn nhân. Đây là một ví dụ phổ biến về một cuộc tấn công leo thang đặc quyền bằng phương pháp kịch bản chéo trang và cưỡi phiên
Khắc phục kịch bản chéo trang
Việc khắc phục các lỗ hổng XSS phụ thuộc nhiều vào ngữ cảnh và các bản vá khác nhau. Dưới đây là một số mẹo chung [trong đó UNTRUSTED là nơi dữ liệu do người dùng cung cấp]
Nội dung HTML
Ví dụ
UNTRUSTED
Giải pháp
Chuyển đổi sang thực thể HTML [nghĩa là. & đến & v.v.].
Xem PHP htmlspecialchars[]
Thuộc tính HTML
Ví dụ
Giải pháp
Chuyển đổi đầu vào không đáng tin cậy của người dùng thành các thực thể HTML để ngăn việc tạo các thuộc tính khác và không bao giờ cho phép bất kỳ dữ liệu người dùng nào vào các tham số “id”, “class” hoặc “name”. Hãy hết sức thận trọng khi cung cấp dữ liệu người dùng vào trình xử lý sự kiện DOM [e. g. title], chúng được tạo ra để thực thi JavaScript.
URL không đáng tin cậy
Ví dụ
link
Giải pháp
URL mã hóa dữ liệu người dùng, đưa các URL đã biết vào danh sách cho phép và chạy dữ liệu người dùng thông qua thư viện URL phù hợp bằng ngôn ngữ của bạn. Lưu ý đến giao thức được chỉ định và nếu bạn mong đợi các liên kết HTTP hoặc HTTPS, hãy đưa các liên kết đó vào danh sách trắng. Ngăn JavaScript chạy bằng cách sử dụng trình xử lý giao thức.
NHẬN tham số
Ví dụ
link
Giải pháp
URL mã hóa dữ liệu người dùng và ngăn việc sử dụng dấu và vì nó có thể dẫn đến các vấn đề về ô nhiễm tham số.
giá trị CSS
Ví dụ
Giải pháp
CSS mã hóa giá trị hex.
biến Javascript
Ví dụ
Giải pháp
Trích dẫn xung quanh biến và mã hóa hex. Ngăn ngắt dòng.
XSS DOM
Ví dụ
element.innerHTML = UNTRUSTED
Giải pháp
Làm sạch bằng thư viện được viết bằng ngôn ngữ bạn sử dụng. Thực thi việc sử dụng các chức năng an toàn hơn bất cứ khi nào có thể áp dụng [e. g. InternalText thay vì InternalHTML]. Hãy thật cẩn thận khi xác định dữ liệu nào được phép in. Tốt hơn là có một danh sách trắng các ký tự được phép hơn là một danh sách đen.
Để có danh sách các mẹo mở rộng hơn, hãy xem các mẹo ngăn chặn XSS của OWASP
Cách Detectify có thể trợ giúp
Detectify là một trình quét bảo mật web thực hiện các kiểm tra hoàn toàn tự động để xác định các vấn đề bảo mật trên trang web của bạn. Nó kiểm tra trang web của bạn để tìm hơn 1000 lỗ hổng, bao gồm Cross-site scripting [XSS]. Đăng ký dùng thử miễn phí và tìm hiểu xem bạn có dễ bị tổn thương không »
Đối với các nhận xét chung, các thẻ tập lệnh được thoát chính xác, do đó, nó chỉ được hiểu là văn bản thay vì mã thực tế. Trong trường hợp này, loại sự việc đó được xử lý thông qua một thứ được gọi là mã hóa HTML, trong đó
UNTRUSTED
6 của bạn Cross-site scripting [XSS] là một trong những cuộc tấn công web tầng ứng dụng phổ biến nhất. Lỗ hổng XSS cho phép đưa các tập lệnh độc hại vào trang web, tập lệnh này được thực thi trong trình duyệt web của người dùng. Và kết quả của cuộc tấn công như vậy có thể không đẹp như được hiển thị ở đây
Đẹp nhỉ?
Đoạn video ồn ào đó minh họa mức độ phổ biến của lỗ hổng XSS trên các trang web của các ngân hàng Hà Lan. Nó được trình bày bởi Brenno de Winter vào năm 2015 tại hội nghị AppSecEU… Anh ấy đã vui hơn một chút vào năm 2016… Và không có nhiều thay đổi vào năm 2019
Các ứng dụng Angular hoặc React có an toàn không?
Có… gần như… ở một mức độ nào đó
Cả Angular và React đều cung cấp khả năng khử trùng đầu vào tích hợp và coi tất cả các đầu vào là không đáng tin cậy theo mặc định, giúp giảm thiểu rủi ro chính [xem tài liệu liên quan cho Angular và React]. Mặc dù vậy, với cả hai khung, bạn có thể tự bắn vào chân mình bằng cách sử dụng một cách nguy hiểmSetInnerHTML trong React hoặc bỏ quaSecurityTrust trong Angular
Mặc dù câu thần chú "vào đầu vào, chúng tôi không tin tưởng" hoạt động cho các nhà phát triển SPA, nhưng đừng rơi vào cảm giác sai lầm về khả năng miễn nhiễm với các cuộc tấn công XSS. Có nhiều cách khác để đưa tập lệnh phía máy khách vào trang web. Ngoài ra, các nhà phát triển thiếu kinh nghiệm có thể sáng tạo trong việc viết mã không an toàn dễ bị tấn công XSS, chẳng hạn như. g. thêm tập lệnh hoặc kiểu nội tuyến, kẻ tấn công có thể dễ dàng tận dụng hoặc chỉ cần có
UNTRUSTED
7Mã như dưới đây có được chú ý khi xem xét mã của bạn không?
0
Kiểm tra các ví dụ khác
Để bảo vệ ở cấp độ khác, chúng tôi cần các tiêu đề HTTP thích hợp
Tiêu đề HTTP để ngăn Cross-site scripting [XSS]
Tất nhiên, bạn đã chạy các trang web trên HTTPS. Sau đó quét trang web của bạn với tiêu đề bảo mật. com để xem các tiêu đề HTTP mà bạn đang thiếu. Có khả năng, hầu hết các tiêu đề cần thiết đều dễ dàng thêm vào [e. g.
UNTRUSTED
8 hoặc UNTRUSTED
9], nhưng có một công việc sử dụng nhiều lao động - 0
Chính sách bảo mật nội dung [CSP] xác định các nguồn được phê duyệt cho nội dung trên trang web của bạn mà trình duyệt có thể tải
Việc nhận ra độ phức tạp của các tham số CSP có thể đến sau khi xem xét Hướng dẫn tham khảo nhanh CSP hoặc tài liệu web MDN. Có hơn một tá chỉ thị cho các chỉnh sửa chi tiết và rất có thể bạn cần ít nhất những thứ sau
1
Bạn có thể dùng thử công cụ CSP Builder trực tuyến để tạo chính sách CSP
Làm cách nào để áp dụng CSP cho trang web hiện tại?
Tìm ra các chỉ thị CSP phù hợp là một quá trình tẻ nhạt và yêu cầu khá nhiều thử nghiệm. Có hai cách khác nhau để làm điều đó
#1. Cách tinh tế
Trước khi đi sâu vào
0, hãy bắt đầu thử nghiệm các chính sách bằng cách giám sát [nhưng không thực thi] tác động của chúng bằng cách đặt Chính sách bảo mật nội dung-Chỉ báo cáo. Nó sẽ cố gắng gửi tất cả các báo cáo vi phạm tới URI đã chỉ định [xem chỉ thị báo cáo-uri] hoặc ghi vào bảng điều khiển nếu URI báo cáo không được định cấu hình
Các bước sẽ là
Đặt chính sách hạn chế nhất
3Mở trang web và kiểm tra nhật ký lỗi trong bảng điều khiển của trình duyệt
Khắc phục lỗi bằng cách điều chỉnh chính sách
12Lặp lại các bước 2-3 cho đến khi tất cả các lỗi biến mất
Thay đổi tiêu đề HTTP
12 thành
0, để các chính sách đã xác định được thực thi
Để thay đổi nhanh chóng trong môi trường nhà phát triển, bạn có thể thử nghiệm bằng cách đặt không phải tiêu đề HTTP mà là thẻ meta
0
6
Thật không may, thẻ meta cho
12 không tồn tại [xem yêu cầu bổ sung]
#2. cách hack
Cảm thấy mạo hiểm? . Chúng hữu ích để mô phỏng các chính sách khác nhau ngay trên môi trường sản xuất của bạn nếu nó khác với môi trường phát triển
Hãy lấy Fiddler làm ví dụ. Các bước của bạn sẽ là
Đặt "Giải mã lưu lượng HTTPS" trên tab "HTTPS" của "Tùy chọn" [nó sẽ cài đặt chứng chỉ TSL]. Xem tài liệu của Fiddler
Thực hiện các thay đổi tùy chỉnh đối với phản hồi trên web, sử dụng FiddlerScript để thêm quy tắc trong
17 [xem tài liệu]Bắt đầu nắm bắt lưu lượng truy cập
Mở trang web trong trình duyệt cùng với bảng điều khiển của trình duyệt và kiểm tra lỗi
Điều chỉnh cài đặt CSP trong
17 cho đến khi tất cả các lỗi biến mất
Báo cáo vi phạm
Các trang web phức tạp, nơi rủi ro/chi phí cắt bỏ nội dung hợp lệ cao, cần có thông báo về vi phạm chính sách. May mắn thay, CSP có chỉ thị report-uri, hướng dẫn trình duyệt POST các báo cáo vi phạm có định dạng JSON đến một vị trí được chỉ định trong chỉ thị
19
Bạn không cần phải tự mình xử lý các báo cáo đó, report-uri. com hoạt động tốt và miễn phí ở quy mô nhỏ
Gotchas với CSP trong ứng dụng Angular và React
góc cạnh
Quá trình biên dịch Ahead-of-Time [AOT] [hay còn gọi là
30] tách tất cả mã JavaScript khỏi tệp
31. Thật không may, việc xử lý CSS không được gọn gàng và các kiểu vẫn nằm trong dòng trong tất cả các thành phần [đây là một vé để theo dõi]. Vì vậy, chúng tôi phải đưa ra chỉ thị
32 khó chịu trong tiêu đề CSP và hy vọng điều tốt nhất
Đối với một ứng dụng đơn giản có phông chữ của Google, tiêu đề CSP có thể giống như
Could not find any pages when searching for4
Phản ứng
Ứng dụng tạo phản ứng thực hiện tốt công việc ngăn chặn các tập lệnh nội tuyến và tạo ra một HTML tương thích với CSP hơn. Tuy nhiên, không phải theo mặc định, bạn cần cài đặt
33 trong tệp
34 [xem tài liệu]
Nhưng
35 không lý tưởng vì nó chèn trực tiếp các hình ảnh nhỏ vào HTML [vé]. Vì vậy, hãy thêm chỉ thị
36 vào CSP
Tiêu đề CSP này có thể là một cách tốt để bắt đầu
Could not find any pages when searching for9
Cập nhật [ngày 1 tháng 7]. Yêu cầu PR có liên quan đã được hợp nhất và cài đặt
37 sẽ loại bỏ hình ảnh base64 nội tuyến. Mặc dù vậy, tôi vẫn chưa thử, nhưng nếu nó hoạt động, thì
35 sẽ tuân thủ CSP
Phần kết luận
Thêm hầu hết các tiêu đề HTTP là một chiến thắng nhanh chóng. Về CSP, nó làm giảm nguy cơ tấn công kiểu XSS trên các trình duyệt hiện đại. Nếu cấu hình đúng
Vào năm 2016, Google đã xuất bản một bài báo có tên “CSP đã chết, CSP còn sống lâu. ” Điều đó chứng tỏ rằng 95% tất cả các chính sách CSP có thể bị kẻ tấn công bỏ qua một cách tầm thường. Thế nào?
Thêm vào đó là rủi ro cắt bỏ một số chức năng thiết yếu do định cấu hình sai CSP, nhiều ngày điều chỉnh cài đặt và bạn phải đối mặt với ROI rất tệ
Là một giải pháp thay thế cho việc đưa toàn bộ máy chủ vào danh sách trắng, các nhân viên của Google đã đề xuất bật các tập lệnh riêng lẻ thông qua cách tiếp cận dựa trên sự kết hợp của CSP dựa trên
60 với chỉ thị
61. Do đó, nếu một tập lệnh được tin cậy với một nonce sẽ tạo một tập lệnh mới trong thời gian chạy, thì tập lệnh mới này cũng sẽ được coi là hợp pháp
Hừm…thú vị. Mặc dù vậy, cách tiếp cận dựa trên nonce vẫn chưa được biết đến nhiều, điều đó có nghĩa là ít tài liệu hơn và dễ bị lỗi hơn. Webpack có khả năng thêm
60 vào tất cả các tập lệnh mà nó tải, nhưng các khung SPA đang chờ áp dụng [#3430, #12378]