Az alforrás integritása egy másik problémát old meg

[asikurrahmanshuvo]

Ahogy el tudja képzelni, ez az engedélyezési lista meglehetősen hosszú lesz. Vegyük connect-srcpéldául a Google Analytics hozzáadását az irányelvhez : a Google maga azt javasolja , hogy „minden Google felső szintű domaint (TLD) külön kell megadni, mivel a CSP szintaxis nem teszi lehetővé a helyettesítő karakterek használatát a gazdagépnév jobb oldalán”. Ez a számú Google-domain hihetetlenül hosszú (187 a cikk írásakor!), és ezt ajánlják egyetlen szolgáltatás támogatására. Minden külső erőforrást, amelyet a webhely elér, rögzíteni és dokumentálni kell, különben nem töltődik be – ez szigorú tervezés. Ennek eredményeként a fejlesztők félnek eltávolítani a tartományokat erről a listáról, ezért ez egy csak hozzáfűzhető szabálylistává válik (hasonlóan egy globális stíluslaphoz!). Ráadásul ez a hosszú engedélyezési lista minden válaszban szerepel , amikor statikus fejlécként szolgálják fel, növelve ezzel a kérelmek teljes méretét és kilépését.

Sok vállalat megpróbál CSP-t telepíteni, de soha nem jut túl a CSP-RO szakaszon – köztük mi is! Megpróbáltunk kényszeríteni egy CSP-t a Netlify platformon , de ez soha nem vált át Report-Only, mert 1) az új domainek legutóbbi mobiltelefonszámadatok engedélyezési listára való jóváhagyásának munkafolyamata túl nehézkes volt , és 2) nem voltunk biztosak abban, hogy az összes engedélyezett domaint rögzítjük javasolt engedélyezési listánkat.

Talán hallott már az alforrás integritásáról (SRI). A szkriptcímkék tartalmazzák az integrityattribútumot, amelynek értékének meg kell egyeznie az erőforrás tartalmának kivonatolt értékével, ellenkező esetben a böngésző megtagadja annak végrehajtását. Az alforrás integritásának hash statikus/determinisztikus; vagyis az érték nem változik, hacsak a tartalom nem változik.

Az SRI megvalósítása azonban csak akkor hasznos, ha harmadik féltől tölt be parancsfájlokat. Biztos akar lenni abban, hogy a letöltött tartalom – például egy verziószámú könyvtár – nem változik (akár rosszindulatúan, akár véletlenül). Ezenkívül előre ki kell számítania a sha értékét, és ezt az értéket be kell kódolnia a HTML-be, hogy az hatékony legyen.

Amit az SRI nem tesz, az az, hogy megakadályozza a webhelyek közötti parancsfájl-támadásokat (XSS). Ha webhelyén felhasználók által generált tartalom található, vagy űrlapokból vagy lekérdezési paraméterekből gyűjti be a felhasználói adatokat, akkor a frontend fejlesztőinek több lépést kell tenniük annak biztosítására, hogy a rosszindulatú bevitel ne tegye lehetővé szkriptek beillesztését az oldalra. . A modern keretrendszerek, mint például a React, védőkorlátokat alkalmaznak ennek megakadályozására, de vannak olyan használati esetek (különösen a leértékelés HTML-be való megjelenítése), amikor a nem megtisztított jelölés utat találhat az ügyfélhez.