SlideShare a Scribd company logo
ÚROVNĚ OCHRANYÚROVNĚ OCHRANYMichal ŠpačekMichal Špaček www.michalspacek.czwww.michalspacek.cz @spazef0rze@spazef0rze
Pro dobytí hradu kdysi nestačilo překonat jen ten bazén, ale taky vysoké zdi a na
nich budované laserové střílny. Webové aplikace byste měli navrhovat podobně, s
několika úrovněmi ochrany. Když selže první úroveň (vývojář), pořád tam jsou další,
které mohou návštěvníky ochránit. Tyto poznámky v původní prezentaci nejsou.
XSS
Cross Site Scripting
Princip více úrovní ochrany se dá hezky ukázat na útoku Cross-Site Scripting. Ten
útočníkům slouží ke spuštění zákeřného JavaScriptu staženého z jiného serveru v
kontextu zranitelné aplikace. Tím mohou zaútočit na uživatele a jejich prohlížeče.
Cross-Site Scripting (XSS) není žádná novinka. Podle Open Sourced Vulnerability
Database byla první XSS zranitelnost publikována v roce 1999.
$1.2 million
Jen v letech 2014-2016 vyplatil Google 1,2 milionu USD na odměnách za nalezení
XSS chyb ve svých aplikacích v rámci Vulnerability Reward Program. To docela jde.
Jen pro zajímavost, na obrázku vidíte muže, vlevo, a milion dolarů ve stodolarových
bankovkách, alespoň podle PageTutoru. To by se skoro vešlo do krabice od vína,
co? Tak zhruba tolika penězi Google za 2 roky odměnil úspěšné nálezce XSS chyb.
<img src=x onerror=alert(1)>
Cross-Site Scripting spočívá ve vložení JavaScriptu útočníkem do stránky. Lze také
vložit například značku img s onerror handlerem, nemusí to být jen tag <script>.
Když se XSS ukazuje nebo reportuje, tak nejčastěji jako alert(1). Důkaz možnosti
spustit nějaký JavaScript to sice je, ale o nebezpečnosti Cross-Site Scriptingu to nic
nevypovídá. Tohle dialogové okno moc lidí o nutnosti řešit XSS nepřesvědčí.
< → &lt;
> → &gt;
" → &quot;
' → &apos;
& → &amp;
První úroveň ochrany proti XSS je při výpisu správně ošetřit tyto nebezpečné znaky,
hlavně ty první čtyři řádky. Ale na to vývojáři často zapomínají a pak se dějí zlé věci.
The Browser Exploitation Framework Project
BeEF
Jenže XSS je mnohem víc než jen alert(1). XSS framework BeEF má zhruba
300 vestavěných modulů, které v browseru umí zobrazit např. falešné notifikace,
falešné přihlašovací formuláře, umí udělat screenshot stránky nebo přehrát MP3.
2nd
line of
DEFENSEVývojáři často zapomínají ošetřit speciální znaky a asi budou zapomínat i nadále.
Protože mají hořící termíny, špatný kafe nebo moc piv. Takže potřebujeme tohle.
Potřebujeme další úrovně zabezpečení. Ty nemusí fungovat vždy a pro všechny
uživatele, ale když první úroveň selže, tak vám může zachránit život. Nebo cookies.
Když už mluvíme o krádeži cookies… tak přesně takhle to funguje.
Aby JavaScript nemohl číst a krást session cookies, označte je ve vaší aplikaci jako
HTTP-Only, frameworky na to často mají konfigurační direktivy. HTTP-Only cookies
se normálně posílají na server, ale JavaScript je nevidí, takže je útočník nemůže
získat pomocí XSS. Pořád to ale půjde např. odposlechem nešifrovaného HTTP.
XSS
Auditor
Další druhá úroveň ochrany je zabudované přímo ve vašem prohlížeči, zvlášť pokud
používáte Chrome, Internet Explorer nebo Edge. Ve Firefoxu není, ale to nevadí,
není to primární úroveň ochrany. XSS auditor (XSS filtr) chrání proti Reflected XSS.
WEB
APP1 2
3
Takto Reflected XSS funguje. Útočník pošle uživateli odkaz s nějakým zákeřným
JavaScriptem v URL (1), uživatel na odkaz klikne a prohlížeč pošle požadavek na
webovou aplikaci (2). JavaScript z požadavku se vloží do stránky a vše se pošle
zpět uživateli (3), v jehož prohlížeči se ten JavaScript spustí. Browser vidí, co se mu
vrátilo z aplikace a pokud to vypadá jako JavaScript, který v požadavku odeslal, tak
spustí XSS filtr, pokud ho prohlížeč má a je povolen.
X-XSS-Protection: 1; mode=block
XSS filtr můžete ovládat ze serveru poslanou hlavičkou X-XSS-Protection. Režim
mode=block byste měli používat, prohlížeč po aktivaci filtru stránku vůbec neukáže.
mode=block je defaultně zapnutý v Chrome od verze 57. Starší verze se pokouší
stránku vyčistit. Na mém testovacím webu si můžete XSS auditor vyzkoušet.
Content Security Policy (CSP) je nejnovější přírůstek v řadě druhých úrovní ochrany
proti XSS. Tato hlavička posílaná ze serveru určuje povolené URL, ze kterých
prohlížeč do stránky může stahovat obrázky, JavaScript, CSS a další. Takže i když
útočník dokáže do HTML vložit značku <script>, tak browser z uvedené adresy
nestáhne kód, pokud ta adresa není povolená.
Content-Security-Policy: default-src 'self'
Toto je asi nejjednodušší varianta hlavičky Content-Security-Policy. Povolí
browseru do stránky poslané s touto hlavičkou načítat JavaScript, obrázky, CSS
a další pouze ze 'self', tedy z aktuálního protokolu, domény a portu (origin).
Content-Security-Policy:
default-src 'self';
img-src 'self' https://www.google-analytics.com
Můžeme navíc povolit načítání obrázků z https://www.google-analytics.com,
aby fungoval skript Google Analytics. Ten by však musel být načten z aktuálního
originu, protože default-src 'self', ale tak to bohužel nefunguje.
Content-Security-Policy:
default-src 'self';
img-src 'self' https://www.google-analytics.com;
script-src 'self'
https://www.google-analytics.com 'unsafe-inline'
V script-src musíme navíc povolit i origin pro skript Google Analytics. Pomocí
direktivy 'unsafe-inline' povolíme rovnou i tzv. inline JavaScript. Jo, JavaScript
zapsaný rovnou do HTML pomocí značek <script> nebo atributů jako např.
onclick může být unsafe. Jenže některé knihovny a nástroje inline JS používají.
csp-evaluator.withgoogle.com
Nasazení CSP není jednoduché a to nejen kvůli nástrojům jako například Google
Tag Manager. Politika často musí být vcelku otevřená, je nutné povolit spoustu
originů i inline JavaScript. Tím se také zvyšují šance pro útočníka, že najde
skulinku, kterou bude moci vložit svůj kód. Nastavení CSP si můžete otestovat v
nástroji CSP Evaluator, prozradí vám, jak by šlo konkrétní politiku obejít.
CSP3
Content Security Policy
Level 3
Situaci vylepšuje CSP3 a 'strict-dynamic'. Díky této direktivě bude prohlížeč
ignorovat seznam povolených domén a bude stahovat jen skripty označené pomocí
nonce, ty navíc mohou vkládat další skripty bez potřeby rozšířovat politiku.
Content-Security-Policy:
script-src 'strict-dynamic'
Direktivu 'strict-dynamic' podporuje Chrome i Firefox, oba shodně od verze 52.
Vyzkoušet si ji můžete na mé testovací stránce. Pojďme si takovou bezpečnou CSP
hlavičku sestavit, začneme tím, že povolíme skripty označené pomocí nonce.
<script
src=…
nonce="rAnd0m123"
>
</script>
Atribut nonce slouží pro označení skriptů. Jeho hodnota by se měla při každém
načtení stránky změnit a měla by být minimálně 16 náhodných bajtů zakódovaných
do Base64. Stejný nonce může být použit k označení více skriptů na jedné stránce.
Content-Security-Policy:
script-src 'strict-dynamic' 'nonce-rAnd0m123'
Takto do hlavičky Content-Security-Policy přidáme hodnotu atributu nonce.
Content-Security-Policy:
script-src 'strict-dynamic' 'nonce-rAnd0m123'
'unsafe-inline' http: https:;
Starší prohlížeče bez podpory 'strict-dynamic' načtou skripty označené pomocí
atributu nonce a ty pak mohou dále načítat skripty z http: a https:, tedy prakticky
jakékoliv další. Nakonec je potřeba povolit i inline JavaScript pro prohlížeče, které
nepodporují ani nonce z CSP2. Content Security Policy není primární metodou
obrany proti XSS, tou je stále převod nebezpečných znků na entity, takže nevadí, že
pořádně bude fungovat jen pro uživatele moderních prohlížečů s podporou CSP3.
Content-Security-Policy:
script-src 'strict-dynamic' 'nonce-rAnd0m123'
'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
Nakonec zakážeme načítaní pluginů, jako např. Flashe, a použití značky base pro
určení base URL stránky. Pomocí obojího lze Cross-Site Scripting spáchat také.
Content-Security-Policy:
script-src 'strict-dynamic' 'nonce-rAnd0m123'
'unsafe-inline' http: https:;
object-src 'none';
base-uri 'none';
report-uri https://report-uri.io/…
Pokud by se prohlížeč pokusil načíst nějaký zdroj, který mu Content Security Policy
zakazuje, tak vám o tom může poslat report na adresu v report-uri a vy tak
můžete případnou chybu opravit. Jenže prohlížeče posílají spoustu reportů aniž
byste v aplikaci nějakou chybu měli, protože lidé používají divná rozšíření, viry nebo
různé free Wi-Fi, které do stránek vkládají reklamu. Než číst každý jednotlivý report,
tak je lepší koukat na grafy a trendy. Obojí vám hezky zobrazí například report-uri.io.
Michal ŠpačekMichal Špaček www.michalspacek.czwww.michalspacek.cz @spazef0rze@spazef0rze
Chybovat je lidské, evidentně, tak na to myslete, až budete budovat obranu svých
aplikací. Protože i skoro 20 let staré útoky jsou pořád in a nebezpečné.

More Related Content

ODP
Minulé století volalo (Cross-Site Scripting + BeEF + CSP demo)
Michal Špaček
 
ODP
XSS PHP CSP ETC OMG WTF BBQ
Michal Špaček
 
ODP
Kolik webových útoků znáš...
Michal Špaček
 
ODP
Noční můry webového vývojáře
Michal Špaček
 
ODP
Jak zlepšit zabezpečení čtvrtiny celého webu
Michal Špaček
 
ODP
Medvědí služba
Michal Špaček
 
ODP
Bezpečnostní útoky na webové aplikace
Michal Špaček
 
ODP
Poučte se z cizích chyb
Michal Špaček
 
Minulé století volalo (Cross-Site Scripting + BeEF + CSP demo)
Michal Špaček
 
XSS PHP CSP ETC OMG WTF BBQ
Michal Špaček
 
Kolik webových útoků znáš...
Michal Špaček
 
Noční můry webového vývojáře
Michal Špaček
 
Jak zlepšit zabezpečení čtvrtiny celého webu
Michal Špaček
 
Medvědí služba
Michal Špaček
 
Bezpečnostní útoky na webové aplikace
Michal Špaček
 
Poučte se z cizích chyb
Michal Špaček
 

What's hot (20)

ODP
HTTP Strict Transport Security (HSTS)
Michal Špaček
 
ODP
Bezpečnostní útoky na webové aplikace, Čtvrtkon 5
Michal Špaček
 
ODP
Přechod na HTTPS
Michal Špaček
 
ODP
Hashování hesel
Michal Špaček
 
ODP
Zabezpečení Slevomatu
Michal Špaček
 
ODP
WebTop100 Technické chyby, výkon a bezpečnost
Michal Špaček
 
ODP
Základy webové bezpečnosti pro PR a marketing
Michal Špaček
 
ODP
Víte, že nevíte, že já vím, že nevíte? (WebTop100 2014)
Michal Špaček
 
ODP
Bezpečnost e-shopů (HTTPS, XSS, CSP)
Michal Špaček
 
ODP
Password manažeři detailněji – 1Password, LastPass, 2FA, sdílení
Michal Špaček
 
ODP
Hlava není na hesla
Michal Špaček
 
ODP
HTTPS (a šifrování) všude
Michal Špaček
 
PDF
Website Security & WordPress (Peter Gramantik)
wcsk
 
ODP
Bezpečnost na mobilních zařízeních
Michal Špaček
 
ODP
Zapomeňte vaše hesla
Michal Špaček
 
PDF
WordCamp Prague 2014 - Website security cz
peter_sucuri
 
PPTX
Bezpečnost na webu
Miloš Janda
 
PPTX
Nejčastejší problémy WordPress webů
Vladimír Smitka
 
ODP
Total Cost of Pwnership
Michal Špaček
 
PDF
WordPress šablony a rychlost načítání (WordCamp Praha 2017)
Martin Michálek
 
HTTP Strict Transport Security (HSTS)
Michal Špaček
 
Bezpečnostní útoky na webové aplikace, Čtvrtkon 5
Michal Špaček
 
Přechod na HTTPS
Michal Špaček
 
Hashování hesel
Michal Špaček
 
Zabezpečení Slevomatu
Michal Špaček
 
WebTop100 Technické chyby, výkon a bezpečnost
Michal Špaček
 
Základy webové bezpečnosti pro PR a marketing
Michal Špaček
 
Víte, že nevíte, že já vím, že nevíte? (WebTop100 2014)
Michal Špaček
 
Bezpečnost e-shopů (HTTPS, XSS, CSP)
Michal Špaček
 
Password manažeři detailněji – 1Password, LastPass, 2FA, sdílení
Michal Špaček
 
Hlava není na hesla
Michal Špaček
 
HTTPS (a šifrování) všude
Michal Špaček
 
Website Security & WordPress (Peter Gramantik)
wcsk
 
Bezpečnost na mobilních zařízeních
Michal Špaček
 
Zapomeňte vaše hesla
Michal Špaček
 
WordCamp Prague 2014 - Website security cz
peter_sucuri
 
Bezpečnost na webu
Miloš Janda
 
Nejčastejší problémy WordPress webů
Vladimír Smitka
 
Total Cost of Pwnership
Michal Špaček
 
WordPress šablony a rychlost načítání (WordCamp Praha 2017)
Martin Michálek
 
Ad

Similar to Víceúrovňová obrana vysvětlená na Cross-Site Scriptingu (20)

PDF
HTTPS zdarma a pro všechny - LinuxDays 2015
tomashala
 
PPTX
Bezpečnost Wordpressu - 4. WP konference
Vladimír Smitka
 
PDF
Nejčastější webové zranitelnosti
cCuMiNn
 
PDF
Úvod do bezpečnosti na webu
Keyup
 
PPTX
Bezpečnost WP, tipy pro každého - wordCamp Praha 2015
Vladimír Smitka
 
PPTX
WordCamp Praha 2016 - Bezpečnost WordPress
Vladimír Smitka
 
PDF
Optimalizace webových aplikací
Vašek Purchart
 
PPTX
WordCamp Brno 2017 - rychlý a bezpečný web
Vladimír Smitka
 
PPTX
Webmeetup #3
Vladimír Smitka
 
PPTX
WordPress: Základy - bezpečnost 3x3
Vladimír Smitka
 
PPTX
Bezpečnost WordPress pro začátečníky
Vladimír Smitka
 
PPTX
Wordcamp Praha 2015 - další útržky z prezentace
Vladimír Smitka
 
PPTX
WordPress - základy bezpečnosti
Vladimír Smitka
 
PDF
Webový front-end ve službách mobilního vývojáře
Martin Michálek
 
PDF
Bez HTML5/CSS3 to nejde
Martin Michálek
 
PPTX
Wordfence 2016
Vladimír Smitka
 
PDF
Kernun Clear Web
Avonet, s.r.o.
 
PDF
Před čím vás Nette ani Symfony neochrání
Filip Procházka
 
PPTX
TNPW2-2014-04
Lukáš Vacek
 
PPTX
TNPW2-2016-04
Lukáš Vacek
 
HTTPS zdarma a pro všechny - LinuxDays 2015
tomashala
 
Bezpečnost Wordpressu - 4. WP konference
Vladimír Smitka
 
Nejčastější webové zranitelnosti
cCuMiNn
 
Úvod do bezpečnosti na webu
Keyup
 
Bezpečnost WP, tipy pro každého - wordCamp Praha 2015
Vladimír Smitka
 
WordCamp Praha 2016 - Bezpečnost WordPress
Vladimír Smitka
 
Optimalizace webových aplikací
Vašek Purchart
 
WordCamp Brno 2017 - rychlý a bezpečný web
Vladimír Smitka
 
Webmeetup #3
Vladimír Smitka
 
WordPress: Základy - bezpečnost 3x3
Vladimír Smitka
 
Bezpečnost WordPress pro začátečníky
Vladimír Smitka
 
Wordcamp Praha 2015 - další útržky z prezentace
Vladimír Smitka
 
WordPress - základy bezpečnosti
Vladimír Smitka
 
Webový front-end ve službách mobilního vývojáře
Martin Michálek
 
Bez HTML5/CSS3 to nejde
Martin Michálek
 
Wordfence 2016
Vladimír Smitka
 
Kernun Clear Web
Avonet, s.r.o.
 
Před čím vás Nette ani Symfony neochrání
Filip Procházka
 
TNPW2-2014-04
Lukáš Vacek
 
TNPW2-2016-04
Lukáš Vacek
 
Ad

More from Michal Špaček (11)

ODP
Lámání a ukládání hesel
Michal Špaček
 
ODP
Fantom Opery, "VPN" a Secure Proxy v Opeře
Michal Špaček
 
ODP
Quality of Life, Multiple Lines of Defense
Michal Špaček
 
ODP
Disclosing password hashing policies
Michal Špaček
 
ODP
Operations security (OPSEC) in IT
Michal Špaček
 
ODP
HTTP Strict Transport Security (HSTS), English version
Michal Špaček
 
ODP
I forgot my password – what a secure password reset needs to have and why
Michal Špaček
 
ODP
HTTP/2
Michal Špaček
 
PPT
The problem with the real world
Michal Špaček
 
PPT
Defense in Depth Web Inkognito 12/2013
Michal Špaček
 
PPT
Bezpečnost webových aplikací Web Inkognito VŠE 05/2013
Michal Špaček
 
Lámání a ukládání hesel
Michal Špaček
 
Fantom Opery, "VPN" a Secure Proxy v Opeře
Michal Špaček
 
Quality of Life, Multiple Lines of Defense
Michal Špaček
 
Disclosing password hashing policies
Michal Špaček
 
Operations security (OPSEC) in IT
Michal Špaček
 
HTTP Strict Transport Security (HSTS), English version
Michal Špaček
 
I forgot my password – what a secure password reset needs to have and why
Michal Špaček
 
The problem with the real world
Michal Špaček
 
Defense in Depth Web Inkognito 12/2013
Michal Špaček
 
Bezpečnost webových aplikací Web Inkognito VŠE 05/2013
Michal Špaček
 

Víceúrovňová obrana vysvětlená na Cross-Site Scriptingu

  • 1. ÚROVNĚ OCHRANYÚROVNĚ OCHRANYMichal ŠpačekMichal Špaček www.michalspacek.czwww.michalspacek.cz @spazef0rze@spazef0rze Pro dobytí hradu kdysi nestačilo překonat jen ten bazén, ale taky vysoké zdi a na nich budované laserové střílny. Webové aplikace byste měli navrhovat podobně, s několika úrovněmi ochrany. Když selže první úroveň (vývojář), pořád tam jsou další, které mohou návštěvníky ochránit. Tyto poznámky v původní prezentaci nejsou.
  • 2. XSS Cross Site Scripting Princip více úrovní ochrany se dá hezky ukázat na útoku Cross-Site Scripting. Ten útočníkům slouží ke spuštění zákeřného JavaScriptu staženého z jiného serveru v kontextu zranitelné aplikace. Tím mohou zaútočit na uživatele a jejich prohlížeče.
  • 3. Cross-Site Scripting (XSS) není žádná novinka. Podle Open Sourced Vulnerability Database byla první XSS zranitelnost publikována v roce 1999.
  • 4. $1.2 million Jen v letech 2014-2016 vyplatil Google 1,2 milionu USD na odměnách za nalezení XSS chyb ve svých aplikacích v rámci Vulnerability Reward Program. To docela jde.
  • 5. Jen pro zajímavost, na obrázku vidíte muže, vlevo, a milion dolarů ve stodolarových bankovkách, alespoň podle PageTutoru. To by se skoro vešlo do krabice od vína, co? Tak zhruba tolika penězi Google za 2 roky odměnil úspěšné nálezce XSS chyb.
  • 6. <img src=x onerror=alert(1)> Cross-Site Scripting spočívá ve vložení JavaScriptu útočníkem do stránky. Lze také vložit například značku img s onerror handlerem, nemusí to být jen tag <script>.
  • 7. Když se XSS ukazuje nebo reportuje, tak nejčastěji jako alert(1). Důkaz možnosti spustit nějaký JavaScript to sice je, ale o nebezpečnosti Cross-Site Scriptingu to nic nevypovídá. Tohle dialogové okno moc lidí o nutnosti řešit XSS nepřesvědčí.
  • 8. < → &lt; > → &gt; " → &quot; ' → &apos; & → &amp; První úroveň ochrany proti XSS je při výpisu správně ošetřit tyto nebezpečné znaky, hlavně ty první čtyři řádky. Ale na to vývojáři často zapomínají a pak se dějí zlé věci.
  • 9. The Browser Exploitation Framework Project BeEF Jenže XSS je mnohem víc než jen alert(1). XSS framework BeEF má zhruba 300 vestavěných modulů, které v browseru umí zobrazit např. falešné notifikace, falešné přihlašovací formuláře, umí udělat screenshot stránky nebo přehrát MP3.
  • 10. 2nd line of DEFENSEVývojáři často zapomínají ošetřit speciální znaky a asi budou zapomínat i nadále. Protože mají hořící termíny, špatný kafe nebo moc piv. Takže potřebujeme tohle.
  • 11. Potřebujeme další úrovně zabezpečení. Ty nemusí fungovat vždy a pro všechny uživatele, ale když první úroveň selže, tak vám může zachránit život. Nebo cookies.
  • 12. Když už mluvíme o krádeži cookies… tak přesně takhle to funguje.
  • 13. Aby JavaScript nemohl číst a krást session cookies, označte je ve vaší aplikaci jako HTTP-Only, frameworky na to často mají konfigurační direktivy. HTTP-Only cookies se normálně posílají na server, ale JavaScript je nevidí, takže je útočník nemůže získat pomocí XSS. Pořád to ale půjde např. odposlechem nešifrovaného HTTP.
  • 14. XSS Auditor Další druhá úroveň ochrany je zabudované přímo ve vašem prohlížeči, zvlášť pokud používáte Chrome, Internet Explorer nebo Edge. Ve Firefoxu není, ale to nevadí, není to primární úroveň ochrany. XSS auditor (XSS filtr) chrání proti Reflected XSS.
  • 15. WEB APP1 2 3 Takto Reflected XSS funguje. Útočník pošle uživateli odkaz s nějakým zákeřným JavaScriptem v URL (1), uživatel na odkaz klikne a prohlížeč pošle požadavek na webovou aplikaci (2). JavaScript z požadavku se vloží do stránky a vše se pošle zpět uživateli (3), v jehož prohlížeči se ten JavaScript spustí. Browser vidí, co se mu vrátilo z aplikace a pokud to vypadá jako JavaScript, který v požadavku odeslal, tak spustí XSS filtr, pokud ho prohlížeč má a je povolen.
  • 16. X-XSS-Protection: 1; mode=block XSS filtr můžete ovládat ze serveru poslanou hlavičkou X-XSS-Protection. Režim mode=block byste měli používat, prohlížeč po aktivaci filtru stránku vůbec neukáže.
  • 17. mode=block je defaultně zapnutý v Chrome od verze 57. Starší verze se pokouší stránku vyčistit. Na mém testovacím webu si můžete XSS auditor vyzkoušet.
  • 18. Content Security Policy (CSP) je nejnovější přírůstek v řadě druhých úrovní ochrany proti XSS. Tato hlavička posílaná ze serveru určuje povolené URL, ze kterých prohlížeč do stránky může stahovat obrázky, JavaScript, CSS a další. Takže i když útočník dokáže do HTML vložit značku <script>, tak browser z uvedené adresy nestáhne kód, pokud ta adresa není povolená.
  • 19. Content-Security-Policy: default-src 'self' Toto je asi nejjednodušší varianta hlavičky Content-Security-Policy. Povolí browseru do stránky poslané s touto hlavičkou načítat JavaScript, obrázky, CSS a další pouze ze 'self', tedy z aktuálního protokolu, domény a portu (origin).
  • 20. Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com Můžeme navíc povolit načítání obrázků z https://www.google-analytics.com, aby fungoval skript Google Analytics. Ten by však musel být načten z aktuálního originu, protože default-src 'self', ale tak to bohužel nefunguje.
  • 21. Content-Security-Policy: default-src 'self'; img-src 'self' https://www.google-analytics.com; script-src 'self' https://www.google-analytics.com 'unsafe-inline' V script-src musíme navíc povolit i origin pro skript Google Analytics. Pomocí direktivy 'unsafe-inline' povolíme rovnou i tzv. inline JavaScript. Jo, JavaScript zapsaný rovnou do HTML pomocí značek <script> nebo atributů jako např. onclick může být unsafe. Jenže některé knihovny a nástroje inline JS používají.
  • 22. csp-evaluator.withgoogle.com Nasazení CSP není jednoduché a to nejen kvůli nástrojům jako například Google Tag Manager. Politika často musí být vcelku otevřená, je nutné povolit spoustu originů i inline JavaScript. Tím se také zvyšují šance pro útočníka, že najde skulinku, kterou bude moci vložit svůj kód. Nastavení CSP si můžete otestovat v nástroji CSP Evaluator, prozradí vám, jak by šlo konkrétní politiku obejít.
  • 23. CSP3 Content Security Policy Level 3 Situaci vylepšuje CSP3 a 'strict-dynamic'. Díky této direktivě bude prohlížeč ignorovat seznam povolených domén a bude stahovat jen skripty označené pomocí nonce, ty navíc mohou vkládat další skripty bez potřeby rozšířovat politiku.
  • 24. Content-Security-Policy: script-src 'strict-dynamic' Direktivu 'strict-dynamic' podporuje Chrome i Firefox, oba shodně od verze 52. Vyzkoušet si ji můžete na mé testovací stránce. Pojďme si takovou bezpečnou CSP hlavičku sestavit, začneme tím, že povolíme skripty označené pomocí nonce.
  • 25. <script src=… nonce="rAnd0m123" > </script> Atribut nonce slouží pro označení skriptů. Jeho hodnota by se měla při každém načtení stránky změnit a měla by být minimálně 16 náhodných bajtů zakódovaných do Base64. Stejný nonce může být použit k označení více skriptů na jedné stránce.
  • 26. Content-Security-Policy: script-src 'strict-dynamic' 'nonce-rAnd0m123' Takto do hlavičky Content-Security-Policy přidáme hodnotu atributu nonce.
  • 27. Content-Security-Policy: script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; Starší prohlížeče bez podpory 'strict-dynamic' načtou skripty označené pomocí atributu nonce a ty pak mohou dále načítat skripty z http: a https:, tedy prakticky jakékoliv další. Nakonec je potřeba povolit i inline JavaScript pro prohlížeče, které nepodporují ani nonce z CSP2. Content Security Policy není primární metodou obrany proti XSS, tou je stále převod nebezpečných znků na entity, takže nevadí, že pořádně bude fungovat jen pro uživatele moderních prohlížečů s podporou CSP3.
  • 28. Content-Security-Policy: script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; Nakonec zakážeme načítaní pluginů, jako např. Flashe, a použití značky base pro určení base URL stránky. Pomocí obojího lze Cross-Site Scripting spáchat také.
  • 29. Content-Security-Policy: script-src 'strict-dynamic' 'nonce-rAnd0m123' 'unsafe-inline' http: https:; object-src 'none'; base-uri 'none'; report-uri https://report-uri.io/… Pokud by se prohlížeč pokusil načíst nějaký zdroj, který mu Content Security Policy zakazuje, tak vám o tom může poslat report na adresu v report-uri a vy tak můžete případnou chybu opravit. Jenže prohlížeče posílají spoustu reportů aniž byste v aplikaci nějakou chybu měli, protože lidé používají divná rozšíření, viry nebo různé free Wi-Fi, které do stránek vkládají reklamu. Než číst každý jednotlivý report, tak je lepší koukat na grafy a trendy. Obojí vám hezky zobrazí například report-uri.io.
  • 30. Michal ŠpačekMichal Špaček www.michalspacek.czwww.michalspacek.cz @spazef0rze@spazef0rze Chybovat je lidské, evidentně, tak na to myslete, až budete budovat obranu svých aplikací. Protože i skoro 20 let staré útoky jsou pořád in a nebezpečné.