Có an toàn khi sử dụng InternalHTML trong Angular không?
|
Lỗ hổng Cross-Site Scripting (XSS) có thể và sẽ dẫn đến sự thỏa hiệp hoàn toàn của ứng dụng giao diện người dùng. Lỗ hổng XSS cho phép kẻ tấn công kiểm soát ứng dụng trong trình duyệt của người dùng, trích xuất thông tin nhạy cảm và thực hiện các yêu cầu thay mặt cho ứng dụng. Các framework hiện đại đi kèm với hệ thống phòng thủ tích hợp chống lại XSS, nhưng chúng thực sự đi được bao xa? Show
1 tháng 2 năm 2021 Bảo mật SPA Các ứng dụng XSS, góc cạnh, một trang Một đoạn mồi ngắn về XSSLỗ hổng XSS là lỗ hổng tiêm chích, trong đó kẻ tấn công chèn một phần dữ liệu độc hại vào ứng dụng web. Dữ liệu được tiêm độc hại sẽ được trình duyệt chọn, diễn giải dữ liệu dưới dạng mã. Điều này làm cho tải trọng được đưa vào từ kẻ tấn công được thực thi dưới dạng mã ứng dụng hợp pháp, giúp kẻ tấn công có toàn quyền kiểm soát ứng dụng đang chạy trong trình duyệt của người dùng Ví dụ mã bên dưới minh họa một ví dụ trong sách giáo khoa về lỗ hổng XSS và cuộc tấn công Lỗ hổng DOM-XSS trong ứng dụng jQuery Một thư độc hại chứa tải trọng JavaScript Nếu dữ liệu này được chèn vào trang, trình duyệt sẽ thực thi tập lệnh trong thông báo, kích hoạt hộp thoại cảnh báo. Ví dụ ở đây gọi hàm Cách phòng thủ tốt nhất trước các cuộc tấn công XSS là đảm bảo rằng trình duyệt sẽ không bao giờ xem dữ liệu dưới dạng mã. Một cách tiếp cận phổ biến để đạt được điều đó là áp dụng mã hóa đầu ra theo ngữ cảnh. Mã hóa đầu ra theo ngữ cảnh sẽ đảm bảo rằng dữ liệu được mã hóa cho ngữ cảnh mà nó kết thúc trên trang. Trong quá trình mã hóa, các ký tự nguy hiểm tiềm tàng được dịch thành các ký tự vô hại. Do cách dịch đó, trình duyệt sẽ xem các ký tự này là dữ liệu thay vì mã, tránh nhầm lẫn và ngăn chặn cuộc tấn công Dưới đây là một ví dụ về tác động của việc áp dụng mã hóa đầu ra theo ngữ cảnh đối với dữ liệu chứa tải trọng độc hại Một thông báo độc hại chứa tải trọng JavaScript, nhưng được mã hóa đúng cách để tránh XSS Như bạn có thể thấy, trình duyệt hiện được hướng dẫn hiển thị mã HTML Góc áp dụng tự động thoátKhi một ứng dụng đưa dữ liệu vào trang bằng cơ chế nội suy của Angular (i. e. , sử dụng Góc tự động thoát khỏi tất cả các ràng buộc dữ liệu dựa trên phép nội suy Cơ chế phòng thủ thoát tự động này, mà Angular gọi là Thoát theo ngữ cảnh nghiêm ngặt, rất quan trọng để đảm bảo bảo vệ cơ bản chống lại các cuộc tấn công XSS. Khi các khung phía máy chủ và khung phía máy khách không cung cấp mức bảo vệ tối thiểu này, các ứng dụng sử dụng các khung đó thường gặp phải rất nhiều lỗ hổng XSS Góc áp dụng hành vi nhạy cảm theo ngữ cảnh này trên tất cả các ràng buộc dữ liệu dựa trên phép nội suy. Ví dụ: liên kết dữ liệu vào thuộc tính HTML sẽ đảm bảo rằng dữ liệu không thể thoát khỏi thuộc tính và kích hoạt việc thực thi mã tập lệnh bổ sung Khi trốn thoát hơi xaCác ứng dụng trong thế giới thực thường gặp phải các yêu cầu khi chúng cần hiển thị mã HTML động. Mã HTML đó thường bắt nguồn từ các nguồn không đáng tin cậy, chẳng hạn như dữ liệu do người dùng cung cấp. Hình ảnh dưới đây minh họa một tình huống phổ biến của trường hợp sử dụng này Hình ảnh từ trang web CKEditor minh họa các tính năng của trình soạn thảoTrình soạn thảo văn bản đa dạng thức, chẳng hạn như CKEditor, thường tạo HTML dưới dạng đầu ra. Tài liệu mà bạn có thể xem bên trên hiển thị hình ảnh có thành phần Trong các khóa đào tạo của mình, tôi sử dụng một ứng dụng đào tạo thu thập các đánh giá về nhà hàng. Ứng dụng này muốn người dùng có thể sử dụng các cấu trúc HTML lành tính trong các bài đánh giá của họ. Mặc dù các bài đánh giá ít phức tạp hơn so với tài liệu của CKEditor, nhưng các yêu cầu kỹ thuật là như nhau Đối với những trường hợp sử dụng này, Angular hiển thị thuộc tính Dữ liệu do người dùng cung cấp là một vectơ tấn công phổ biến để khai thác lỗ hổng XSS Nếu chúng tôi chạy bài đánh giá này thông qua trình khử trùng Angular, nó sẽ xuất hiện dưới dạng bài đánh giá mà bạn có thể xem bên dưới Bài đánh giá do người dùng cung cấp sau khi đã được khử trùng bằng trình khử trùng HTML Cơ chế hoạt động ở đây là khử trùng HTML bằng cách sử dụng trình khử trùng HTML tích hợp của Angular. Trình khử trùng HTML biết phần tử và thuộc tính nào an toàn (e. g. , Lưu ý rằng vệ sinh nghe giống như lọc (a. k. a, những thứ bạn làm với biểu thức chính quy), nhưng đó là một cách tiếp cận hoàn toàn khác. Trình khử trùng sẽ phân tích dữ liệu thành cây cú pháp và đưa ra quyết định bảo mật dựa trên cây đó. Một chất khử trùng tốt sử dụng danh sách các giá trị an toàn và coi mọi thứ không có trong danh sách là không an toàn Vì vậy, chúng ta không thể làm mọi thứ rối tung lên trong Angular?Angular thực hiện công việc xuất sắc trong việc giúp các nhà phát triển viết mã an toàn. Bất kỳ ai xây dựng ứng dụng Angular theo “cách thông thường” đều có thể yên tâm rằng chúng sẽ không gây ra lỗ hổng XSS. Tìm cách vượt qua sự phòng thủ của Angular tốn khá nhiều công sức. Hãy xem xét một số mẫu bạn có thể muốn tránh trong các ứng dụng của mình Bỏ qua bảo mậtAngular cung cấp một cách để xuất HTML thô mà không áp dụng bất kỳ biện pháp bảo vệ XSS nào. Chức năng này có sẵn thông qua chức năng Ví dụ mã bên dưới cho biết cách sử dụng hàm Đánh dấu đoạn mã tĩnh là an toàn bằng hàm bypassSecurityTrustHtml Việc gán một đoạn mã an toàn cho [innerHTML] không kích hoạt trình khử trùng của Angular Hành vi này cực kỳ nguy hiểm khi bị lạm dụng, như tên của chức năng gợi ý. Trường hợp sử dụng duy nhất có thể chấp nhận được là xuất một đoạn mã tĩnh, mã do chính bạn viết. Không bao giờ sử dụng chức năng này với bất kỳ giá trị không đáng tin cậy nào Ngoài ra, nếu bạn cần sử dụng nó để xuất mã tĩnh, hãy xem xét đóng gói hàm này trong một hàm trợ giúp có tên apt (e. g. , Sử dụng các phần tử DOM gốcGóc hoạt động ở cấp độ các thành phần và không thực sự ở cấp độ các phần tử HTML riêng lẻ. Chắc chắn, các mẫu chứa các phần tử HTML, nhưng các ứng dụng Angular hiếm khi tham chiếu các phần tử này một cách rõ ràng từ mã. Hiếm khi là từ khóa ở đây. Hầu hết các ứng dụng không cần truy cập trực tiếp vào các phần tử HTML, nhưng một số trường hợp sử dụng cụ thể yêu cầu quyền truy cập cấp thấp như vậy Đó chính xác là lý do tại sao Angular hỗ trợ sử dụng ElementRef. Ví dụ mã bên dưới cho biết cách tham chiếu một phần tử trong mã của thành phần bằng ElementRef. Phần tử này được định nghĩa một mẫu là Sử dụng ElementRef để chỉ một phần tử HTML cụ thể Với tham chiếu này, giờ đây chúng ta có thể truy cập phần tử DOM gốc. Quyền truy cập như vậy hữu ích cho việc xử lý sự kiện chi tiết nhưng cũng cho phép các mẫu mã không an toàn, chẳng hạn như ví dụ mã bên dưới Hành vi nguy hiểm khi sử dụng các phần tử DOM gốc Trong ví dụ mã này, chúng tôi đưa dữ liệu trực tiếp vào DOM. Vì chúng tôi đang xử lý các API DOM gốc, nên Angular không còn có thể bảo vệ chúng tôi khỏi các cuộc tấn công XSS tiềm ẩn. Mã này cực kỳ không an toàn và vượt qua các biện pháp phòng thủ XSS tích hợp của Angular Không có lý do chính đáng tại sao một mẫu mã như thế này nên được sử dụng trong ứng dụng Angular. Tôi khuyên bạn nên quét cơ sở mã của mình để đảm bảo không có mẫu này và thiết lập quy tắc linting để đảm bảo mẫu này sẽ không bao giờ xuất hiện trong cơ sở mã Sử dụng API Renderer2Việc sử dụng Ví dụ mã bên dưới cho thấy cách sử dụng API Renderer2 với ElementRef để đặt thuộc tính Hành vi nguy hiểm khi sử dụng API Renderer2 Cũng giống như việc sử dụng API DOM gốc, tôi khuyên bạn nên quét cơ sở mã của mình để đảm bảo mẫu này không xuất hiện và thiết lập quy tắc linting để đảm bảo mẫu này sẽ không bao giờ được đưa vào cơ sở mã Hội thảo bảo mật kéo dài 2 ngày này tiến xa hơn rất nhiều so với các biện pháp phòng thủ XSS tích hợp của AngularTham gia hội thảo này để tìm hiểu thêm về các biện pháp bảo mật tốt nhất hiện tại cho các ứng dụng Angular Đợi một chút, còn URL thì sao?Một nguồn lỗ hổng XSS phổ biến khác là các URL. Hãy xem URL được hiển thị bên dưới Tất cả các trình duyệt hiện đại đều hỗ trợ URL JavaScript trong thuộc tính phần tử URL này sử dụng Ngày nay, có thể nói rằng Trình khử trùng góc đảm bảo rằng các URL được tạo động an toàn để sử dụng trong ứng dụng. Nhìn vào mã cho thấy rằng trình khử trùng chỉ cho phép các URL an toàn đã biết và thêm tiền tố vào các URL khác bằng lược đồ Thậm chí tốt hơn, Angular áp dụng cơ chế này ngay lập tức Không nhanh lắm, các URL tài nguyên không hoạt động tốtNếu bạn đã từng thử tải một iframe bằng cách gán một biến cho thuộc tính Đây là Angular bảo vệ ứng dụng khỏi nội dung có thể gây hại. Tốt, nhưng tại sao lại có thông báo lỗi? URL tài nguyên về cơ bản là các URL kích hoạt ngay việc tải tài nguyên. Ví dụ là iframe, tập lệnh, biểu định kiểu, v.v. Bao gồm các URL Thay vì đoán xem cái gì an toàn và cái gì không, Angular sai lầm ở khía cạnh an toàn bằng cách từ chối tải tài nguyên động. Đó là lý do tại sao bạn nhận được thông báo lỗi. Vì vậy, về bản chất, Angular bảo vệ bạn khỏi những mẫu nguy hiểm này Để kích hoạt hành vi này, ứng dụng của bạn sẽ phải chứng minh tính hợp lệ của URL mà bạn đang cố tải. Về bản chất, điều này có nghĩa là bạn sẽ phải đảm bảo URL được xây dựng an toàn hoặc bạn sẽ phải xác thực URL trước khi gán nó cho một thành phần HTML. Để ngăn Angular kích hoạt lỗi, bạn phải đánh dấu URL là an toàn trước khi gán nó. Bạn có thể làm điều đó bằng cách sử dụng hàm Biến một URL động thành một URL an toàn bằng cách sử dụng hàm bypassSecurityTrustResourceUrl Lưu ý rằng trong ví dụ mã này, chúng tôi tạo URL Youtube an toàn bằng cách chỉ cho phép người dùng cung cấp ID video. Bằng cách đó, chúng tôi chắc chắn rằng URL trỏ đến Và những gì về kết xuất trang phía máy chủCái hay của Angular là nó là một framework giải quyết các trường hợp sử dụng phổ biến. Kết quả là mã Angular chạy trên trình duyệt chính là mã đang chạy trên máy chủ. Mặc dù điều này có vẻ hợp lý, nhưng điều này không phải lúc nào cũng đúng với các framework khác, chẳng hạn như React (Hãy xem loạt bài gồm 3 phần này về XSS trong React) Cụ thể, đối với Angular, điều này có nghĩa là nếu bạn tuân theo các nguyên tắc viết mã an toàn, như đã thảo luận trong bài viết này, thì các trang được hiển thị phía máy chủ của bạn cũng được bảo mật. Angular Universal cũng bảo vệ chống lại các lỗ hổng bên ngoài khác, điều này thật tuyệt. Thật không may, điều này không phải lúc nào cũng đúng với các dự án dựa trên Angular. Bạn có thể đọc thêm về điều đó trong bài viết này về XSS đến Tóm tắt và hướng dẫn mã hóa an toànĐiều đó đưa chúng ta đến phần tóm tắt của bài viết này về XSS trong các ứng dụng Angular. Để kết thúc, hãy tóm tắt lại những điều quan trọng nhất
Đó là nó. Ba nguyên tắc đơn giản này sẽ giúp bạn tránh XSS trong Angular. Và nếu bạn thích bài viết này, đừng quên chia sẻ nó với bạn bè và đồng nghiệp Angular của bạn Sử dụng InternalHTML trong góc có tốt không?Angular đi kèm với trình khử trùng html tích hợp DomSanitizer , như một tính năng bảo mật, được sử dụng bất cứ khi nào bạn sử dụng [innerHtml]. Đó là một tính năng tuyệt vời - nhưng có một lỗi/tính năng khá khó chịu ở chỗ nếu bạn có các thành phần có kiểu nội tuyến, thì các kiểu đó sẽ bị xóa khỏi trang của bạn .
InternalHTML có phải là rủi ro bảo mật không?Việc đặt giá trị của InternalHTML cho phép bạn dễ dàng thay thế nội dung hiện có của phần tử bằng nội dung mới. Ghi chú. Đây là rủi ro bảo mật nếu chuỗi được chèn có thể chứa nội dung độc hại tiềm ẩn .
Việc sử dụng InternalHTML trong góc là gì?Angular 14 cung cấp liên kết thuộc tính [innerHTML] mà bạn có thể sử dụng để kết xuất HTML thay vì sử dụng phép nội suy , như bạn có thể .
Nhược điểm của việc sử dụng InternalHTML trong JavaScript là gì?Nhược điểm của InternalHTML
. Khi chúng tôi đã sử dụng trình xử lý sự kiện thì trình xử lý sự kiện sẽ không tự động được gắn vào các phần tử mới được tạo bởi InternalHTML. It is very slow because as inner HTML already parses the content even we have to parse the content again so that's why it takes time. When we have used the event handlers then the event handlers are not automatically attached to the new elements created by innerHTML. |
