Názory k článku Bezpečnější web s hlavičkou Content Security Policy
-
NULL (neregistrovaný)
No, ono ten content security policy a same origin (to v článku myslím není) nejsou tak úplně prohlížeči podporovány zas tak dlouho (pokud vím teda) a hlavně vebařinu dělá kde kdo na koleni, rekvalifikanti a třeba lidi, které by Cčko svou striktností přivedlo do blázince. Už jsem i viděl, že se proměnné, jejich hodnoty a error stavy neošetřovaly a nechalo se to na debug = false, čili na produkci to nejde vidět a zbytek se přeskočí na další část :-)
-
j (neregistrovaný)
Jenze tady nejde o to co umi browser, de o to, ze jakmile naprosto cokoli nacitas odnekud zvenku, tak je bezpecnost tvyho webu presne 0. Nemas zadnou moznost ovlivnit, co se vlastne nacte.
To ze to jako bonus delaj patlalove, je spis takova tresnicka ktera to dorazi. Zadna vyjimka neni nacteni 10MB scriptu kvuli 10 pouzitym radkum z nej. A pak se vsichni muzou podelat z toho, ze google nefunguje a snim de dokopru uplne vsechno.
-
NULL (neregistrovaný)
Ale no tak, i kdyby ti to někdo naboural třeba přes zero-day, tak bezpečnost není 0, protože i tak by si na tom nejspíš většina attackerů vylámala zuby. A je taky dost možné, že i kdyby jsi nějakou chybu zveřejnil a neopravil, i tak je dost možné, že by se k jejímu možnému zneužití většina útočníků ani nepropracovala. A taky není nikde napsané, že i když ti nekdo podstrčí něco zvenku, tak že tě úspěšně napadne . . .
-
Filip JirsákStříbrný podporovatelK tomu skriptu, který se načítá z externích adres, je možné připojit hash. Provozovatel té externí adresy pak sice skript může změnit, ale prohlížeč to podle jiného hashe pozná a skript nespustí.
-
j (neregistrovaný)
Jo jasne, a kdyz ten externi script obsahuje jednu radku ktera nacita dalsi externi script, tak bude hash vporadku porad ... jen nikdo nevi, co to vlastne nacita. A vubec uzasne to bude fungovat u vsemoznych dynamicky generovanych zdroju ...
Pricemz podpora toho vseho je taky uzasna ...
-
NULL (neregistrovaný)
S dynamickými scripty je problém, prostě se odevzdává totální kontrola nad obsahem někomu jinému někam jinam. Nemusí jít ani o útok, stačí když se nestahne a JS v browseru pak zkusí něco z toho zavolat. Ale tak dneska je tento způsob moderní, nestaráš se, ne-přikompilováváš do zdroje, jenom hodíš link do hlavičky, resp. patičky a je to, ne? . . . :-D
-
j (neregistrovaný)
2M ... ale ty to prece chces pouzivat, takze to povoleny mit musis, jen proste bezpecnost tvyho webu je 0, protoze nemuzes ovlivnit to, co se tam vlastne bude dit. Klidne to muze delat presne co chces, a za uplnku to muze vsechny tvoje uzivatele treba okrast o login. Pokud budes pouzivat externi zdroje, tak s tim nenadelas nic.
2NULL ... hlavne je free khull a in pouzivat vsemozny megaframeworky, a pak chces po nekom aby posunul ten div o 30% doprava, a on si na to nalinkuje 10MB js. A jeste ti bude tvrdit ze to neni pravda, protoze ten soubor kterej odkazuje ma prece jen MB, protoze tech dalsich 10, ktery to pouziva pri svy demenci nevidi ...
A protoze se frikulinsky musi vsude narvat nocache (psali to tak v tom manualu), tak samo vlastni srv nestiha ... takze proc to nehodit na cizi, ty to zvladnou.
-
Filip JirsákStříbrný podporovatel
Jak už jsem psal výše, co se tam bude dít autor webu ovlivnit může. Zkontroluje, že ten skript dělá to, co po něm chce, a nic jiného, a pak do stránky vloží ten skript i s jeho hashem - takže správce toho externího webu ho nemůže vyměnit bez povšimnutí prohlížeče (změna projde v MSIE, Edge a Safari, ale ty se to časem snad také naučí). Není v tom vůbec žádný rozdíl od skriptu, který budete servírovat ze svého vlastního web serveru.
-
NULL (neregistrovaný)
@Jirsák
Už tě vidím, jak kontroluješ celé jQuery, jestli tam není nějaká bota a s každým patchem měníš hashe. Hodně štěstí a šáteček na cestu. A to si ještě pogratuluj, protože ze starosti, aby tvůj server/y s weby jely 24/7 jsi si přidal starost, aby jely weby tvých externích zdrojů a aby tam vždy byly správné verze a aby jim je nikdo nenapadl. Hurá
-
Filip JirsákStříbrný podporovatel
Už tě vidím, jak kontroluješ celé jQuery, jestli tam není nějaká bota
Když si jQuery nahraju na vlastní servery, tak se ty boty zázračně odstraní? Připomínám, že celou dobu řešíme rozdíl v nahrávání skriptů z externích domén (obvykle z CDN) proti nahrávání z vlastního webu.s každým patchem měníš hashe
Pokud nepoužívám žádný package manager, „s každým patchem“ zvedám verzi tak, že jdu na distribuční stránku jQuery, kliknu na požadovanou verzi a objeví se mi okno s HTML tagem, který stačí vložit do stránky. Například:<script src="https://code.jquery.com/jquery-3.1.1.min.js" integrity="sha256-hVVnYaiADRTO2PzUGmuLJr8BLUSjGIZsDYGmIJLv2b8=" crossorigin="anonymous"></script>
Co myslíte že je snazší – nechat tam ten atribut
integrity, nebo ho pokaždé odmazávat?aby jely weby tvých externích zdrojů
Když neběžel Google, nefunkčnost nějakého webíku opravdu nikoho netrápila.aby tam vždy byly správné verze
Když se objeví odkaz na novou verzi jQuery na CDN, je ta verze v CDN už dostupná.aby jim je nikdo nenapadl
Stačí si porovnat pravděpodobnost, že někdo úspěšně napadne CDN a že někdo napadne můj server. Navíc i v případě napadení toho skriptu v CDN se ten skript nanejvýš nespustí, protože nebude sedět jeho hash. -
NULL (neregistrovaný)
A co je snažší? Použít package manager a zakompilovat si to do vlastních scriptů anebo na pár stovkách webů měnit link v hlavičce? I kdyby jenom na několika desítkách . . .
1) "Když neběžel Google, nefunkčnost nějakého webíku opravdu nikoho netrápila."
Ano, teda až na majitele tech tvých "webíků", kterým tam někdo přilezl třeba přes seznam nebo záložku v browseru. Asi ti ještě nikdy během hodiny nevolalo pár set nasraných majitelů a neposílali tě s nějakým hashem do ... No evidentně tě to čeká. Taky bych se asi dobře bavil, až by jsi třeba v neděli odpoledne sháněl nějakého z programátorů, aby ti přes CI/CD změnil link v hlavičce 200 webů :-))))) Jednou se firmě kde jsem pracoval stalo něco podbného a je to opravdu na ho.no.
2) "Stačí si porovnat pravděpodobnost, že někdo úspěšně napadne CDN a že někdo napadne můj server."
No, řekl bych že CDNka je hodnotnější cíl a pokud si vzpomínám, není to zas tak dávno kdy zrovna servery jQuery byli úspěšně napadeny. Ale vozit se po nich nebudu, to se stát může. To, že můj server není CDNka óóóó velkého googlu nebo jquery neznamená, že jsou děravé jak cedník. Tuhle otázku co je pravděpodobnější bych neřešil.Stát se může oboje nebo ani jedno.
3) "Navíc i v případě napadení toho skriptu v CDN se ten skript nanejvýš nespustí, protože nebude sedět jeho hash."
Ano, není nic lepšího, než když funkčnost tvých webů závisí ještě na nějaké 3. straně jenom tak, na její správnosti a konektivitě k ní. Dále viz.bod 1)
-
Filip JirsákStříbrný podporovatel
Pro package manager je principiálně nemožné použít odkaz na CDN a hash?
Pravděpodobnost, že web nebude fungovat kvůli problémům na mém serveru, je mnohem vyšší, než že nebude fungovat kvůli problémům s CDN. Ano, může nastat případ, že můj web poběží a CDN selže. Ale také CDN doručuje obsah rychleji a nezatěžuje můj server a mou konektivitu. Takže si musíte vybrat, co je pro vás důležitější. No a pokud je pro vás dostupnost vašeho webu tak kritická, stejně ho nebudete provozovat na jednom serveru a stejně budete mít skripty na jiné adrese, ať už to bude vaše privátní CDN nebo veřejná.
-
NULL (neregistrovaný)
Z CDN to leze jak kdy. Ano, vím, principiálně je to rychlejší, relálně jak kdy . . . třeba na mobilu (mobilní připojení) je ideální stahovat co nejvíce věcí a pro každou otevírat nové spojení, ideálně někam do zahraničí ;-)
"Pravděpodobnost, že web nebude fungovat kvůli problémům na mém serveru, je mnohem vyšší, než že nebude fungovat kvůli problémům s CDN"
No, na svém serveru to mám ale ve svých rukou a stejně by mě zajímalo odkud tu statistiku čerpáš.
Třeba za celou dobu, řekněme od kdy už proběhlo kompromitování jQuery serverů a nyní ten Google výpadek jsem neměl výpadek žádný (a děkuji za to . . . ) - to jen tak jako vlastní statistika ale chápu, průkazné to není, ani to není statistický vzorek ale jak toto píšu tak mě to napadlo . . . Každopádně teď s tím googlem už bych jeden měl ;-)
A to se pořád ještě bavíme o Googlu a jQuery - uznávám že kdybych měl něco linkovat z externích zdrojů tak zrovna u těchto dvou bych se bál výpadku nebo nějaké boty (to už teď neřešíme) nejmíňNikde jsem nepsal nic o vlastní CDN. Jen o vlastním zkompilovaném souboru.
Každopádně nevím, na kolik přidání jQuery (88KB) do svého js scriptu zlikviduje konektivitu a jestli je to dobrá výměna za to, že něco na svém webu nemáš pod kontrolou. Samozřejmě, výpadek se stává jenom občas, třeba jako napadený jQuery server nebo výpadek na googlu, nebo DOSy ze zahraničí a blokování zahraničního provozu, ale to přece neznamená, že se na to vykašlu nebo nad tím mávnu rukou . . .
To si o tom myslím a už tímto bezvýznamným dohadováním nehodlám marnit drahocenný čas, ono je to nakonec stejně jedno, každopádně si myslím, že content security policy je dobrý počin, když už to takto někdo linkuje
-
Filip JirsákStříbrný podporovatel
Když já "mít něco ve vlastních rukou" nepovažuju vždy za přínos. Někdy je to lepší, někdy na tom nezáleží, a někdy je to horší. Pomocí hashe skriptu mám ve svých rukou, který skript se nahraje - a tam to "mít to ve vlastních rukou" považuju za důležité. Ale v ostatních ohledech to považuju spíš za nevýhodu, protože provozovatel CDN bude v provozování CDN nejspíš lepší než já.
-
NULL (neregistrovaný)
Ale ty pořád nějak operuješ s tím, že já navrhuji nějakou vlastní CDNku (...provozovatel CDN bude v provozování CDN nejspíš lepší než já....) , ale tak to není. Já si, třeba to jQuery, pomocí package manageru zkompiluji, buď do samostatného min.js souboru a nebo to přikompiluji k nějakému dalšímu min.js a CI/CD to můžu poslat na všechny instance a mám to pod vlastní kontrolou a můžu to mít interně i linkované z jednoho zdroje - nějaké složky třeba a nemusím nikde měnit nic v hlavičkách a pak u 100 webů třeba promazávat page cache - kdyby to bylo potřeba hned a nemusím doufat že server jQuery pojede atd . . .
-
Filip JirsákStříbrný podporovatel
To, že statické soubory nedoručuju přes CDN ale z hlavního webového serveru, je přece součástí toho, že provozovatel CDN je v tom doručování lepší než já. Nejde o to, jaký se použije nástroj, ale jaký je výsledek.
Nerozumím tomu, proč byste něco ručně měnil v hlavičkách sto webů a promazával page cache. Když chcete přejít na novou verzi, tak prostě upravíte cestu k nové verzi, ať už je to zkopírováním odkazu ze stránek projektu nebo přepsáním čísla verze v konfiguraci package manageru. To je všechno.
To, že externí web nemusí fungovat v okamžiku, kdy váš server zrovna funguje, je jediný argument proti externím skriptům. Podle mne je tahle nevýhoda ale vyvážena výhodami poskytování z externích adres - už jenom to, že se zdaleka ne všude používá HTTP/2 a stahování z jiného jména serveru má v prohlížeči samostatný limit na počet spojení, je podle mne dostatečná výhoda.
-
NULL (neregistrovaný)
"CDN je v tom doručování lepší než já"
To je ale tvoje nějaké mylné přesvědčení, že kdo je větší nebo oficiálnější je vždycky lepší než já, ty nebo někdo jiný, přeneseně nazván "obyčejný". To je ale obecný postřeh, ne etalon skutečnosti. Každopádně na můj server se pro mnou nabízený web připojit musí tak i tak. Na CDN nějaké té "super firmy", jak to pořád předhazuješ, musí jenom když to linkuješ. Takže provoz už nezáleží jenom na jednom zdroji a to i na dalším, cizím.
"Nerozumím tomu, proč byste něco ručně měnil v hlavičkách sto webů a promazával page cache"
Evidentně. Třeba proto, že v linku do stránky musíš změnit ten hlavička -> script - hash. . . . . No ale stránku máš v cache. Ano, je pravda že záleží na tom, jak máš cache nastavenou . . .
"Podle mne je tahle nevýhoda ale vyvážena výhodami poskytování z externích adres"
Tak pokud dostupnost webů garantuješ jako "většinou pojede", tak OK. Jo kdybychom se bavili o dynamicky poskytovaném nějakém statickém obsahu, hmmm, tam už bych měl názor jiný.
"už jenom to, že se zdaleka ne všude používá HTTP/2 a stahování z jiného jména serveru má v prohlížeči samostatný limit na počet spojení, je podle mne dostatečná výhoda."
Je možné, že jsi se někde upsal a věta nevyznívá tak, jak by měla?
-
Filip JirsákStříbrný podporovatel
Nepsal jsem, že je v tom CDN vždy lepší – ale je v tom lepší ve velké většině případů. Už jenom proto, že má lepší konektivitu a více distribučních míst, takže je obvykle blíž uživatelům.
Třeba proto, že v linku do stránky musíš změnit ten hlavička -> script - hash. . . . . No ale stránku máš v cache. Ano, je pravda že záleží na tom, jak máš cache nastavenou . . .
Zatímco když to mám na svém serveru, musí se změnit adresa skriptu, tedy se změní stránka a opět se musí stránka znovu načíst. Rozdíl v tom není vůbec žádný.Tak pokud dostupnost webů garantuješ jako "většinou pojede", tak OK.
Když se podíváte na statistiku nedostupnost toho webu, bude to z velké části způsobené výpadky na vaší straně. Pokud budete chtít provozovat web „bez výpadků“, nemůžete mít jeden server u jednoho poskytovatele. A pokud budete provozovat takhle důležitý web, budete stejně skripty načítat z externích adres – i když i ty externí adresy budou třeba zase vaše servery.Je možné, že jsi se někde upsal a věta nevyznívá tak, jak by měla?
Je to možné. Tak to napíšu jinak. Když má prohlížeč limit na počet spojení na jednu webovou adresu (třeba 5 spojení), a budu z www.example.com stahovat i skripty, stahování skriptů mi vyčerpává ta volná spojení, takže třeba stažení obrázku bude čekat, až se stáhnou skripty. Když místo toho budu skripty stahovat z f.example.com nebo z jquery.maxcdn.com, budu mít na stahování těch skriptů 5 spojení, a těch 5 spojení na www.example.com zůstane k dispozici pro stahování z mého serveru (např. stylů, obrázků, dat apod.). -
NULL (neregistrovaný)
"Nepsal jsem, že je v tom CDN vždy lepší – ale je v tom lepší ve velké většině případů."
Opravdu? No možná jsi to tak myslel, ale jaksi jsi to zapomenul napsat. Podívejme se tedy:
"To, že statické soubory nedoručuju přes CDN ale z hlavního webového serveru, je přece součástí toho, že provozovatel CDN je v tom doručování lepší než já"
"Zatímco když to mám na svém serveru, musí se změnit adresa skriptu, "
Proč? Mám link na /js/xyz.js a jenom ho rekompiluji s novu verzí, třeba toho jQuery. Proč bych měl měnit jeho adresu? (same-origin)
"Když se podíváte na statistiku nedostupnost toho webu, bude to z velké části způsobené výpadky na vaší straně."
Opět nějaká interperace vlastní statistiky alá "mám ten pocit"?
" Když má prohlížeč limit na počet spojení na jednu webovou adresu (třeba 5 spojení), a budu z www.example.com stahovat "
A který z nich má takový limit? Podívej se, co stahuje root.cz. 5? Mimochodem to by jsi se třeba na Alze na nic jen tak ani nepodíval, tam je jenom těch obrázků na každé stránce tak 30 minimálně. Jinak defaultně mám v mozille network.http.max-connections 900 a http.max-persistent-connections-per-server a http.max-persistent-connections-per-proxy 32. O persistentních ale není řeč. Na mobilu 20. Tak jakých 5? A i tak. Pokud budu mít 30 obrázků 1 nebo 2 css a 1 nebo 2 js, protože na mobilu je časový "problém" i navázání každého dalšího spojení, tak je to stejně jedno a navíc CDN urychluje jenom cestu zpět a i to je relativní, protože nového ISP kvůli tomu najednou nepostaví . . . A pak se podívej na WP jak je oblíbený a má vlastní jQuery a za každý blbý plugin načítá minimálně 1 jsko a 1 cssko a že jich tam lidi mívají - i ty větší weby by jsi se divil - jo, je to "čuňárna" a jak je to populární . . . prej 5 :-D
Hele aby jsi si nemyslel, já ti svůj názor necpu, jen se mi nezdá ta argumentace. Ani nemám pocit že CDN je nějaké zlo, ale nevolím tuto cestu.
-
Filip JirsákStříbrný podporovatel
Ano, provozovatel CDN je v tom lepší než já, a je v tom lepší než drtivá většina provozovatelů jiných webů.
Proč? Mám link na /js/xyz.js a jenom ho rekompiluji s novu verzí, třeba toho jQuery. Proč bych měl měnit jeho adresu?
Protože se změnil obsah toho skriptu a vy chcete, aby se stáhla jeho nová verze. Určitě nechcete, aby se použila náhodná kombinace starých a nových skriptů podle toho, jak zrovna skončí platnost jejich kopií v cache prohlížeče. Pořád tu píšete, jak ten váš web musí bezpodmínečně pořád fungovat, tak ty stránky také musíte mít napsané tak, aby fungovaly.Opět nějaká interperace vlastní statistiky alá "mám ten pocit"?
Ne, to jsou všeobecně známé informace. Když provozujete svůj web na občas aktualizovaném WordPressu na VPS u provozovatele, kterému občas prší do serverovny, těžko dosáhnete na stejné SLA, jaké má Google s datacentry po celém světě.A který z nich má takový limit?
Každý. Ve Firefoxu hledejte v about:config network.http.max-persistent-connections-per-server, výchozí hodnota je 6, Chrome má myslím také 6, IE se drží doporučení RFC2616 a limit má 2.CDN urychluje jenom cestu zpět
U CDN je především větší šance, že už prohlížeč bude mít soubor v cache. Navíc je větší pravděpodobnost, že bude CDN geograficky blíž, tedy i to spojení se naváže rychleji.Ani nemám pocit že CDN je nějaké zlo, ale nevolím tuto cestu.
To je v pořádku. CDN není vhodné použít vždy. Ale pokud začínáte stavět malý web, je použití skriptů a stylů z CDN to nejefektivnější řešení. Až ten web vyroste a jeho provozovatel bude mít důvod začít se zabývat tím, co se bude dít v případě výpadku CDn, nebude problém adresy přepsat. -
NULL (neregistrovaný)
"WordPressu na VPS u provozovatele, kterému občas prší do serverovny"
Kurňa člověče, ty jsi samé maloměšťácké klišé . . .
"Každý. Ve Firefoxu hledejte v about:config network.http.max-persistent-connections-per-server"
OK. A četl jsi co jsem k tomu napsal? Opravdu si myslíš, že když máš na stránce 20 - 30obrázků, 10 scriptů (i css) a pošleš si 1 jquery přes CDN, tak to nějak poznáš při loadu stránky? To uřčitě - teda pardon, to co tu z tebe padá za statistiky tak určitš okem měříš v [ms] ale já teda ne.
"U CDN je především větší šance, že už prohlížeč bude mít soubor v cache. Navíc je větší pravděpodobnost, že bude CDN geograficky blíž"
Ano, v cache to asi najde. Ovšem kvůli jQuery třeba (88KB) . . . Kolik CDN má google v čr třeba? Mám pocit že ty lokace bubou velmi podbné (Praha, Brno . . .) jako produkční servery, tedy pokud nemáš server v nejaké Řitce.
"Až ten web vyroste a jeho provozovatel bude mít důvod začít se zabývat tím, co se bude dít v případě výpadku CDn, nebude problém adresy přepsat."
On to pak vetšinou problém je, minimálně časový. Hlavně když těch webů máš víc.
-
Filip JirsákStříbrný podporovatel
Doba načítání stránky se neměří okem – úplně základní nástroj máte v prohlížeči, vidíte tam Ganttův diagram načítání zdrojů. Pro podrobnější informace a optimalizace pak existují další nástroje.
Těch souborů, které se tahají z CDN, je obvykle mnohem víc než jeden – skripty, styly, fonty, ikony…
Kolik serverů vy máte po světě? Když máte server v Praze a uživatel je z ČR, bude se i skript tahat přes pražský uzel Google (i když ne nutně z Prahy, možná z Německa). Jenže když bude uživatel ze San Francisca, váš server bude pořád v Praze – při použití CDN se ten skript ale bude tahat z nějkaého uzlu na západním pobřeží USA, což je pro uživatele o dost blíž, než Praha.
Změna URL skriptu se dělá při každé změně verze, takže změna serveru, který skripty poskytuje, není žádný problém, ani časový. Pokud někdo ty skripty vkládá do spousty stránek ručně, má daleko větší problémy, než je nějaká CDN a její případná nedostupnost.
-
NULL (neregistrovaný)
"Doba načítání stránky se neměří okem "
No nepovídej , , , Optimalizace je jedna věc, dojem druhá. Máš pocit že zákazník pozná na prezentaci 371ms od 456 ms? Nebo krásných 186ms od 251ms? A to se nebavím o konektivitě na místě. . . No, tak si takové poznámky laskavě odpusť, zbytečně se mě snažíš urazit a zbytečně ze sebe děláš vola. Za sebe děkuji.
"Těch souborů, které se tahají z CDN, je obvykle mnohem víc než jeden – skripty, styly, fonty, ikony…"
Ano, na těch 100kách MB se ušetří ?.D Mimochodem pak ti ale bude těch 6 platit na tu CDNku . . .Nehledě na to, že když se ti nestahnou fonty, tak to ctěné oko zákazníka přežije. Když ti padne JS tak máš jiný problém.
"San Francisca, váš server bude pořád v Praze – při použití CDN se ten skript ale bude tahat z nějkaého uzlu na západním pobřeží USA, což je pro uživatele o dost blíž, než Praha."
Ano. to je pravda, ale stejně ta větší část webu pojede z Prahy . . . už jenom to, aby vůbec začal něco loadovat z CDNky tak musí první stáhnout tu Prahu a to se ani nebavím o tom, že klasicky bývá třeba to jQuery linované až v patičce . . . (narážka na to, kdy se začne stahovat)
Problém je to, že zrovna takové věci jsou pro web kritické. Pokud se ti nenačtou kvůli výpadku CDN obrázky, je to blbé ale dá se uděla fallback aby to nevypadalo a nebylo to tak hrozné. Ale stěžejní věci pro funkčnost by měl web distribuovat sám za sebe. Možná to není cool, in a tvrďácké prďácké, za to je to robustní řešení za prakticky okem nerozponatelný nárok."Změna URL skriptu se dělá při každé změně verze, takže změna serveru, který skripty poskytuje, není žádný problém, ani časový."
Ano "se dělá". Záleži asi kde (jak je napsaný web). K vlastním scriptům se většinou incrementuje i verze, často podle nějakého někde @version 1.2.3 a utomaticky se přihodí. Nevím o tom, že by se automaticky při buildu hádaly i hashe u linků na CDN . . .
Nehledě na to, že je rozdíl "Změna URL skriptu se dělá při každé změně verze" a vydávat novou verzi kvůli změně hashů okamžitě protože nejede CDNka. Je to v podstatě hotfix - úplně stejná procedůra - akorát že možnost že se stane jsi tam implementoval sám sobě. Hurá.
No a vidiš. Tím, že si nějaké ty KB nakompiluju to svého zdorjáku znamená, že tato diskuze zajímá jenom tebe, protože jsi si tam zavedl pravděpodobnost tohoto hotfixu a pak ještě změny zpět až to zase pojede a zpět až to zase nepojede. -
j (neregistrovaný)
2NULL: O nekolik radu pravdepodobnejsi je prave to, ze nekdo napadne nejakou CDNku a to uspesne napadne. To ze na ni nekdo utoci je setrvaly stav. Prave proto, ze je to daleko zajimavesi cil - predevsim kvuli patlalum, ktery si z ni nalinkujou kdejakou kravinu.
Google nebezi jeste stale ... zrovna na to koukam, pred vypadkem nejakych 11ms. Po vypadku a preroutovani to vybehlo na nejakych 25. Pak to, zhruba pred tydnem slo na cca 20. Od ty doby sou tam vide pekny zuby, kdy se to nachvilu (tak 2 hodky) vraci na tech 11, a pak zpatky na tech 20. Tzn porad to jeste zjevne nefunguje tak, jak to fugovalo pred tim vypadkem a pouziva se vyrazne delsi routa do nejakych pekel horoucich.
-
GH (neregistrovaný)
Nehodlám s tebou diskutovat, nemám na dementy čas. Jen jsem chtěl říct, že je vtipné zrovna od tebe, který jsi už mnohokrát prokázal absolutní neznalosti v tématu webu nebo webových aplikací, číst neustále dokola tohle navážení se ve stylu "hele, pár webařů umí ještě větší hovno než já, musím to hned všem říct, nejlíp 100x za sebou a vztáhnout to úplně na všechny, třeba pak budu za o něco menšího kreténa". K těm tvým "příkladům ze života" jako třeba desítky megabajt javascriptu kvůli posunutí divu - ehm, zkus při tom vymýšlení trochu míň přehánět, možná ti to pak i někdo uvěří.
-
NULL (neregistrovaný)
No, víš, ono ty 10ky MB jsou fakt extrém, ale v lidové webařině je úplně normální kvůli jednomu kalendáři 200x200 nalinkovat celé jquery-ui. Dokonce jsem zažil člověka, který to všechno v kopíroval ručně do jednoho scriptu. Heldat pak verze a co všechno to obsahuje byla skutečně zábava. Evidentě tě extrémní příklady z praxe nezajímají, tak zbývá ještě jedna možnost: tvářit se, že se to neděje ;-)
-
Řekl bych, že tady došlo k nedorozumění. Hlavička CSP je určena tvůrcům webů, aby lépe zabezpečili svůj web proti případnému XSS attacku. Z diskuse vyplývá, že to "j" nepochopil a chce po ní ochranu uživatele před tvůrcem webu. To samozřejmě není schopna zajistit. Při tak striktních požadavcích, jaké "j" má doporučuji noscript a ještě lépe odpojit počítač od sítě.
Pokud se týká následné diskuse zda "kompilovat" veškerý javascript do jednoho mega balíku nebo je dělit po funkčních celcích, není to tak jednoduché, jak to jednotlivé strany prezentovaly. Oba způsoby mají své výhody i nevýhody a bez hlubší analýzu konkrétního případu nelze říct, co je výhodnější.
-
j (neregistrovaný)
2ivoszz: Nikoli, z diskuse plyne, ze TY vubec nechapes, o cem tu je rec. A stejne tak ze TY naprosto nechapes, ze to proti XSS NIJAK a NIKOHO neochrani, protoze to lze pouze a vyhradne tak, ze web zadne externi scripty pouzivat nebude.
Tatar jako ty se samo neumi podivat o fous vedle, kde je seznam toho, co nacita diskuse na rootu, a 80% z toho nenacita naprimo, nacitaj to az ty externi scripty, ktery spoustej dalsi a dalsi svinstvo. Sem zvedav, jak tomu scriptu kterej je prece zcela koser ... zabranis nacist jinej scipt, kdyz si ho prave povolil. A uz vubec, jak zabranis, aby se ten dalsi scipt zmenil.
-
Lol Phirae (neregistrovaný)
Hlavička CSP je určena tvůrcům webů, aby lépe zabezpečili svůj web proti případnému XSS attacku.
Ano. A tvůrce webu určitě bude s nadšením řešit hashe u javaskriptu, deseti externích šmírovatel a analytik a dalších dvacet shitů vkládaných reklamními sítěmi, nad kterými nemá žádnou kontrolu. Celej vlhkej.
-
NULL (neregistrovaný)
No vždyť jo. Když je někdo čuně, tak to čuní. Když přebereš projekt po čuněti, tak ti nezbude nic než některé věci prostě čunit dál, tiše se stydět a doufat, že se nikomu z oboru nebudeš muset představit jako vývojář z onoho projektu.. Co je ale zajímavé je, že se v různých jazycích určitý druh čuňáren opakuje - třeba klasika, dodržování jmených konvencí - to umí napáchat zajímavé věci :-)
-
ad a) to jakože neumíte nastavit svůj web server tak, aby posílal příslušné hlavičky?
tak tady pro vás:
https://cs.lmgtfy.com/?q=nginx+custom+header
a
https://cs.lmgtfy.com/?q=apache2+custom+headerad b) ukázky konfigurací vidím v článku
...
-
Filip JirsákStříbrný podporovatel
Pokud někdo chce konfigurovat webový server, snad ví, že webové prohlížeče mají obvykle nějaké vývojářské nástroje. Použije tedy ty ve svém prohlížeči a zjistí, že Root hlavičku CSP posílá a může si prohlédnout její obsah. Pro vás - Root posílá jen direktivu
upgrade-insecure-requests. -
Filip JirsákStříbrný podporovatel
Byl tu dotaz na reálnou konfiguraci. Mně Root.cz připadá jako dostatečně reálný server. Vy se možná nespokojíte s reálnou konfigurací, ale chtěl byste vidět třeba reálnou komplexní konfiguraci – tak to napište místo těch svých rádobychytrých otázek.
-
Palo (neregistrovaný)
Toto sa nacitava pri tejto diskusii, ostatne zvladnete alebo to chcete uplne presne?
data:image
https://adx.adform.net
https://bbcdn-bbnaut.ibillboard.com
https://bbnaut.ibillboard.com
https://cm.g.doubleclick.net
https://fonts.googleapis.com
https://fonts.gstatic.com
https://f.root.cz
https://go.eu.bbelements.com
https://googleads.g.doubleclick.net
https://google-sync.rutarget.ru
https://i.iinfo.cz
https://ls.hit.gemius.pl
https://pagead2.googlesyndication.com
https://s1.adform.net
https://s1.navrcholu.cz
https://securepubads.g.doubleclick.net
https://spir.hit.gemius.pl
https://tpc.googlesyndication.com
https://trackad.cz
https://track.adform.net
https://www.google-analytics.com
https://www.google.com
https://www.googletagmanager.com
https://www.googletagservices.com
https://www.gstatic.com
https://www.root.cz -
Filip JirsákStříbrný podporovatel
A teď si z toho seznamu vyškrtejte vše, co souvisí s reklamou - abyste dostal seznam, který by mohl platit pro nějakou webovou aplikaci, třeba e-shop, webmail, úložiště souborů apod. U webových aplikací jsou přeci jen nároky na bezpečnost vyšší, když někdo získá můj účet na Rootu, může tak maximálně mým jménem psát komentáře.
-
Filip JirsákStříbrný podporovatel
"To" jsou hlavičky HTTP protokolu, takže se "to" konfiguruje tak, jak se konfigurují HTTP hlavičky vašeho HTTP serveru nebo webové aplikace. Z toho plyne i b). Ze serverů a webových aplikací to podporuje každá, která umí posílat uživatelem definované HTTP hlavičky, odkaz na podporu prohlížečů najdete v závěru článku, stejně jako informace o aktuálním stavu a odkaz na standard. Přehlédnul jste zřejmě závěr článku.
ČLÁNKY DO MAILU