Fórumok
Hát arra, hogy elég egyetlen ponton megnyomni, és máris többezer honlapot lehet megfertőzni általa. Most pont ez történt a polyfill.io-val. Ha valaki használja ezt a CDN-t, sörgősen álljon le vele.
https://sansec.io/research/polyfill-supply-chain-attack
A cloudflare persze próbál úgy csinálni, mintha nem az ő saruk lett volna a CDN-ek hájpolása úgy eleve; na nem mintha egy single point of failure lecserélése egy másik single point of failure-re bármit is javítana a helyzeten...
https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-w… (sic!)
Már nagyon várom, mikor fogja valaki felnyomi a cloudflare-t és egycsapásra megfertőzni millió honlapot!
Hozzászólások
Az nem a technológia hibája, hogy más által elérhetővé tett fájlokat boldog boldogtalan használ. CDN-t úgy is lehet használni, hogy a saját asseteid elérését gyorsítod vele, hogy több régióban is megfelelően gyors legyen az oldalad.
Mire jó az internet? Hát arra, hogy elég egyetlen ponton megnyomni, és máris többezer honlapot lehet megfertőzni általa. Ha valaki használja az internetet, sörgősen álljon le vele. :D
https://iotguru.cloud
mire jo a bicikli kerek? hat arra, hogy eleg egy helyen kiszurni es maris leereszt... :)
neked aztan fura humorod van...
The internet is for porn.
Bárcsak arra lenne, de a hülyeségek terjesztésére jobban alkalmas :(
https://www.youtube.com/watch?v=kV7ou6pl5wU
A strange game. The only winning move is not to play. How about a nice game of chess?
?
Mi ez az elferizett muppett só?
anthem of the internet XD
A linux nem érintett ahogy látom. No problem. :)
"Sose a gép a hülye."
Barki hasznalhat 1-nel tobb CDN-t egyszerre (mi pl 4-et 5-ot), hogy lesz ebbol SPoF?
Hogy töltöd be ugyanazt a jslib-et egy html oldalon belül 1-nél több cdn-ről?
Hát nem nyilvánvaló? Ha lerohad a cloudflare pl., akkor egycsapásra több millió oldal nem fogja tudni betölteni a js szarját és elérhetetlenné válik.
A vps-ről nyújtott Vér István Bt. szolgáltatása pöpec, de a Cloudflare az SPoF? Globálisan nagyon sok adatközpontból hálózati eszközök és gépek tízezreiről nyújtanak nagyon elosztott nagyon hibatűrő szolgáltatást. És semmi nem tart vissza hogy egynél több CDN-t sorolj fel a DNS rekordban, ha félsz attól, hogy a CF letérdel.
Tudok még pár védendő elemet:
Hiszed Te, én sosem mondtam ilyent.
Igen, pontosan ugyanúgy, ahogy a polyfill is az.
Ezt HTML-ből...? Vagy Vér István Bt. által gondoltad?
És ez a DNS hogy véd meg az ellen, hogy valaki felnyomja a cloudflare-t és fertőzött js-ekkel pakolja tele? Pont mint ahogy itt most történt a polyfill-el? Azt hiszed, egy DNS rekord megvéd ettől?
Na várj, itt két különböző architektúra elemről beszélünk.
A CDN egy elosztott cache réteg, ami mögött van egy tartalom szolgáltató (webszerver), ami felelős azért, hogy mi megy kiszolgálásra és az milyen cache policy mellett.
Az, hogy a külső függőségeidről csinálsz e másolatot a saját webszerveredre vagy sem, az egy független probléma attól, hogy skálázási vagy DDoS védelmi szempontból raksz e elé CDN-t.
A polyfill egy ügyes, de security szempontból eredetileg is igencsak megkérdőjelezhető szolgáltatással állt elő, a "webszerverén" módosított js verziókat készített röptében, amiket egyébként a Cloudflare-en mint CDN-en keresztül terített, ezért tudta a CF URL rewrite-tal kidobni őket
Szerintem nem cloudflareen hostolták, és a CF szolgáltatása annyira, hogy ha az én oldalam CFen van, akkor onthefly átírják a polyfill includeot úgy, hogy a polyfilles cdn helyett a CloudFlarees cdn legyen az ügyfélnek küldött htmlben.
Lehet, de közben komoly sárdobálás van a két cég közt, mert a polyfill simán azt reklámozta hogy a Cloudflar partner a szolgáltatásában, ezt a CF tagadja
Multi-CDN-re ha rakeresel biztos talalsz erre peldat, de valoban tenni kell azert, hogy mukodjon a te cuccoddal is.
Ki mondta, hogy a CDN egy biztonsági megoldás? Te magad írod, hogy:
Vagyis a CDN nem javít, de nem is ront a biztonságon. Tessék használni subresource integrity ellenőrzést, pont erre találták ki.
Hogyne rontana. Behoztál egy plusz függőséget a képbe, amire semmi kihatással sem tudsz lenni. Ha elmegy a cdn, vagy ha lecserélik az ott tárolt jquery-t egy fertőzöttre, akkor megszívtad úgy is, hogy a szerveredet fel sem kellett törni.
Pontosan ez történt most a polyfill-el, és a couldflare-el is bármikor megtörténhet.
No. Azért válasszuk szét, hogy "megtörik a CDN-t" vagy bekerül az origin/source részre egy malware terjesztő, és a CDN oldal értelem szerűen nekiáll cache-elni. Az mennyivel jobb amikor hasonló logikivál nyílt forrású csomagforrásban rejtenek el eztazt (megtörtént nemrég), és minden Linux disztró átveszi.
Csak ez akkor nem segít, ha a html-t is a CDN-ben szeretnéd tárolni.
mire jo a viz? hat arra hogy szociopata meszarosok beledobjak a megeroszakolt nok hullait....persze masra is, de most arrol beszelunk hogy a viz ocsmany szar dolog :D
Amikor donteni kell, hogy sor/bor/palinka VAGY viz, mindig jusson eszedbe, hogy melyikben basznak a halak... :-)
Én két részre választanám. Van, amikor általános fájlokat (JS könyvtár, ikonkészlet, betűtípus, ..) nem letöltesz és saját szerverről szolgálsz ki, hanem külsős CDN-ről hivatkozod be. Ez szerintem csak arra jó, hogy a CDN kiszolgálója nyomon tudjon követni, valószínűleg ezért is nyomják nagyon mindenhol. A másik 'előnye', hogy úgy lehet pl. egy WP-s oldalba behúzni sok millió függőséget, hogy nem kell fájlokhoz nyúlni, nem kell programozni, csak Ctrl+C és Ctrl+V és már működik is :)
Ill. van az az eset, amikor jelentős forgalmat bonyolít egy weboldal, és a statikus tartalmakat (JS, CSS mellett nem változó képek is pl.) területileg elosztva, több szerverről szolgálnak ki. Ezzel skálázhatóbbá válik a rendszer és költséghatékonyabb is, személy szerint ennek látom értelmét, de ezzel tényleg csak komoly forgalom esetén van értelme foglalkozni.
Igen, pontosan erre van, minden más csak parasztvakítás ls ködösítés.
Semmivel sem lesz lassabb a honlap, ha a js-t ugyanonnan tölti le a böngésző, mint a html-t és nem pedig egy harmadik féltől. Sőt, CDN-hez újabb tcp csatornát kell kiépíteni, míg a helyben tárolt js jöhet ugyanabban a csatornában is. (Az esetleges szerverközpontok közötti latency meg egyébként is annyira minimális manapság, hogy egy átlaguser észre sem veszi, EU-s szerverről vagy USA-beli szerverről töltődött-e be a jquery.js...)
A tudomány fejlődésével már a fény is gyorsabb, vagy sikerült teret görbíteni, hogy közelebb legyenek egymáshoz?
A CDN láthatóan nem való neked, de mindenki másnak igencsak hasznos.
Neked milyen szolgáltatásnál hasznos? Mennyire vannak más kontinensről usereid?
Az összes munkahelyem globálisan szolgáltatott, így nagyon hasznos és nagyon vannak felhasználók más kontinensről. Persze volt, hogy külső szolgáltató nélkül kellett összerakni - irgalmatlan drága és elméleti esély sincs a közelébe érni.
A nem static fileokat, pl API hívásokat, cachelve szolgálta ki a CDN (nyílván amit lehet), vagy arra várniuk kell a usereknek többet?
Jól használni CDN-t gondolkodásmód váltást is igényel.
API: általában 2-es csoport, amennyiben nem tudod szűrni WAF-on, akkor kell egy olcsó megoldás fail fast-ra, azaz tudd még azelőtt eldobni az érvénytelen kérést, mielőtt drága komponenst (db) elér. Ez GET-re jól működik.
POST-ot kerüld, ha lehet, az általában a 3. csoportba esik
Érdemes megnézni a network nézetet néha. A CDN-es cuccok van hogy HTTP3-on jönnek le, ott nem is TCP a protokoll. (Nekem saját szerveren még nem sikerült összerakni a HTTP3-at, igaz nem is próbáltam.) És elképesztő sebessége van a CDN-eknek. Én egy Magyarországon működő VPS-en hosztolt oldal esetében mértem a latencyt és a CDN elképesztő gyors volt. Ennek ellenre átírtam helyben hosztoltra mert én sem vagyok CDN párti, de a teljesítménye el kell ismerni, hogy nagyon jó tud lenni.
De ami sokkal durvább, hogy skálázód DDOS elleni védelmet nem tudsz CDN nélkül csinálni. Ezt nem úgy értem, hogy te nem tudsz, hanem hogy általános alany sem tud, bizonyos méret alatt nem lehet megcsinálni. Ha betámadnak, akkor csakis valamelyik ilyen szolgáltató tud kihúzni a szarból AFAIK. De aki jobban ért hozzá javítson ki, ha nem így van!
a DDOS hogy mukodik? ugyanugy mint ahogy a bongeszo letolti az oldalt? eloszor az index.html-t, majd az abban linkelt eroforrasokat? vagy csak az index.html-t tolti le, de a benne linkelt eroforrasokat nem?
neked aztan fura humorod van...
inkabb megkeresik a JS kodban a leglassabb REST hivast es azt terhelik
Dehogynem. Konkrétan üzemeltettem ilyent, egy munkahelyen pedig én terveztem az egész rendszert. Nemzetközileg ismert projekt, ami új verzió kiadásakor irdatlan forgalmat szokott kapni, viszont biztonságtechnikai okokból elfogadhatatlan, hogy máshonnan osszák a binárist. Megoldottuk, simán. Nem olcsó nyilván, de a cloudflare sem az, csak ott az adataiddal kell fizetni.
Kis pályán működik. Veszel egy nagyobb kapacitású DDoS védelmi eszközt, mint amekkora az internet madzagod, és örülsz mindaddig, amíg valójában nem leszel célpont. Utána esélyed sincs.
Nézd meg ebben a cikkben a számokat és nézz utána mekkora vassal védted volna ki:
https://www.bleepingcomputer.com/news/security/cloudflare-mitigates-rec…
Saját vas elfogyási sorrend:
Eleve ott bukik a dolog hogy az ISP-d fog lekorlátozni, hogy a saját infráját megvédje ha tényleg komolyra fordul a dolog.
Nyilván lehet ISP-vel együttműködő DDOS védelemet is kialakítani Blackhole, BGP Flowspec stb, vagy magától az ISP-től venni szolgáltatásként. De a Cloudflare a végén mindig nagyobb lesz :)
LOL. :-D Az egyik garantáltan a legnagyobb forgalmú magyar infrastruktúra, a másik pedig egy nemzetközileg ismert és használt biztonságtechnikai megoldás oldala... Kispálya mindkettő, ja... :-D
"garantáltan a legnagyobb forgalmú magyar infrastruktúra"
Ez esetben dolgoztunk együtt, és továbbra is fenntartom, hogy bármekkora itthon fellelhető vaskupac kispálya a CF képességeihez képest. Nem olvastad el a cikket amit fent linkeltem, nem létezik akkora vas a piacon (nem csak itthon), ami ekkora számokat akár csak nagyságrendileg közelít.
Tehat csinaltatok egy sajat CDN-t?
Érted azt a koncepciót, másvalaki jóindalától függsz, és hogy ez miért nem túl biztonságos?
tudnal irni a megoldasrol? persze csak ami nem titok.
neked aztan fura humorod van...
Mi van akkor, ha van mondjuk egy CSS/JS library, aminek minden verziojat ugy szazmillio weboldal hasznalja? Honnan toltodik be a .js fajl, amikor a masodik/n-edig olyan weboldalt nyitod meg, ami ugyanarrol a CDN-rol toltene le ugyanazt a fajlt? Es honnan, ha az n-edik weboldal toltene be a sajat domainjerol?
Sokan szkeptikusok itt, de ez a polyfill.io dolog nagyon nem vicc.
Rengeteg, tényleg rengeteg weboldal megy így hogy mindenféle publikus CDN-ekről importálnak JavaScript kódokat a Jquery-től a Bootstrap-en keresztül a polyfill.io-ig.
A polyfill.io-t most megvette egy kínai cég és a HTTP kérés fejléceitől és ki tudja még mitől függően dinamikusan generált polyfilleket tol a böngészőknek.
A polyfillek lényege, hogy régi böngészők is tudnak újabbakra írt Javascript kódokat futtatni. Ez szép dolog, de a polyfill.io most azt csinálja, hogy a saját kódjait injektálja mindenféle függvényekbe.
Gyakorlatilag akár le is logolhatnak minden billentyűlenyomást, oda irányítanak, ahová akarnak, stb. És meg is teszik.
Szerk: szerencsére a domain szolgáltató már letiltotta a nevet, de ez hónapokon keresztül ment így.
Nem, ez egy tényleg szörnyű eset volt, de semmi köze a CDN vagy nem-CDN vitához. Ennek ahhoz van köze, hogy hard külső függőség forrás rendszereként miben bízol meg
"A polyfillek lényege, hogy régi böngészők is tudnak újabbakra írt Javascript kódokat futtatni." - Nem kéne minden marhaságot észnélkül használni, telepíteni, include-olni, bepakolni. Az N+1 függőség semmilyen módon nem nyerő, dehát ugye a kényelem, és hát működnie kell. Nem KELL működnie, hanem hát szeretnénk, hogy az amúgy igencsak sebezhető régi/régebbi böngészőkkel működjön. Ügyes....
IE idején egy rémálom volt Javascript kódot írni a rengeteg inkompatibilitás miatt.
Ezt a polyfillek vagy a jquery vagy framework-ök használatával lehetett áthidalni.
Ma már ezekre semmi szükség, ettől függetlenül rengeteg régi weboldalon még mindig ott vannak. Ráadásul sok fejlesztő a mai napig használja ezeket új fejlesztésekben is.
Igen, sokan nem értik itt, mi is a baj. Nem az én dolgom az IT biztonságtechnológiai kikupálásuk, úgyhogy használjanak csak CDN-t, no meg persze felhős jelszómenedzsert is! Sok sikert!
Nem véletlenül írják a legtöbb CDN-nél így a kódot:
Ha felnyomják a CDN-t, max. addig nem működik az oldal, de mást nem tudnak vele csinálni.
Én még a saját szerverről betöltött JS és CSS fájlok esetén is kitöltöm az integrity mezőt, mert ha a tudtomon kívül változik a jquery kódja, az akkor is baj, ha én hostolom.
Nagy Péter
Idővel lesz sha256 collision is... Alapból az ötlet rossz, ez meg egy temporary fix.
Es a collisiont okozo script nemhogy ertelmes JS lesz, hanem pont azt fogja csinalni, amit a tamado szeretne.
https://hup.hu/node/126869
Ezt nem teljesen értem.
Arra számítunk, hogy idővel valaki olyan JS fájlt fog feltölteni az eredeti helyére, aminek ugyanaz az SHA256 értéke, és közben a benne lévő kód meg azt csinálja, mint amit a támadó szeretne?
(egyébként sha-384-et, és sha-512-őt is lehet használni az integrity mezőben, itt egy rövid leírás, hogy érdemes használni)
Az ötös lottón nyerni 1 a 43,949,268-hoz eséllyel lehet. Annak, hogy valaki két azonos SHA-256 összegű fájlt készítsen, de eltérő tartalommal; az ötöslottó nyerési esélyéhez képest 1.29 × 10 a -32-ediken esélye van. Tehát ha minden alkalommal, amikor lottózol, készítesz egy ilyen js fájlt, akkor minden alkalommal, amikor nyertél a lottón, 0.0000000000000000000000000000000129% esélyed van, hogy a JS fájl SHA256 értéke is azonos lesz az elvárttal. A legtöbb weboldal esetében ez már az elfogadható kockázat szintjén van, általában ennél nagyobb eséllyel talál valaki véletlenül olyan programhibát a kódban, amivel a saját szervereden módosíthatja az oldal kódját.
Nagy Péter
Ha csak simán használod a fájlt a saját szervereden, ezeken el sem kell gondolkodnod.
Mi van, ha nem megy a CDN vagy lassú? Mi a helyzet a privacyvel? Mi van, ha a CDN elkezd böngészőhibákat kihasználni? A SHA-256 elég secure-e még ma is? És 10-20-30 év múlva az lesz-e? Vagy ez lesz az ultimate hash függvény az életünkben?
A lottós példa szerintem kicsit sántít, mert nem kvázi végtelen erőforrással lottózol.
Ha csak simán használod a szervereden a fájlt, akkor is érdemes elgondolkodni az SHA-n, mert nem csak a CDN-t, de a saját szervert is meg tudják törni.
Ha az erőforrásokat helyben is ellenőrzi a böngésző, akkor jelentősen több munkát igényel a támadó oldaláról, hogy úgy cseréljen le JS vagy CSS kódot a szervereden, hogy az oldal utána ne dobjon hibákat, ne álljon le, és így ne vegye észre nagyon gyorsan a szerver üzemeltetője.
- A CDN általában megy. Mivel általában redundáns rendszereken van, és van üzemeltetője is, ritkán van nagy leállás benne. Gyakoribb, hogy a saját szerver áll, mint a CDN. Nyilván érdemes olyan CDN-t választani, ami nem szokott leállni, és olyan cég van mögötte, aminek van kapacitása üzemeltetni. Pl. a Google által kiszolgált fájlok esetében 2013-ban volt utoljára leállás, az elmúlt 11 évben működött. Ez jobb SLA, mint amit a legtöbb szerver-hosting cég ajánlani tud.
- A CDN-ről a Jquery-t, vagy társait tölti be a böngésző, ott nem dolgoz fel adatot. Privacy terén ugyanaz a helyzet, mint ha magad hostolod a fájlt.
- Mi van, ha a saját szervered kezd el böngészőhibákat kihasználni? Gyakoribb, hogy nyílt forrású rendszerek kódjába raknak kártékony kódot, ami rátelepül a saját szerveredre rendszerfrissítés gyanánt, mint hogy a CDN böngészőhibát használna ki. (pl. a 2024 márciusában felfedezett XZ Utils backdoor probléma)
- Az SHA-256 még elég secure ma is, de az SHA-512 is választható azoknak, akik nem bíznak benne. Azon weboldalaknál, ahol a következő 10-20-30 évben nem szeretnének a kiszolgált oldalhoz hozzányúlni, ott valószínűleg a böngészők a már a nem kellően biztonságos HTTPS protokol miatt 20 év múlva sem fogják betölteni az oldalt (ahogyan most sem töltik be az SSLv3 oldalakat), így ott a CDN-el kapcsolatos probléma nem fog előbukkanni. Ahol pedig időközben hozzányúlnak a rendszerhez, ott van lehetőség az aktuálisan használatos biztonsági megoldásokat beépíteni a CDN-re vonatkozóan is.
- Ha megjelenik valami ultimate HASH protokol addigra, akkor lehet az lesz az első ultimate megoldás az informatika történetében. Mert jelen pillanatban semmi protokollt, vagy megoldást nem tudnék mondani az informatikában, ami velünk lenne 30 éve, és akkor is a legjobb megoldás lett volna, meg ma is az.
A lottós példát csak azért hoztam fel, hogy érezhető legyen, hogy egy amúgy elég nehezen elérhető cél (nyerni a lottón) is arányaiban mennyire gyakori ahhoz képest, mint hogy két SHA-256 érték azonos legyen eltérő fájlokon. Hasonló eséllyel tud mondjuk egy macska végigsétálni valakinek a billentyűzetén úgy, hogy ezzel egy szoftverhibát kihasználva megtörje a szerveredet. Elméletben nem nulla az esélye, de azért a gyakorlatban erre az eshetőségre nem annyira kell számítani.
Nagy Péter
Ha felül tudja írni a js-t, valszeg akkor a html-t is.
Aha, csak biztos, hogy logolja az ip-t. Küldhet cookiet, etag-et usernek stb. És valamiért mégis buli ezeknek a cégeknek "ingyen" nyújtani ilyet.
Az XZ kiderült hamarabb... De pl amit itt említettek az nem. És valszeg a célzottabb dolgok nem derülnek ki.
A weboldalnak nincs köze ahhoz, hogy a webszerver milyen HTTPS protokollt támogat.
Nem szokott ez annyira megtörténni: https://blog.cloudflare.com/javascript-libraries-are-almost-never-updat…
Meg épp az aktuális projekten talán még le is cserélnék, de mondjuk az elmúlt 20 évben elkészülten biztos nem.
Ingyen??? Eleg sulyos penzeket fizetunk erte, milyen "ingyen"?
Ehhez hasonló dolgokról van szó ebben a szálban. Vagy én ezekre a free js lib hosting dolgokra gondoltam itt CDN alatt.
Powered by Fastly
marketing...
Igen, de míg az első részt (JS-t megkeresni / cserélni) általában egy bot is megoldja, addig a megfelelő fájlokban megkeresni a megfelelő HTML-eket is mind frissíteni sokszor már emberi beavatkozást igényel. Arról nem is beszélve, hogy sokszor csak a weblap HTML-jét frissítgetik a felhasználók (felmásolják a gépükről az aktuális változatot), így a hiba ott máris kibukik.
Cookiet nem tud úgy küldeni, hogy ne tudj róla, hiszen akkor a fejlesztés során már Te is kapnál. IP címet logolhat, de azzal önmagában nem megy sokra.
Az XZ kiderült, de azért nem annál hamarabb, hogy már ne futott volna sok-sok gépen. És ráadásul az sokkal több adathoz férhetett hozzá, hiszen amit a szerver elért adatot, azt el lehetett érni ezen keresztül.
Statikus HTML oldalaknál ez igaz, de azokról jellemzően sok adatot sem lehet lopni egy JS-el. Mármint ami azon van adat, az általában elérhető bárki számára, Egy PHP-s oldalnak viszont már van köze hozzá, személyesen is ismerek olyan céget, aki a PHP 5.2-es rendszerét már nagyon nehezen tudja úgy üzemeltetni, hogy a szerver egyszerre támogassa a nagyon régi PHP-t, és közben menjen vele a napjainkban elvárt SSL is.
Félreértés ne essék, ilyen random generált külső JS-t én sem hívnék be az oldalba, de azért egy nagyobb CDN szolgáltatótól egy kellően biztonságosan behívott jQuery szerintem a gyakorlatban nem sok biztonsági kockázatot hordoz.
Nagy Péter
Nem hiszem, hogy aki már egy botot megírt, ne tudná kiterjeszteni a működést egy hash cserére 5 perc alatt.
Nem tudhatod, mikor, hogy mit, nem a tiéd a szerver.
Productionbe nem került ki, úgy tudom.
Talán erről beszélünk, hogy ne azt a megoldást válaszd, ami lehetséges, hogy el fog avulni egyszer by design és nincs is hozzá frissítési mechanizmus jelenleg.
bzt megint megmondta a tutit...
szerintem TD;LR:
szóval, az a "baj", hogy van egy lib, amit rengeteg weblap használ. Erről sok mindent lehet olvasni, lényeg, hogy valami kínai tulajdonos kezébe került és már sokszor felmerült a malware gyanú meg ilyenek, hogy "bug-reportok" eltűntek a githubból, stb.
szóval, eléggé úgy tűnik, hogy egy elég komoly problémáról beszélünk.
És, hogy a cloudflare-nek az anyja kínja, mert megpróbálta a problémát mérsékelni. Azt a problémát, amit végül úgy oldottak meg, hogy a domain le lett tiltva a domain registrar által.
Ebben az esetben privacyról és annak megsértéséről beszélni (a cloudflare részéről) kb. olyan, mint hogy a túszejtőt ne nyírjuk ki, mert ölni illegális.
Szóval a Namecheap az jócég, a Cloudflare az rosszcég. Értem.
de kövezzetek meg...
Felültél a bullshitnek te is. A gond amit említettem pont az, hogy valójában egyáltalán nem mérsékli a problémát, ez egy szemenszedett hazugság, aminek te is bedőltél. Biztonságtechnikai szempontból az, hogy külsős A szerverről vagy külsős B szerverről jön-e, tökmindegy.
A CF bele tudott nyúlni, hogy ne fertőzött cucc menjen. Ez most nemjó?
A B probléma, hogy random mindenhonnan külső scripteket húznak be. Elég egy ISP DNS-ét valahogy rávenni, hogy ezekre a belinkelt scriptekre egy malware-es IP-t mondjon. Semmi CDN nem kell ehhez, ezek technikailag külső linkek, és leginkább a fejlesztői kényelem miatt terjednek.
Meg azert, hogy csokkentsuk az egress halozati forgalmat + koltsegunket.
Egy néhány kbájtos JS pláne tömörítve az igen kevés helyen számít. Ahol számít, ott a saját cucc elé behető CDN, immár valódi feladattal.
Mondjuk amikor 1MB JS-t húz be egy html oldal, azért meg szintén fejfogós...
eleve nem értettem, hogy miért cdn-ezik. Amikor külső forrásból hivatkozott js-ről van szó, ami bárhol lehet.
Eleve rossz gyakorlat verzió nélkül hivatkozni változó bármit. A már említett integrity is jó ötlet. És egyébként nem a vadvilágban hanem saját kiszolgálón érdemes tárolni a saját szolgáltatás libjeit. Az persze lehet saját cdn előfizetés alatt.