iframe-beágyazás ellenőrző

Ingyenes online iframe ellenőrző: írjon be egy tetszőleges weboldal URL-címét az X-Frame-Options és a Content-Security-Policy frame-ancestors fejlécek vizsgálatához, derítse ki, hogy az oldal beágyazható-e iframe-be, és ellenőrizze élő előnézettel. Az előzmények a jelenlegi böngészőmunkamenethez kötött tárolásra kerülnek.

IFrame beágyazottság ellenőrzése

:

Mindegyik sort ugyanazzal a fejléces ellenőrzéssel futtatja le, és hozzáadja az alábbi munkamenet-előzményekhez. Kötegelenként max. 20 URL-cím engedélyezett; kisebb csoportokban történő feldolgozás, hogy ne terheljük túl a céloldalakat.

Ellenőrizve: /
URL-cím Eredmény HTTP

Élő előnézet

A fejlécek ellenőrzése egy gyors, első körös szűrés, mivel nem képes érzékelni a JavaScript kerettörési (frame-busting) kódokat. Ha a fejlécek „Beágyazható” eredményt jeleznek, mégis üres marad az előnézet, kiugrik az iframe-ből, vagy hibafeltüntetést mutat, az oldal nem biztonságos beágyazási célokra. Az élő előnézet jelenti a végső ítéletet.

Előzmények (jelen munkamenet)

Csak ebben a fülön tárolódik (sessionStorage); a fül bezárásával törlődik. Semmi nem kerül szerverre.

Még nincs ellenőrzés a jelenlegi munkamenetben.

Hogyan működik az ellenőrzés?

  1. Adja meg a céloldal URL-jét, majd kattintson az Ellenőrzés gombra. A szerver valós iframe-kérésként lekéri az oldalt (Sec-Fetch-Dest: iframe fejléccel), és kiolvassa a válaszfejléceket.
  2. Az eredményt az X-Frame-Options (DENY / SAMEORIGIN blokkolja a keretezést) és a Content-Security-Policy frame-ancestors vezérli (kizárólag a * vagy a protokollhelyettesítő karakter engedélyezi tetszőleges harmadik fél általi megjelenítést).
  3. Ugyanezt az URL-t betölti az élő előnézeti iframe-be, így Ön láthatja, mit tesz a böngésző valójában – beleértve a fejlécek által nem közvetített JavaScript kerettörési kódokat is.

Mi határozza meg, hogy egy oldal beágyazható-e?

Annak eldöntésére, hogy egy weboldal megjeleníthető-e egy másik webhely <iframe> elemein belül, a böngésző a válaszfejlécek alapján hoz döntést. Ezt a vizsgálatot az ellenőrző eszköz kiszolgálói oldalon végzi el, és azonnal eredményt szolgáltat.

Az X-Frame-Options a hagyományos fejléc: a DENY teljesen megtiltja az ágyazást, a SAMEORIGIN csak azonos eredetű oldalak engedélyezésére szolgál, az ALLOW-FROM viszont mára már elavult a modern böngészőkben. Ha a fejléc hiányzik, a régebbi szabályok nem korlátozzák az ágyazást.

A Content-Security-Policy frame-ancestors direktívája a modern váltója. Ez felsorolja azokat az eredeteket, amelyek beágyazhatják az oldalt – például: frame-ancestors 'self' https:\/example.com. Az * érték (vagy egy nyers séma, például https:) bármilyen HTTPS szülőoldalt engedélyez; ennél szűkebb beállítás esetén pedig tiltja a külső oldalak ágyazását.

A válaszfejlécek önmagukban nem adnak teljes képet: az oldalkódok futtathatnak frame-busting kódot (amely például a top !== self ellenőrzéssel kényszerít átfelé navigációt), és a belépési oldalak vagy regionálisan korlátozott végpontok eltérően kezelhetik az adatközpontból érkező lekéréseket. Ezért minden ellenőrzési eredményt élő előnézettel egészítünk ki.

Gyors útmutató: a válaszfejlécek beállításai

Ha a webhely az Öné, közvetlenül a válaszfejlécek segítségével irányíthatja az ágyazást.

Az ágyazás blokkolása bármely oldalról

X-Frame-Options: DENY Content-Security-Policy: frame-ancestors 'none'

A böngészők nem jelenítik meg az oldalt egyetlen iframe-ben sem – ez a legszigorúbb védelem a clickjacking-kkel szemben.

Csak azonos eredetű oldalak ágyazásának engedélyezése

X-Frame-Options: SAMEORIGIN Content-Security-Policy: frame-ancestors 'self'

Csak az azonos sémájú, hosztú és portú oldalak ágyazhatják be; a külső oldalak blokkolva lesznek.

Csak kijelölt eredetű oldalak ágyazásának engedélyezése

Content-Security-Policy: frame-ancestors 'self' https:\/trusted.example.com

Sorolja fel a megbízható eredeteket a frame-ancestors direktívában; a listán nem szereplő eredetek blokkolva lesznek.

Bármely oldal ágyazásának engedélyezése

Ne állítson be X-Frame-Options fejlécet Content-Security-Policy: frame-ancestors *

Bármely oldal betöltheti iframe-ben. Mielőtt alkalmazná, mérlegelje a biztonsági kockázatokat.

Megjegyzés: A CSP frame-ancestors direktívája felülírja az X-Frame-Options-t. Ha mindkettő szerepel, a CSP érvényesül – így a frame-ancestors használata az ajánlott.

Hogyan észleli a szerver, hogy a kérés iframe-ből érkezik?

2020 tájékától kezdve a Chromium- és Firefox-alapú böngészők automatikusan hozzácsatolnak egy Fetch Metadata kérésfejlécek csoportját minden navigációs és részleges erőforrás-kéréshez. A keréklépés-ellenőrzések szempontjából a legfontosabb ezek közül a Sec-Fetch-Dest – ez jelzi a kiszolgálónak, milyen környezetből történt az erőforrás-lekérés, a kérő oldal bármiféle közreműködése nélkül.

  • Sec-Fetch-Dest: document – Elsődleges navigáció, nem helyezkedik el egyetlen keretelemen belül sem.
  • Sec-Fetch-Dest: iframe – A kérés egy <iframe> elemen belül töltődik be.
  • Sec-Fetch-Dest: frame – Betöltődik egy elavult <frame> (frameset) elemen belül.
  • Sec-Fetch-Dest: embed / object – Betöltődik egy <embed> vagy <object> elemen belül.

Ez a vizsgálóeszköz egy saját próbakérést küld Sec-Fetch-Dest: iframe fejléccel, pontosan úgy, ahogy azt egy valós böngésző teszi oldalbeágyazásnál – így az eredmény azt mutatja, hogy a célkiszolgáló ténylegesen hogyan viselkedik igazi iframe-kérések esetén, nem pedig egy általános lekérdezésre.

A Sec-Fetch-Dest hasznos jelzés, de nem biztonsági gát: kizárólag a modern böngészők küldik, míg a nem böngészős kliensek (curl, botok, egyes webview-k és régebbi böngészők) akár teljesen ki is hagyhatják, vagy önkényes értéket küldhetnek. A kiszolgálónak érdemes ezen alapuló naplózást vagy sebességkorlátozást alkalmaznia, azonban soha ne ezt használja kizárólagosan a keretezés biztonságának eldöntésére; ehelyett az X-Frame-Options és a CSP frame-ancestors szabályok irányítanak, amelyeket a böngészők a kérésfejléctől függetlenül, önállóan érvényesítenek.

Oldalnézetben az oldal fejlécek nélkül is felismerheti, hogy kereten belül fut – például a window.top !== window.self összehasonlítással (vagy a window.frameElement értékének olvasásával azonos eredetű keretek esetén), majd ebből következően tehet lépéseket: megjeleníthet egy figyelmeztetést, vagy kényszeríthet egy felső szintű átirányítást. Ez az előbb említett frame-busting technika, amely minden kérésfejléc-tartalomtól függetlenül működik.

Szerverkonfigurációs példák: iframe beágyazás letiltása

Az alábbi kód-részletek azt mutatják be, hogyan kell konfigurálni az egyes szervereket vagy keretrendszereket az iframe ágyazás teljes letiltásához (X-Frame-Options: DENY + CSP frame-ancestors 'none'). Ez a legmagasabb biztonságú módszer a fenti gyors útmutatóban szereplő lehetőségek közül.

server {
    location / {
        add_header X-Frame-Options "DENY" always;
        add_header Content-Security-Policy "frame-ancestors 'none'" always;
    }
}
<IfModule mod_headers.c>
    Header always set X-Frame-Options "DENY"
    Header always set Content-Security-Policy "frame-ancestors 'none'"
</IfModule>
app.use((req, res, next) => {
  res.setHeader('X-Frame-Options', 'DENY');
  res.setHeader('Content-Security-Policy', "frame-ancestors 'none'");
  next();
});
// next.config.js
module.exports = {
  async headers() {
    return [
      {
        source: '/:path*',
        headers: [
          { key: 'X-Frame-Options', value: 'DENY' },
          { key: 'Content-Security-Policy', value: "frame-ancestors 'none'" },
        ],
      },
    ];
  },
};
class SetFrameOptions
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);
        $response->headers->set('X-Frame-Options', 'DENY');
        $response->headers->set('Content-Security-Policy', "frame-ancestors 'none'");

        return $response;
    }
}
export default {
  async fetch(request) {
    const response = await fetch(request);
    const headers = new Headers(response.headers);
    headers.set('X-Frame-Options', 'DENY');
    headers.set('Content-Security-Policy', "frame-ancestors 'none'");
    return new Response(response.body, { status: response.status, headers });
  },
};

Ha csak a saját webhelyét vagy egy rövid engedélyezési listát szeretné engedélyezni az ágyazáshoz? Cserélje ki a DENY-t SAMEORIGIN-re, a „none”-t pedig „self”-re (vagy egy konkrét lista a megengedett eredetekről) – a konfiguráció többi része változatlanul marad.

Ismert technikai buktatók

Az általános fejlécsszabályokon túlmenően számos közismert platformnak megvannak a sajátos sajátságai – érdemes ismeretre szerezned róla, mielőtt csupán a fejlécek alapján blokkoltnak vagy beágyazhatónak ítélnél egy oldalt.

Platform / forgatókönyv Viselkedés Indoklás
YouTube videólekérési oldal (youtube.com/watch) Blokkolt Használd helyette a hivatalos youtube.com/embed/{id} lejátszó URL-t – a normál videonező oldal korlátozó keretezéspolitikát alkalmaz.
Google Maps helyszínoldalak Blokkolt Csak a Maps Embed API iframe URL-je (google.com/maps/embed) alkalmas keretezésre.
Google / Microsoft OAuth belépőoldalak Blokkolt Szándékosan blokkolva 2015-től kezdve a jelszólopás (credential phishing) ellen iframe környezetben; a belépési folyamatot mindig teljes ablakban vagy felugró ablakban kell végrehajtani.
Fizetési rendelési oldalak (Stripe Checkout, PayPal, legtöbb banki átjáró) Blokkolt A fizetési űrlapok keretezése klasszikus klikkcservész (clickjacking) támadási vektor, ezért a fizetési szolgáltatók ezt kategorikusan megtagadják.
GitHub tároló- / fájloldalak Blokkolt A teljes oldalra érvényes frame-ancestors 'none' szabály; használd a REST/GraphQL API-t vagy egy képernyőképet iframe helyett.
Notion / Google Dokumentumok „Közzététel a weben” oldalai Beágyazható Kifejezetten beágyazásra tervezve, és a termék maga is előre elkészített beágyazási kódot biztosít.
Wikipédia szócikkek Beágyazható Alapértelmezés szerint nincs korlátozó X-Frame-Options/CSP, de tömeges beágyazás előtt mindenképp ellenőrizd a licenc- és hivatkozási feltételeket.

Gyakori felhasználási esetek

  • Döntsd el, hogy egy külső widget, műszerfal vagy dokumentum beágyazható-e a saját termékedbe, mielőtt az integrációs kód megírása neki kezdenél.
  • Ellenőrizd, hogy a saját oldalad valóban a tervezett X-Frame-Options vagy CSP frame-ancestors politikát ad-e vissza.
  • Clickjacking-védelem hibakeresése: derítse ki, miért jelenik meg egy oldal iframe-en belül about:blank címként vagy tiltóüzenetet.
  • Jelölt URL-ek kötegelt ellenőrzése tartalomaggregálás vagy portálintegráció során, a munkamenet-előzmények használatával az eredmények későbbi visszakereséséhez.
  • Biztonsági auditok vagy penetrációs tesztek előkészítése a külső függőségek keretrendezési (iframe) szabályzatának dokumentálásával.

GYIK

Miért marad üresen a „Beágyazható”-ként jelölt oldal az előnézetben?
A válaszfejlécek engedélyezik a beágyazást, de az oldal valószínűleg JavaScript kerettörés (frame-busting) kódot tartalmaz, bejelentkezést vagy cookie-kat igényel, illetve a látogató profiljától függően eltérő tartalmat szolgál ki. Bízzon az előnézetben.
Felülírhatók vagy megkerülhetők az X-Frame-Options és a CSP fejlécek?
Nem. Ezeket a fejléceket a böngésző biztonság érdekében (clickjacking-védelem) kényszeríti ki; az ügyféloldali megkerülő megoldások nem megbízhatóak. Ha olyan tartalmat szeretne beágyazni, amelynek kezelésében nincs része, kérje meg a weboldal tulajdonosát, hogy engedélyezze az eredetét (origin) a frame-ancestors fejlécben, vagy használja a általuk biztosított hivatalos beágyazási/API megoldást.
Mi a különbség a DENY és a SAMEORIGIN között?
A DENY letiltja az oldalt minden iframe-ben, beleértve az azonos forrású oldalakat is; a SAMEORIGIN csak azoknak az oldalaknak engedélyezi a beágyazást, amelyek ugyanarról a protokollról, gazdagépéről és portjáról származnak.
Tárolja az ellenőrző az URL-jeimet?
Az előzmények kizárólag a saját böngészőlapon belül, a sessionStorage-n keresztül tárolódnak, és megszűnnek, ha a lap bezárul. Az ellenőrző szerver csupán a kért URL-t hívja meg a válaszfejlécek lekérdezéséhez.
Miért ad ugyanaz az URL eltérő eredményeket különböző időpontokban?
A webhelyek elérési útvonalonként, átirányítások után, a User-Agent alapján, vagy A/B teszteken és WAF-szabályok miatt eltérő fejléceket küldhetnek. Futtassa újra az ellenőrzést a legfrissebb állapot lekérdezéséhez.