Microsoft zablokuje nieautoryzowane skrypty w logowaniu Entra ID. Co to oznacza dla Twojej organizacji?

Wprowadzenie do problemu / definicja luki

Microsoft zapowiedział egzekwowanie Content Security Policy (CSP) w doświadczeniu logowania Microsoft Entra ID (adresy zaczynające się od login.microsoftonline.com). Zmiana ma blokować wykonywanie skryptów zewnętrznych oraz wymuszać zaufane źródła i nonce’y dla skryptów inline. Celem jest ograniczenie wektorów XSS oraz innych form wstrzykiwania kodu podczas uwierzytelniania. Wdrożenie globalne przewidziano na połowę/koniec października 2026 r.

W skrócie

• Zakres: tylko przeglądarkowe logowanie do Entra ID na login.microsoftonline.com. Entra External ID i niestandardowe domeny CIAM – bez wpływu.
• Co będzie blokowane: pobieranie skryptów spoza zaufanych CDN Microsoftu oraz wykonywanie skryptów inline bez zaufanego źródła (nonce).
• Kiedy: komunikat Microsoftu z 25 listopada 2025 r.; egzekwowanie od X–2026 (mid-to-late).
• Dlaczego teraz: element programu Secure Future Initiative (SFI) po krytyce CSRB nt. kultury bezpieczeństwa Microsoftu (2024).

Kontekst / historia / powiązania

Kroki wzmacniające to część SFI, wieloletniego programu, który m.in. zwiększył adopcję phishing-resistant MFA (99,6% użytkowników i urządzeń w Microsoft) oraz migrację krytycznych komponentów Entra ID do Azure Confidential Compute. Zmiany wpisują się w nacisk na „secure-by-default” po zaleceniach US Cyber Safety Review Board, które w 2024 r. oceniło kulturę bezpieczeństwa firmy jako „niewystarczającą” i wymagającą przebudowy.

Analiza techniczna / szczegóły zmiany CSP

Microsoft zapowiada dodanie nagłówka CSP do stron logowania Entra ID z kluczowymi zasadami:

• script-src ograniczone do zaufanych domen Microsoft CDN (location-based allowlist) oraz
• dopuszczenie skryptów inline wyłącznie z zaufanego źródła (nonce).
  To w praktyce „zamyka” powierzchnię ataku w przeglądarce: skrypty z rozszerzeń, wtyczek, narzędzi monitorujących czy modyfikujących DOM nie spełniających zasad CSP zostaną odrzucone.

Z perspektywy standardów sieciowych CSP to nagłówek HTTP kontrolujący źródła zasobów. Dyrektywa script-src definiuje dozwolone pochodzenie JS oraz mechanizmy nonce/hash dla skryptów inline, co jest rekomendowane w tzw. strict CSP jako skuteczna obrona przed XSS.

Zakres techniczny:

• dotyczy wyłącznie przeglądarkowej ścieżki logowania (login.microsoftonline.com),
• MSAL / API flows – bez wpływu (enforcement ograniczony do URL logowania),
• Entra External ID / custom domains – bez wpływu.

Praktyczne konsekwencje / ryzyko

• Rozszerzenia przeglądarki i narzędzia wstrzykujące skrypty w ekran logowania mogą przestać działać (np. niestandardowe overlaye, niestandardowe mechanizmy SSO-helpers, skrypty telemetryczne). Samo logowanie nadal zadziała, lecz funkcje tych narzędzi mogą być zakłócone.
• Password manager’y: typowe autouzupełnianie, które nie wymaga wstrzykiwania skryptów w kontekście strony logowania, nie powinno być objęte blokadą; natomiast menedżery używające content-scripts modyfikujących DOM logowania mogą trafić na naruszenia CSP. (Wniosek na podstawie zakresu CSP opisanym przez Microsoft).
• Monitoring/observability: wszelkie rozwiązania zbierające dane poprzez skrypty osadzane w widoku logowania będą blokowane – konieczne są alternatywy zgodne z CSP.

Rekomendacje operacyjne / co zrobić teraz

1. Audyt rozszerzeń i narzędzi używanych przez helpdesk/SSO/IT (listy rozszerzeń, GPO/Intune, MDM). Usuń lub zastąp te, które wstrzykują skrypty w logowanie Entra ID.
2. Testy w przeglądarkach: przejdź pełną ścieżkę logowania z otwartą konsolą dev – szukaj błędów typu “Refused to load the script … violates script-src / nonce”. Zanotuj źródło naruszenia i zespół/użytkownika.
3. Plan zgodności z CSP: jeśli zależysz od narzędzia stron-trzecich, pracuj z dostawcą nad wersją zgodną z CSP (np. bez wstrzykiwania skryptów, z integracją poprzez oficjalne API/SDK).
4. Zero Trust & SFI alignment: równolegle wzmacniaj kontrolę tożsamości (MFA odporne na phishing, hardening stacji, inventory, telemetry) – to filary SFI.
5. Komunikacja z użytkownikami: zapowiedz zmiany i wyjaśnij, że od X–2026 niektóre „przydatne” wtyczki mogą przestać działać na ekranie logowania – to działanie proaktywne podnoszące bezpieczeństwo.

Różnice / porównania z innymi przypadkami

• „Zwykłe” CSP w aplikacji vs CSP narzucone przez dostawcę tożsamości: w pierwszym przypadku pełna kontrola jest po stronie dewelopera aplikacji; w drugim – politykę definiuje Microsoft dla krytycznego komponentu łańcucha uwierzytelniania. To utrudnia „obejścia” przez rozszerzenia i narzędzia klienta.
• Allowlist CSP vs strict CSP (nonce/hash): Microsoft łączy allowlistę z nonce dla inline, co ogranicza zarówno zewnętrzne źródła, jak i możliwość podmiany inline.

Podsumowanie / kluczowe wnioski

• Microsoft utwardza logowanie Entra ID przed XSS i wstrzykiwaniem kodu poprzez egzekwowanie CSP od października 2026 r.
• Organizacje muszą usunąć lub wymienić rozwiązania wstrzykujące skrypty w ekran logowania; samo logowanie dalej zadziała, ale takie skrypty będą blokowane.
• To element szerszej strategii SFI i odpowiedź na postulaty CSRB – trend „secure-by-default” w tożsamości przyspiesza.

Źródła / bibliografia

• The Hacker News: zapowiedź zmian i daty wdrożenia (27 listopada 2025). (The Hacker News)
• Microsoft TechCommunity (Entra Blog): oficjalny komunikat i instrukcje przygotowania. (TECHCOMMUNITY.MICROSOFT.COM)
• Microsoft Learn: „Content Security Policy overview for Microsoft Entra ID”. (aka.ms)
• Microsoft Trust Center: „November 2025 SFI Progress Report”. (Microsoft)
• CISA/CSRB: „Review of the Summer 2023 Microsoft Exchange Online Intrusion” – wnioski dot. kultury bezpieczeństwa. (CISA)