Jak jsme zlepšili zabezpečení Slevomatu.
Chceš zlepšit zabezpečení webu a nevíš kde začít a kdy skončit? Ukážu ti, co jsme udělali na Slevomatu, co všechno jsme museli vyřešit, čemu jsme se divili a co plánujeme. Třeba tě to trochu taky nakopne.
Ukládáš hesla do databáze jen tak, v čitelné podobě? Nebo používáš MD5? Nebo snad SHA-1? Vsadím se, že nevíš, co je to salt. Taky tajně doufám, že neposíláš hesla e-mailem. Jednoho krásného dne se někde na webu objeví obsah databáze tvojí webové aplikace a její uživatelé nebudou mít radost. Nevystavuj je zbytečnému nebezpečí a raději si rezervuj místo v první řadě a já ti ukážu, jak se se svým webem nedostat do hlavního zpravodajství TV Nova.
Zajímá vás správné ukládání hesel? Přijďte si o tom popovídat na školení Bezpečnost PHP aplikací: http://www.michalspacek.cz/skoleni/bezpecnost-php-aplikaci
Jak zlepšit zabezpečení čtvrtiny celého webuMichal Špaček
WordPress prý používá 27 % webu. Na následujících slajdech bych chtěl naznačit, co bychom ve WordPressu mohli zlepšit z pohledu bezpečnosti,protože když to uděláme, tak se zvýší zabezpečení poměrně hodně webů. Já vím, ne všichni aktualizují, ale o tom někdy jindy.
Securitas, res publica.
V posledních pár letech se s bezpečnostními incidenty roztrhl pytel. Tady unikl seznam uživatelů, tady i jejich hesla, tady jen jejich objednávky. V této přednášce spojíme moje dvě oblíbená rčení a to, že každý web je dostatečně dobrý na hacknutí a že opakování je matkou moudrosti. Zopakujeme si, koho už u nás hacknuli a poněvadž by to byla nekonečně dlouhá přednáška, tak se raději zaměříme jen na zveřejněné případy.
Bezpečnost, věc veřejná.
Základy webové bezpečnosti pro PR a marketingMichal Špaček
Na dotazy ohledně ukládání hesel raději odpovídejte až zhlédnutí této přednášky. Proč je důležité správné ukládání hesel a co se pod tím vlastně skrývá? Nebojte se, do zbytečných technických detailů zabíhat nebudeme. Podíváme se také na šifrovaný přenos přihlašovacích údajů, bezpečnostní otázky a na příkladech si ukážeme špatné odpovědi na různé zapeklité otázky ohledně zabezpečení některých webů. Po této přednášce byste měli vědět, jak na sociálních sítích správně odpovídat nejen na moje dotazy.
Jak jsme zlepšili zabezpečení Slevomatu.
Chceš zlepšit zabezpečení webu a nevíš kde začít a kdy skončit? Ukážu ti, co jsme udělali na Slevomatu, co všechno jsme museli vyřešit, čemu jsme se divili a co plánujeme. Třeba tě to trochu taky nakopne.
Ukládáš hesla do databáze jen tak, v čitelné podobě? Nebo používáš MD5? Nebo snad SHA-1? Vsadím se, že nevíš, co je to salt. Taky tajně doufám, že neposíláš hesla e-mailem. Jednoho krásného dne se někde na webu objeví obsah databáze tvojí webové aplikace a její uživatelé nebudou mít radost. Nevystavuj je zbytečnému nebezpečí a raději si rezervuj místo v první řadě a já ti ukážu, jak se se svým webem nedostat do hlavního zpravodajství TV Nova.
Zajímá vás správné ukládání hesel? Přijďte si o tom popovídat na školení Bezpečnost PHP aplikací: http://www.michalspacek.cz/skoleni/bezpecnost-php-aplikaci
Jak zlepšit zabezpečení čtvrtiny celého webuMichal Špaček
WordPress prý používá 27 % webu. Na následujících slajdech bych chtěl naznačit, co bychom ve WordPressu mohli zlepšit z pohledu bezpečnosti,protože když to uděláme, tak se zvýší zabezpečení poměrně hodně webů. Já vím, ne všichni aktualizují, ale o tom někdy jindy.
Securitas, res publica.
V posledních pár letech se s bezpečnostními incidenty roztrhl pytel. Tady unikl seznam uživatelů, tady i jejich hesla, tady jen jejich objednávky. V této přednášce spojíme moje dvě oblíbená rčení a to, že každý web je dostatečně dobrý na hacknutí a že opakování je matkou moudrosti. Zopakujeme si, koho už u nás hacknuli a poněvadž by to byla nekonečně dlouhá přednáška, tak se raději zaměříme jen na zveřejněné případy.
Bezpečnost, věc veřejná.
Základy webové bezpečnosti pro PR a marketingMichal Špaček
Na dotazy ohledně ukládání hesel raději odpovídejte až zhlédnutí této přednášky. Proč je důležité správné ukládání hesel a co se pod tím vlastně skrývá? Nebojte se, do zbytečných technických detailů zabíhat nebudeme. Podíváme se také na šifrovaný přenos přihlašovacích údajů, bezpečnostní otázky a na příkladech si ukážeme špatné odpovědi na různé zapeklité otázky ohledně zabezpečení některých webů. Po této přednášce byste měli vědět, jak na sociálních sítích správně odpovídat nejen na moje dotazy.
Víceúrovňová obrana vysvětlená na Cross-Site ScriptinguMichal Špaček
Jak se pomocí více úrovní obrany bránit proti notoricky známému útoku Cross-Site Scripting (XSS). Jaké vrstvy zabezpečení existují a kdy se používají. O vlastnostech prohlížečů a Content Security Policy (CSP).
HTTP Strict Transport Security (HSTS), zajistí zabezpečený „převoz“ informací bez možnosti odstranění HTTPS (SSL Strip). HSTS je HTTP hlavička, kterou posílá server. Browser poté bude po X sekund interně přesměrovávat http:// na https://.
… a chtělo svoje útoky zpět. Útok Cross-Site Scripting (XSS) byl poprvé popsán v roce 1999 a od té doby je tu stále s námi. Proč je tak nebezpečný a jak se mu bránit, když to vývojáři evidentně nezvládají?
Jak vytvářet hesla, co je to password manager a proč ho nutně potřebujete.
Zapomínáte hesla? Já taky ne. Používáte heslo pro přístup k vašemu emailu i pro přístup k jiným službám? Pokud ano, tak to není moc dobrý nápad. Prozradím vám, jak to dělat lépe.
Útoků na webové aplikace existují desítky. Představíme si tři základní, ukážeme si, jak takový útok provést a jak webovou aplikaci proti danému útoku zabezpečit. Na závěr si ukážeme, jak bezpečně ukládat uživatelská hesla.
Jako odborníci v IT už asi víte, že máte používat nějaký password manager, že? Ale jaký a jaké jsou rozdíly mezi nimi? A v čem se liší 1Password od LastPassu, tedy kromě ceny?
Každý rok se objeví několik desítek nových typů útoků a hackovacích technik na webové aplikace. V loňském roce jich bylo popsáno 31, pojďme si některé nové i starší útoky představit.
Víte, že nevíte, že já vím, že nevíte? (WebTop100 2014)Michal Špaček
Víte, že nevíte, že já vím, že nevíte?
Po přednášce už budete vědět. Ukážu vám pár chyb, které možná již znáte, jen netušíte, že kvůli nim zrovna váš web opouští data vaše nebo vašich uživatelů. A že budete bezpečnost webu řešit až se něco stane a že se ještě nic nestalo? Jasně, tak hlavně přijďte :-)
Pár praktických ukázek, ve kterých ukážu, proč se věnovat zabezpečení e-shopů a co se stane, když se na to vykašlete. A že když to budete řešit, až se když se něco bude dít, tak už může být pozdě.
Tato přednáška byla doplněna a nahrazena novější přednáškou "Hlava není na hesla", prohlédněte si raději tu. Najdete ji na https://www.michalspacek.cz/prednasky/hlava-neni-na-hesla-barcampjc
Odkazy z článku jsou také na http://www.michalspacek.cz/prednasky/zapomente-vase-hesla-new-media-inspiration
Přednáška s podtitulkem Jak vytvářet, ukládat, používat hesla, jaké nástroje k tomu používat a proč proboha.
Používáte hesla? Kolik jich máte? Asi dost, co. Znáte nějaký program pro správu a pamatování hesel nebo snad používáte jedno heslo na více místech? Používáte heslo pro přístup k vašemu emailu i pro přístup k jiným službám? Šmarjá, opravdu? Když náhodou takové službě unikne databáze emailů a hesel, včetně toho vašeho, tak pak případný zlý hoch může získat přístup i k dalším službám, protože do vaší emailové schránky vám chodí např. zapomenutá hesla nebo odkazy na nastavení hesel nových. Pokud k tomu tedy dojde, tak vás může zachránit už jen dvoufaktorová autentizace, víte, co to je? To je otázek, že… ale nebojte, mám i odpovědi.
Lehce osvětová přednáška o tom, proč by HTTPS mělo být úplně všude, nejen na přihlašovacím formuláři. A že šifrování není jenom o HTTPS. Jako obvykle si něco i ukážeme.
Bezpečnostní útoky na webové aplikace, Čtvrtkon 5Michal Špaček
Útoků na webové aplikace existují desítky. Představíme si tři základní, ukážeme si, jak takový útok provést a jak webovou aplikaci proti danému útoku zabezpečit. Na závěr si ukážeme, jak bezpečně ukládat uživatelská hesla a pár špeků, kterým byste se měli obloukem vyhnout.
HTTPS zdarma a pro všechny - LinuxDays 2015tomashala
Proč by na HTTPS měly běžet i weby, ke kterým se nepřihlašujete? Co znamenají chyby nalezené v SSL/TLS za poslední rok? V čem se můžeme poučit z kauzy Hacking Team? Jak se s přechodem na HTTPS vypořádávají vyhledávače? Jak si nerozbít web při honbě za A+ ratingem u SSL Labs? Co přináší nový HTTP/2 protokol? A proč má být na webhostingu HTTPS k dispozici zdarma a všem?
NMI14 Michal Špaček - Jak vytvářet, ukládat, používat hesla, jaké nástroje k ...New Media Inspiration
Prezentace z třetího ročníku konference New Media Inspiration (http://nminspiration.cz), který se konal 8. 2. 2014 v hlavní budově FF UK pod vedením @petrkou, @simindr a @josefslerka.
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
Víceúrovňová obrana vysvětlená na Cross-Site ScriptinguMichal Špaček
Jak se pomocí více úrovní obrany bránit proti notoricky známému útoku Cross-Site Scripting (XSS). Jaké vrstvy zabezpečení existují a kdy se používají. O vlastnostech prohlížečů a Content Security Policy (CSP).
HTTP Strict Transport Security (HSTS), zajistí zabezpečený „převoz“ informací bez možnosti odstranění HTTPS (SSL Strip). HSTS je HTTP hlavička, kterou posílá server. Browser poté bude po X sekund interně přesměrovávat http:// na https://.
… a chtělo svoje útoky zpět. Útok Cross-Site Scripting (XSS) byl poprvé popsán v roce 1999 a od té doby je tu stále s námi. Proč je tak nebezpečný a jak se mu bránit, když to vývojáři evidentně nezvládají?
Jak vytvářet hesla, co je to password manager a proč ho nutně potřebujete.
Zapomínáte hesla? Já taky ne. Používáte heslo pro přístup k vašemu emailu i pro přístup k jiným službám? Pokud ano, tak to není moc dobrý nápad. Prozradím vám, jak to dělat lépe.
Útoků na webové aplikace existují desítky. Představíme si tři základní, ukážeme si, jak takový útok provést a jak webovou aplikaci proti danému útoku zabezpečit. Na závěr si ukážeme, jak bezpečně ukládat uživatelská hesla.
Jako odborníci v IT už asi víte, že máte používat nějaký password manager, že? Ale jaký a jaké jsou rozdíly mezi nimi? A v čem se liší 1Password od LastPassu, tedy kromě ceny?
Každý rok se objeví několik desítek nových typů útoků a hackovacích technik na webové aplikace. V loňském roce jich bylo popsáno 31, pojďme si některé nové i starší útoky představit.
Víte, že nevíte, že já vím, že nevíte? (WebTop100 2014)Michal Špaček
Víte, že nevíte, že já vím, že nevíte?
Po přednášce už budete vědět. Ukážu vám pár chyb, které možná již znáte, jen netušíte, že kvůli nim zrovna váš web opouští data vaše nebo vašich uživatelů. A že budete bezpečnost webu řešit až se něco stane a že se ještě nic nestalo? Jasně, tak hlavně přijďte :-)
Pár praktických ukázek, ve kterých ukážu, proč se věnovat zabezpečení e-shopů a co se stane, když se na to vykašlete. A že když to budete řešit, až se když se něco bude dít, tak už může být pozdě.
Tato přednáška byla doplněna a nahrazena novější přednáškou "Hlava není na hesla", prohlédněte si raději tu. Najdete ji na https://www.michalspacek.cz/prednasky/hlava-neni-na-hesla-barcampjc
Odkazy z článku jsou také na http://www.michalspacek.cz/prednasky/zapomente-vase-hesla-new-media-inspiration
Přednáška s podtitulkem Jak vytvářet, ukládat, používat hesla, jaké nástroje k tomu používat a proč proboha.
Používáte hesla? Kolik jich máte? Asi dost, co. Znáte nějaký program pro správu a pamatování hesel nebo snad používáte jedno heslo na více místech? Používáte heslo pro přístup k vašemu emailu i pro přístup k jiným službám? Šmarjá, opravdu? Když náhodou takové službě unikne databáze emailů a hesel, včetně toho vašeho, tak pak případný zlý hoch může získat přístup i k dalším službám, protože do vaší emailové schránky vám chodí např. zapomenutá hesla nebo odkazy na nastavení hesel nových. Pokud k tomu tedy dojde, tak vás může zachránit už jen dvoufaktorová autentizace, víte, co to je? To je otázek, že… ale nebojte, mám i odpovědi.
Lehce osvětová přednáška o tom, proč by HTTPS mělo být úplně všude, nejen na přihlašovacím formuláři. A že šifrování není jenom o HTTPS. Jako obvykle si něco i ukážeme.
Bezpečnostní útoky na webové aplikace, Čtvrtkon 5Michal Špaček
Útoků na webové aplikace existují desítky. Představíme si tři základní, ukážeme si, jak takový útok provést a jak webovou aplikaci proti danému útoku zabezpečit. Na závěr si ukážeme, jak bezpečně ukládat uživatelská hesla a pár špeků, kterým byste se měli obloukem vyhnout.
HTTPS zdarma a pro všechny - LinuxDays 2015tomashala
Proč by na HTTPS měly běžet i weby, ke kterým se nepřihlašujete? Co znamenají chyby nalezené v SSL/TLS za poslední rok? V čem se můžeme poučit z kauzy Hacking Team? Jak se s přechodem na HTTPS vypořádávají vyhledávače? Jak si nerozbít web při honbě za A+ ratingem u SSL Labs? Co přináší nový HTTP/2 protokol? A proč má být na webhostingu HTTPS k dispozici zdarma a všem?
NMI14 Michal Špaček - Jak vytvářet, ukládat, používat hesla, jaké nástroje k ...New Media Inspiration
Prezentace z třetího ročníku konference New Media Inspiration (http://nminspiration.cz), který se konal 8. 2. 2014 v hlavní budově FF UK pod vedením @petrkou, @simindr a @josefslerka.
node.js: zápisky z fronty (Battle guide to node.js)almadcz
[czech] V Apiary používáme node.js v produkci už přes rok.
Proč se zamyslet nad tím, zda ho chcete? A na co se připravit a na co si dát pozor, pokud se do toho pustíte?
API a microservices se často setkávají a ne vždy se hodí pro tvorbu rozhraní microservice použít REST. V této přednášce se podíváme na některé méně tradiční formy přístupu k API, jako třeba event sourcing nebo m-n komunikace a ukážeme si zajímavé možnosti, které nám tyto formy přinášejí. A jak už to ve správném obludáriu musí být, některé exempláře budou opravdu strašidelné.
Slidy z přednášky o bezpečnostni Wordpressu na 3. WP konferenci.
Kdo je útočník, jaké jsou jeho možnosti a jak se mu bránit.
Další materiály se objeví na http://edu.lynt.cz
Relační databáze efektivně z pohledu vývojářeJan Smitka
S relačními databázemi se setkal asi každý vývojář, ale ne každý vývojář jim rozumí natolik, aby je dokázal efektivně využít. V přednášce si ukážeme, jak databáze vykonávají naše dotazy a jak jim v tom pomoci. Ukážeme si nástroje pro ladění dotazů v MySQL a PostgreSQL a celou řadu praktických tipů. Po přednášce už se nebudete muset bát příkazu EXPLAIN!
Přednáška z 4. WP konference - bezpečnost Wordpressu. Aktuální statistiky, základní útoky, skenování wordpressu, iThemes Securtiy, Fail2Ban, Web Application Firewall.
Další info na: http://edu.lynt.cz/course/bezpecnost-wordpressu
Přednáška z 2.6.2011 z akce Internet Session Brno. Martin Pešout a Marek Hulán představili výhody vývoje webových aplikací ve frameworku Ruby on Rails.
Hobby Developer 3.0: Tipy a triky pro webTomáš Muchka
Develop functional useful webpages, not monsters with the size of classic games. This presentation will guide you through all stages of modern web page development with tons of examples from his a real hobby project: http://lan.strazov.cz
Čtvrtkon #71 - Marian Benčat - Angular a NativeScriptCtvrtkoncz
Téma: Angular a NativeScript: Pro enterprise level web, desktop a nativní mobilní aplikace, více info na: http://ctvrtkon.cz/pozvanka-na-ctvrtkon-71-30-srpna-2018/
#golang @SkrzCzDev (Skrz DEV Cirkus 21.10.2015)Jakub Kulhan
Go se @SkrzCz používá pro výkonově nejnáročnější části aplikaci. Jedna z nich je servírování bannerů a výběr těch správných reklam do nich. 1000 req/s v peaku a "adbandit" má minimální nároky na server. Podívejte se, jak použít Go ve spolupráci s ReactPHP a RabbitMQ.
Fantom Opery, "VPN" a Secure Proxy v OpeřeMichal Špaček
Jak jsem pomocí prohlížeče přišel na to, že Opera VPN není VPN aneb co všechno na sebe Chrome prozradí v chrome://net-internals/ a jak to můžete použít pro ladění nebo zkoumání různých udělátek a extenzí.
Would you voluntarily share how your web app stores passwords? Some companies indeed do share, for example Facebook and LastPass to name just a few. Some share involuntarily. Some don't share at all because they feel that it will make them more vulnerable. Here's why you should do that and how.
Operations security (OPSEC) is a term originating in U.S. military jargon. In IT, it says what to do to protect your servers, developers, information, and other resources. Targeting developers, new trend in computer security, is becoming increasingly common because they usually have access to production servers and other critical infrastructure.
HTTP Strict Transport Security (HSTS), English versionMichal Špaček
HTTP Strict Transport Security (HSTS) provides secure transport of data, by removing the possibility of HTTPS stripping. HSTS is an HTTP header issued by the server. After receiving such header, the browser will perform internal redirects from http:// to https:// for given amount of seconds.
I forgot my password – what a secure password reset needs to have and whyMichal Špaček
Users often forget their passwords, so applications often must have a password reset mechanism. There are several options for how to do it; some of them are good, most of them not so good. Generate a password and send it in an email? No. Security questions? No way. Reset passwords via a phone call? Rather not. This talk presents some really creative examples of botched password reset implementations, as well as a proven method for resetting passwords securely.
From unsalted SHA-1 to bcrypt, from generated passwords sent in e-mails to just links and other stories of securing user passwords at your regular e-commerce site from web developer's point of view.
Video of the talk available at http://www.michalspacek.cz/prednasky/the-problem-with-the-real-world-passwords
Bezpečnost webových aplikací Web Inkognito VŠE 05/2013
Noční můry webového vývojáře
1. NOČNÍ MŮRYNOČNÍ MŮRY
WEBOVÉHOWEBOVÉHO
VÝVOJÁŘEVÝVOJÁŘE
Michal ŠpačekMichal Špaček
www.michalspacek.czwww.michalspacek.cz @spazef0rze@spazef0rze
Na fotce je Mike Rogers, šéf americké NSA.
Tato verze slajdů obsahuje navíc poznámky
nejen pro ty, kteří na přednášce nebyli.
2. POUZE PRO
STUDIJNÍ ÚČELY
NENABÁDÁM
K TRESTNÉ ČINNOSTI
Webová bezpečnost je tak trochu jako matematika nebo sekera nebo
kladivo. Když s těmito znalostmi nebo nástroji uděláte něco nepěkného,
půjdete bručet. Můj anděl strážný mi doporučil vás upozornit.
3. Trestní zákoník – č. 40/2009 Sb. § 182
Porušení tajemství dopravovaných zpráv
(1) Kdo úmyslně poruší tajemství
a) …
b) datové, textové, hlasové, zvukové či obrazové zprávy posílané
prostřednictvím sítě elektronických komunikací a přiřaditelné k
identifikovanému účastníku nebo uživateli, který zprávu přijímá, nebo
c) neveřejného přenosu počítačových dat do počítačového systému, z něj
nebo v jeho rámci, včetně elektromagnetického vyzařování z
počítačového systému, přenášejícího taková počítačová data,
bude potrestán odnětím svobody až na dvě léta nebo zákazem činnosti.
4. Trestní zákoník – č. 40/2009 Sb. § 230
Neoprávněný přístup k počítačovému systému
a nosiči informací
(1) Kdo překoná bezpečnostní opatření, a tím neoprávněně získá přístup k
počítačovému systému nebo k jeho části, bude potrestán odnětím svobody
až na jeden rok, zákazem činnosti nebo propadnutím věci nebo jiné
majetkové hodnoty.
V § 230, odstavci (1), se vůbec nehovoří o úmyslu. Jakákoliv bezpečnostní opatření
na webu ale bohužel často chybí.
5. Chyby tedy raději hledat nebudeme, jen si o nich budeme povídat. Chyby často hledají
jiní a píšou o nich pak na webu. Když budete nějaký popis hledat, raději použijte Tor.
Uber nechal přístupový klíč k databázi veřejně na GitHubu, někdo ho zneužil a Uber teď
chce po GitHubu IP adresy všech návštěvníků té stránky. Tor funguje takto.
6. Jedním z webů, kde se občas zveřejňují chyby je český SOOM. Nezáleží na tom, jak
velký máte web nebo kolik máte uživatelů, vždycky jste pro někoho dost dobrý cíl.
7. SQL INJECTIONSQL INJECTION
Velmi často je zmiňována útok SQL Injection. Ten vypadá
přesně takto. To znáte, ne? Někteří úplně přesně takhle,
že? Fajn, pro ty, kteří jste to nezažili nebo to s radostí
zapomněli, tak opakování: SQL Injection spočívá v
úpravě dotazu odesílaného do databáze.
8. SELECT jmeno, adresa
FROM vozidla
WHERE rz = '$prectena';
Představte si aplikaci pro kameru, která měří rychlost. Pod kamerou projede
auto, kamera přečte jeho registrační značku a když pojede rychle, tak z
databáze vytáhne adresu a pošle pokutu. Zjednodušeně.
9. SELECT jmeno, adresa
FROM vozidla
WHERE rz = '1AM 1337';
1AM 1337
Když pod kamerou projede nějaký elitní pražan, tak obslužný software
kamery pošle do databáze tento dotaz, najde se jméno a adresa a už se
tiskne milostný dopis.
10. ' OR 0='0
Když pod kamerou projede třeba tohle auto ze Severní
Karolíny, tak… to nebude fungovat, protože nejspíš nebude
mít značku vpředu. Ale kdyby to fungovalo, tak se stane tohle:
11. SELECT jmeno, adresa
FROM vozidla
WHERE rz = '' OR 0='0';
' OR 0='0
Do databáze se pošle tento dotaz, to červené a podtržené je přečtená
značka. OR 0='0' je vždy pravda, takže pokuta se pošle všem. HA HA HA.
12. ' OR 1=1; --
Někdy se používá tenhle minitrik s komentářem, protože nevíme, co všechno
na konci dotazu je, tak to prostě zakomentujeme.
13. SELECT jmeno, adresa
FROM vozidla
WHERE rz = '' OR 1=1; --';
' OR 1=1; --
Dotaz pak bude vypadat třeba takto, všimněte si, že vše za středníkem je
zakomentováno. Středník se dá vynechat a v MySQL by bylo potřeba ještě
doplnit mezeru za pomlčka pomlčka. Výsledek je ale stejný.
14. Mno, tak když by pod takovou kamerou projel tenhle frajer, tak… Ale tohle by
fungovalo jen v případě, že by šlo najednou poslat více dotazů oddělených
středníkem. Za určitých okolností to lze i v MySQL, třeba při
SQL Injection v emulovaných prepared statements v PDO.
15. Software kamer na silnici ale není to, s čím se často setkáváme, zvlášť pokud
nemáme řidičák. Pojďme si to ukázat spíš na nějaké webové aplikaci. Tady
jsme chtěli zobrazit produkty značky 30'abc – to je známá čínská značka, něco
jako McDonald's – v obojím je apostrof a to se hodí.
16. V téhle webové aplikaci došlo k chybě, protože dotaz není syntakticky správně,
ale vývojáři nám k tomu naštěstí vypsali spoustu dalších informací, jako třeba celý
dotaz, takže přesně víme, jak vypadá a co máme dělat. Tohle nikdy nedělejte,
když dojde k chybě, tak tohle uživatele vůbec nezajímá. Zajímá to jen mizery.
17. "… WHERE znacka = '{$_GET['znacka']}'"
Dotaz, který aplikace odesílala, mohl vypadat třeba nějak takto, parametr je
sice ohraničen do apostrofů, ale bez jakéhokoliv ošetření. Stačí pak
apostrofem z toho ohraničení vyskočit a zbytek dotazu upravit dle přání.
18. Někdy není apostrof potřeba, protože není z
čeho vyskakovat, to je třeba tento případ.
Aplikace očekává číslo a my pošleme řetězec.
19. '… WHERE id = ' . $_GET['id']
Kód v tomto případě mohl vypadat takto, parametr
je do dotazu vložen bez ohraničení apostrofy, takže
i kdyby náhodou ochrana spočívala v nějakém
ošetření apostrofů, aby nešlo vyskočit, tak je to
jedno, apostrof zde vůbec není třeba psát.
20. STOP! DEMO TIME!
SQL Injection si můžete beztrestně vyzkoušet třeba u mě, na adrese
http://exploited.cz/sql/products.php
21. BLINDBLIND
SQL INJECTIONSQL INJECTION
Při útoku SQL Injection je běžné, že aplikace zobrazuje
nějaké chybové hlášky nebo něco vypisuje do stránky.
Často ale nic takového nevidíte. Blind SQL Injection
spočívá v tom, že jen pozorujete chování stránky.
22. Prepared statements (PDO)
Řešením mohou být třeba prepared statements, které jsou v PHP v PDO extenzi.
Fungují tak, že si v dotazu pojmenujete zástupné místo (:id) a pak na něj navážete
proměnnou. Někdy se místo těchto pojmenovaných míst mohou použít jen otazníky.
Ale pozor, v PHP tohle neumí třeba vložit pole, takže si musíte spoustu věcí dopsat a
můžete to podělat. Jako třeba Drupal, ten si právě takto zavlekl do kódu SQL Injection.
23. Je tedy lepší použít něco, co už tyto věci umí, třeba
dibi, nebo aspoň dávejte velký pozor při implementaci,
v tom případě vám přeji hodně štěstí.
24. $query where(→
'p.product = (%sql)',
'SELECT id FROM products
WHERE code = '' . $code . '''
);
No a nakonec, ani s dibi nesmíte udělat třeba tohle. $code je tam prostě
nalepené, což je špatně, protože i toto je zranitelnost SQL Injection. Do
dotazu raději nic takto nevkládejte, vždy využijte vázání proměnných.
25. Mark Burnett https://xato.net/passwords/password-stock-photos/
Může se stát a asi se i stane, že někde přece jen uděláte chybu a někdo získá
přístup k databázi. Nebo se dostane k zálohám. V databázi je spousta věcí, údaje o
dodavatelích apod. jsou sice jen vaše, ale hesla uživatelů vaše nejsou. Hesla
uživatelů se pak dají použít na páchání zla přímo těm uživatelům, třeba na přístup k
jejich e-mailovým schránkám. Hodně uživatelů používá jedno heslo na více místech.
26. Plaintext
MD5(heslo)
SHA-1(heslo)
SHA-2(heslo)
Takto hesla neukládejte. MD5, ani SHA-
1 nebo SHA-2 nepoužívejte. Pokud dva
uživatelé budou mít stejné heslo, budou
mít i stejný hash. Takto zahashovaná
hesla lze najít i v tzv. předpočítaných
tabulkách (rainbow tables). Lidé, co to
myslí vážně s lámáním hesel už
rainbow tables nepoužívají, zabírají moc
místa a dlouho se vytváří.
27. Jenže Google takových tabulek pár indexuje, takže pro rychlé
vyzkoušení stačí vzít hash a dát ho do Google. Profi práce se ale
takto nedělá. Profíci používají grafické karty a velké slovníky
(které obsahují i sousloví a celé věty, nejenom jednotlivá slova)
pro slovníkové a hybridní útoky.
28. MD5(heslo + salt)
SHA-1(heslo + salt)
Pro zamezení použití rainbow tables a narozeninových útoků se používá salt. Salt je unikátní a
náhodný pro každý účet, není tajný a je v db uložen v čitelné podobě, neslouží ke zpomalení
lámání hesel. Takže takhle to také nedělejte. Tohle je sice lepší, než jen MD5, ale…
29. Salt nezpomaluje lámání hesel, takže hrubou silou 8 grafických karet
se pořád dá lámat hodně rychle. Tenhle stroj generuje 80 miliard
MD5 hashů/sec. I můj laptop dělá 30 milionů MD5 hashů/sec a asi
20M SHA-1/sec. Podobné stroje pro profíky staví Jeremi Gosney.
30. bcrypt!
Blowfish hashing
Takže jak na to? Pro ukládání hesel použijte bcrypt, někdy nazýván
„Blowfish hashing“ (samotný název Blowfish představuje symetrickou
šifru, tedy něco jiného a nevhodného pro ukládání hesel). Bcrypt
podporuje salt a dá se řídit jeho rychlost. Doporučuje se nastavit cost
parametr na 10 (nebo více), což znamená, že se jedno heslo zahashuje
v cyklu 2×1010
. Jedno hashování trvá zhruba 80 ms, uživatel to ani
nepostřehne, ale útočníka to podstatně zpomalí.
31. crypt() salt=$2y$…
password_hash() password_verify()
Bcrypt je v PHP implementován ve funkci crypt() od 5.3.7. Nastavuje se saltem,
který začíná na $2y$. Salt si musíte vymyslet sami, jenže to je masakr. Saltem to
můžete pokazit, třeba když použijete všude stejný. Jakákoliv funkce, která po vás
chce salt je na nic. Od PHP 5.5 jsou dostupné funkce, kterým jen dáte heslo
a ony ho zahashují nebo ověří, nic víc neřešíte. Pro starší PHP raději použijte
password_compat. Od Nette 2.2 můžete použít NetteSecurityPasswords.
32. scrypt
PBKDF2
Argon2
Další vhodné algoritmy jsou scrypt a PBKDF2. Scrypt je pro PHP dostupný
pouze jako PECL extenze. PBKDF2 je v PHP od 5.5. V létě 2015 bychom
měli znát výherce Password Hashing Competition, tedy nový a ještě lepší
algoritmus pro ukládání hesel. Snad bude brzy dostupný i v PHP a dalších
jazycích. (Aktualizace: novou hashovací funkcí je Argon2, až bude
dostupná ve vašem oblíbeném jazyce, tak ji používejte.)
33. Zdroj: http://www.flickr.com/photos/40852961@N04/5439723004/
Neposílejte hesla e-mailem, ani po
registraci. Ne všechna spojení
mezi servery jsou šifrovaná a někdo
tedy e-mail s heslem může
odposlechnout. Navíc když si
uživatel zprávu s heslem stáhne do
počítače, tak to heslo tam může
někdo přečíst. Uživatel si navíc
heslo zaslané e-mailem spíš nikdy
nezmění.
34. Zdroj: http://www.flickr.com/photos/reidrac/4696900602/
Reset zapomenutého hesla provádějte tak, že uživateli pošlete odkaz, který bude mít
náhodný token, který bude za hodinu expirovat a bude platit jen jednou. Po kliknutí si
bude moci uživatel nastavit heslo. Negenerujte mu nové heslo a neposílejte ho ani e-
mailem. Po změně hesla uživatele informujte, inspirujte se třeba u Facebooku.
35. Jeden uživatel
=
Jedna databáze
Nebuďte líní a pro každou aplikaci vytvářejte nové databázové uživatele a
nová hesla. Nastavte jim právo pro přístup pouze do jedné databáze.
Jeden uživatel s možností přístupu k databázím více aplikací může být
problém ve chvíli, kdy jedna z těch aplikací bude mít chybu SQL Injection.
36. Žádný kód v databázi
eval(), HTML
V databází nemějte ani žádný PHP kód, který budete chtít spouštět
pomocí eval(), viz Drupal 7 Remote Code Execution, ani HTML na
formátování, protože to HTML může útočník s přístupem do databáze
upravit a dát tam třeba svoji reklamu. Použijte třeba Texy s vypnutým
HTML, aby nešlo propašovat ani vlastní Javascript.
37. Cross-Site Scripting
XSS
Další častou chybou je XSS, tedy útok, během kterého útočník vloží nějaký kód
na stránku, JavaScript, obrázek, HTML formulář apod.
38. XSS vypadá třeba takto, viz parametr zb v URL. Tím se do
stránky propašoval JavaScript, který zobrazil tohle alert okno.
39. V kódu napadené stránky to vypadá takto. Modře označený text je to, co se
do HTML dostalo z parametru zb v URL.
40. JavaScript od útočníka může vypadat třeba takto. Tohle konkrétně
krade přihlašovací jméno a heslo z přihlašovacího formuláře po
jeho odeslání. JavaScriptem lze někdy získat i session id z cookies,
pak není třeba krást hesla. Ačkoliv heslo se vždycky hodí.
41. htmlspecialchars($string, ENT_QUOTES)
Výstupy ošetřujte pomocí htmlspecialchars() s parametrem ENT_QUOTES
aby se převáděly i apostrofy. Ty se standardně nepřevádí. Lepší je ale
použít nějaký šablonovací systém, který toto řeší za vás automaticky. Nikdy
si nezkracujte cestu a automatické ošetřování nevypínejte.
42. Nepoužívat
strip_tags()
proti XSS
Funkce strip_tags() není ta správná ochrana pro XSS. Odstraňuje
pouze celé značky, ale to útočníkovi nezabrání vložit třeba nový atribut
onclick do existujícího formulářového políčka.
43. X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
A když náhodou zapomenete něco ošetřit (nebo když vypnete automagické
ošetřování), tak tahle HTTP hlavička může vaše návštěvníky zachránit. Aktivuje XSS
Auditor v prohlížečích a v pokud se na stránku dostane nějaký JavaScript přes adresu
nebo z formuláře, tak jej nespustí, případně celou stránku vůbec nezobrazí, pokud
použijete mode=block. A to byste měli, protože některé prohlížeče se stránku pokusí
opravit, ale opraví ji tak dobře, že vložený JavaScript se stejně spustí.
44. default-src 'none'
script-src 'unsafe-inline'
script-src ajax.googleapis.com
Content-Security-Policy
Hlavička X-XSS-Protection neřeší případy, kdy útočník uloží JavaScript do
databáze, například do článku. Dopad takového problému můžete zmírnit třeba
pomocí Content Security Policy (CSP). Tato hlavička explicitně povoluje zdroje,
odkud se mohou načítat skripty, obrázky, styly aj. Hodnota unsafe-inline povoluje
inline JS, tedy JavaScript vložený přímo do HTML kódu. To byste neměli dělat,
veškerý kód byste měli dát do externích souborů a unsafe-inline nepoužívat.
Podle mé zkušenosti s tím ale nefunguje třeba Google Tag Manager, bohužel.
45. script-src 'strict-dynamic' 'nonce-<random>'
'unsafe-inline' http: https:;
object-src 'none';
report-uri https://….report-uri.io/…
Lepší Content-Security-Policy
Zavést CSP na běžící web není nic jednoduchého, právě třeba kvůli Google Tag Manageru.
Proto je jednodušší použít tuto hlavičku. strict-dynamic je vlastnost z CSP3, která dovolí
skriptům již vloženým do stránky vkládat další skripty, tedy přesně to, co dělá právě např Tag
Manager. HTML značky script pro vkládání JavaScriptu do stránky je nutné označit pomocí
atributu nonce a jeho hodnotu pak přidat do direktivy script-src. Hodnota by měla být
náhodná a měla by se měnit při každém načtení stránky. Zbytek, včetně 'unsafe-inline', je
pak pro starší prohlížeče, které CSP3 neumí. object-src zakáže vložit Flash, který také může
způsobit XSS. Díky direktivě report-uri bude prohlížeč odesílat reporty o porušení nastavení
politiky, posílejte si je na službu report-uri.io. Kvalitu nastavení CSP si můžete zkontrolovat na
csp-evaluator.withgoogle.com, na stejném místě můžete stáhnout i extenzi do Chrome.
46. session.cookie_httponly: true
session.cookie_secure: true
HTTP-Only cookies
Pomocí XSS se často kradou sessions - JS načte z document.cookie session
cookie a pošle ji útočníkovi, ten si ji vloží do svého browseru a vydává se za
uživatele, který útočníkův kód spustil. Parametr httponly zabrání JS ve čtení dané
cookie, v document.cookie pak není dostupná. Tuhle direktivu si nastavte. HNED.
TEĎ. A pokud máte web pouze na HTTPS, což byste měli mít, tak nastavte
i secure parametr. A tím se pomalu dostáváme k…
47. HTTPS
=
How To Transfer Private Shit
Nikomu tedy není nic do toho, jaké články si zrovna čtu, jaká odesílám hesla,
co si zrovna prohlížím a nikdo nemá právo modifikovat data, která stahuji.
48. STOP! DEMO TIME!
Umím donutit vaše zařízení, aby se připojila k mojí Wi-Fi a HTTPS potom docela
oceníte. Ukázku najdete v druhé půlce mojí přednášky z konference PHP live 2014.
49. TLS
Transport Layer Security
To S v názvu HTTPS neznamená SSL, ale Secure. SSL je protokol z minulého
tisíciletí a už by se neměl dnes používat. Nahradil ho protokol TLS, aktuálně ve
verzi 1.2, v březnu 2015 je aktuálně k dispozici návrh TLS 1.3.
50. Pro web na HTTPS (celý web, jinak to nemá smysl) vlastní IP adresu potřebovat
NE-BU-DE-TE.
51. SNI
Server Name Indication
Od roku 2003 existuje rozšíření TLS s názvem SNI, které zajistí, že název serveru pošle
prohlížeč nešifrovaně a server tak bude moci poskytnout prohlížeči správný certifikát.
SNI umí IE od verze 7 na WinVista a pozdějších. Na WinXP to nefunguje v žádném IE,
ve Firefoxu a Chrome ano. Firefox umí SNI od verze 2, Chrome od verze 6 na WinXP
(na WinVista v jakékoliv verzi), Safari od verze 3, Android od 3 dále. Pokud potřebujete
podporovat starší verze, tak budete pořád vlastní IP adresu potřebovat.
52. HSTS
HTTP Strict Transport Security
Až budete mít celý web na HTTPS, tak přidejte hlavičku Strict-Transport-
Security. HSTS, zajistí, že browser vnitřně přesměruje na HTTPS a nebude
vůbec nebude posílat požadavek po HTTP. Ten by stejně jenom vygeneroval
přesměrování na HTTPS verzi. Požadavek na HTTP tedy nepůjde zachytit a
odstranit to přesměrování a tím efektivně HTTPS odstranit a převést na HTTP.
53. MIXED CONTENTMIXED CONTENT
Po převodu na HTTPS si dávejte pozor na tzv. mixed content, tedy
abyste do stránek na HTTPS nenačítali HTTP obsah, browser by tento
obsah mohl zablokovat. Typicky se jedná třeba o videa, styly a obrázky.
54. REFERRER
<meta name="referrer" content="origin">
Pozor na referrer, ten se ze stránek na HTTPS nepředává do stránek na HTTP,
takže je potřeba si správně odkazy z HTTPS nějak označit, jinak nebudete v
Google Analytics vědět, odkud návštěvník přišel. Můžete také použít meta referrer
(tady už správně s dvěma „r“), ten zajistí, že se referrer bude předávat i z HTTPS
na HTTP, pokud použijete hodnotu origin (předá se pouze doména) nebo
unsafe-url (předá se celé URL včetně parametrů), podpora v Chrome od konce
roku 2011, Firefox od verze 36, IE od verze 12/Edge.
55. HTTPONLY
&
SECURE
HTTP-only cookie jsem zmiňoval jako obranu proti krádeži session pomocí XSS.
Secure parametr jsem také už nakousl. Ten zajistí, že browser nepošle cookie (třeba
se session id) po nešifrovaném spojení, i kdyby ho útočník přesvědčoval, že to má
udělat, takže nepůjde odposlechnout. Bez toho je HTTPS jakoby bez toho S.
57. http://www.example.com/app/config.neon
Konfigurace Nette v čitelné podobě. Přibližně jedno procento webů napsaných
v Nette má konfiguraci volně a veřejně přístupnou. Tyhle soubory nesmí být
přístupné pomocí prohlížeče, patří mimo document root nebo k nim musí být
zakázán přístup pomocí souboru .htaccess.
58. http://www.example.com/.git
git clone http://www.example.com/.git
Pokud pracujete s Gitem, tak si zkontrolujte, jestli na webu nemáte adresář
.git a pokud máte, tak ho smažte a zajistěte, aby se tam zase nedostal.
Pokud se dá do toho adresáře dostat přes browser, tak je možné získat
interní databázi Gitu, ve které je třeba seznam souborů. Často lze také
naklonovat repozitář a získat tak kompletní zdrojové kódy.