Elementy iframe bez danych logowania: łatwe umieszczanie elementów iframe w środowiskach COEP

Arthur Sonzogni
Arthur Sonzogni

Deweloperzy korzystający z interfejsu COEP mogą teraz umieszczać elementy iframe innych firm, które nie używają tego interfejsu.

Bezpieczeństwo bez hasła w przypadku ramek iframe jest domyślnie włączone od wersji 110 przeglądarki Chrome. Rozwiązanie to eliminuje najczęstszą przyczynę skarg deweloperów pracujących z zasadami osadzania z innych źródeł (COEP): umieszczanie elementów iframe innych firm, które nie mają ustawionej wartości COEP.

Dlaczego potrzebujemy COEP

Niektóre interfejsy API zwiększają ryzyko ataków typu side-channel, takich jak Spectre. Aby ograniczyć to ryzyko, przeglądarki oferują środowisko izolowane oparte na opcjonalnym włączeniu, zwane izolacją zasobów z innych domen, które wymaga wdrożenia COEP. Izolacja między domenami umożliwia witrynom korzystanie z funkcji uprzywilejowanych, takich jak SharedArrayBuffer, performance.measureUserAgentSpecificMemory() i precyzyjne zegary z lepszą rozdzielczością.

Aby umożliwić izolację między domenami, witryny muszą wysyłać te nagłówki HTTP:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

COEP:credentialless może też służyć jako alternatywa dla require-corp. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją.

Problemy z włączeniem COEP

Chociaż izolacja między domenami zwiększa bezpieczeństwo stron internetowych i umożliwia stosowanie zaawansowanych funkcji, wdrożenie tej technologii może być trudne. Jednym z największych wyzwań jest to, że wszystkie iframe między domenami muszą stosować nagłówki COEP i CORP. Przeglądarka nie wczyta iframe bez tych nagłówków.

Tag iframe bez danych logowania na ratunek

Wprowadzamy tag <iframe credentialless>, aby ułatwić umieszczanie ramek iframe innych firm, które nie mają ustawionego parametru COEP. Dodanie atrybutu credentialless do elementu <iframe> powoduje, że iframe jest ładowany z innego, pustego kontekstu. W szczególności jest on wczytywany bez plików cookie. Pozwala to usunąć ograniczenie COEP.

Przykład:

<iframe credentialless src="https://example.com">

Ten iframe jest tworzony w nowym kontekście efemerycznym i nie ma dostępu do żadnych plików cookie powiązanych z witryną najwyższego poziomu. Zamiast tego zaczyna się od pustego pliku cookie. Podobnie interfejsy API pamięci, takie jak LocalStorage, CacheStorage, IndexedDB itp., wczytują i przechowują dane w nowej partycji tymczasowej. Partycja jest ograniczona do bieżącego dokumentu najwyższego poziomu i źródła elementu iframe. Po zwolnieniu dokumentu najwyższego poziomu całe to miejsce na dane zostaje zwolnione.

Elementy iframe bez danych logowania nie podlegają zasadom umieszczania treści COEP. Nadal są one bezpieczne: ponieważ są wczytywane za każdym razem z nowego pustego kontekstu, nie powinny zawierać danych spersonalizowanych, których szukają hakerzy. Jeśli iframe zawiera tylko dane publiczne, nie jest wartościowy dla atakującego.

Prezentacja

Możesz obejrzeć prezentację iframe bez danych logowania.

Najczęstsze pytania

Czy inne przeglądarki będą mogły korzystać z tej funkcji?

Czy <iframe> jest zagnieżdżony w <iframe credentialless> bez hasła?

Tak. Jest dziedziczona. Gdy iframe nie wymaga poświadczeń, dotyczy to wszystkich takich ramek w całym poddrzewie, nawet bez atrybutu credentialless.

Czy wyskakujące okienka są tworzone także bez danych logowania <iframe credentialless>?

Wyskakujące okienka są otwierane tak, jakby było ustawione noopener. Są one tworzone w nowym zwykłym kontekście najwyższego poziomu i nie są bez hasła. Nie mogą one komunikować się z ramką iframe bez danych logowania.

Jak wykryć, że dokument został umieszczony w elemencie iframe bez danych logowania?

window.credentialless ma wartość true (prawda) w przypadku iframe bez danych logowania. W przeciwnym razie ma wartość false (fałsz). Jego wartość to undefined w przeglądarce, która nie obsługuje <iframe credentialless>.

Zasoby