Zásady OOP pro vývoj bezpečných aplikací Rudolf PECINOVSKÝ rudolf@pecinovsky.cz 2012 – Vývoj bezpečných aplikací

Obsah s odkazy Quo vadis, programování? (odkaz) Co je to „bezpečné“? Zásady správného a bezpečného programování Pachy v kódu Rozhraní a implementace (odkaz) Literatura (odkaz) 2012 – e-bezpečnost v Kraji Vysočina

Quo vadis, programování? Quo vadis, programování? (odkaz dovnitř) 2012 – e-bezpečnost v Kraji Vysočina

Co je to „bezpečné“? Bezpečné × zabezpečené aplikace Nebezpečnost geniálních programátorů Používané paradigma Nevýhody předčasné koncentrace na kód Problémy přechodu na nové paradigma 2012 – e-bezpečnost v Kraji Vysočina

Bezpečné × zabezpečené aplikace Bezpečná aplikace = aplikace, která je robustní vůči uživateli i vůči programátoru, který dostane za úkol ji upravit anebo rozšířit Zabezpečená aplikace = aplikace s dodatečnými nadstavbovými prvky, které mají zabránit případným útočníkům v realizaci jejich nekalých úmyslů Aplikaci, která není primárně vytvořena jako bezpečná, nezabezpečí žádné dodatečné zabezpečovací mechanizmy Existuje i druhý pohled: Bezpečná aplikace je taková, která firmě bezpečně přináší zisk Aplikace, která není bezpečná z programátorského hlediska nebude bezpečná ani z hlediska účetního, protože bude mít špatnou pověst (moc se jí neprodá) a navíc její údržba bude neúnosně drahá 2012 – e-bezpečnost v Kraji Vysočina

Nebezpečnost geniálních programátorů Napsat program, kterému rozumí počítač, dokáže každý trouba, dobří programátoři píší programy, kterým rozumějí lidé. Martin Fowler, Refactoring Zkušenost ukazuje, že programátor vytvářející programy, kterým jeho kolegové nerozumí, je pro firmu stejně nebezpečný jako záměrný záškodník Když takovéhoto geniálního programátora zlanaří jiný zaměstnavatel nebo se stane obětí dopravní nehody, musí firma celou jím navrženou část aplikace zahodit a nahradit jinou Nemusím umět napsat stejně geniální program jako kolega, ale když už jej kolega vytvoří, měl by být pro mě natolik srozumitelný, abych v něm dokázal udělat jednoduché úpravy 2012 – e-bezpečnost v Kraji Vysočina

Jednoduchý příklad nesrozumitelného kódu Klasický zápis programátorů v jazyce C Zápis, který preferují méně zkušení programátoři Dohodněte se na konvencích vyhovujících všem, a ty pak dodržujte int znak; while ((znak = bufReader.read()) != očekávaný); int znak; do { znak = bufReader.read(); } while (znak != očekávaný); 2012 – e-bezpečnost v Kraji Vysočina

Používané paradigma Bezpečnost aplikace je do značné míry závislá na použitém paradigmatu Složitost programů se stále zvětšuje, avšak kapacita mozku zůstává konstantní V průběhu 80 let se proto prosadilo objektové paradigma, které umožňuje psát větší, robustnější a snáze spravovatelné programy Výzkumy ukázaly, že tvorba programů větších než 100 000 příkazů je předobjektovými technologiemi jen těžko realizovatelná Zastánci tradičních paradigmat tvrdí, že stačí dodržovat zásady modularity. Bohužel nestačí; OO paradigma přináší několik konstrukcí, které přibližují náš programový popis simulované skutečnosti a umožňuje tak efektivnější a současně robustnější realizaci Publikace o programování bezpečných aplikací už většinou ani s jiným než s objektovým přístupem nepočítají 2012 – e-bezpečnost v Kraji Vysočina

Nevýhody předčasné koncentrace na kód Kurzy programování na školách se většinou soustředí na kód a opomíjejí nutnost výuky výrazně jiného způsobu myšlení, namísto OO paradigmatu učí jenom kódování v OO jazyce Absolventi těchto kurzů dále vyvíjejí své strukturované programy, jenom je nyní vyvíjejí v objektově orientovaném jazyce Takto vychovaný programátor myslí a hovoří v termínech kódu; mezi ním a zákazníkem vzniká sémantická mezera Common 2011

Problémy přechodu na nové paradigma Trocha psychologie Děti před pubertou jsou schopny přijmout nová fakta, aniž by si je musely spojovat s tím, co již znají; s postupným získáváním dalších informací si předchozí informace propojují a zařazují do kontextu Puberta mění naše myšlení z konkrétního na abstraktní a při té příležitosti nás o tuto schopnost připraví Člověk po pubertě si každý nový poznatek okamžitě podvědomě propojí s tím, co zná, i když při tom často dojde k výrazné dezinterpretaci Strukturovaný programátor při výkladu OOP podvědomě převádí vysvětlované termíny do paradigmatu, v němž je doma Problémem tohoto přechodu je k výrazná desinterpretace pojmů, v hlavě zůstane něco jiného, než co přednášející říkal Na počátku kurzu se domnívá, že slyší triviality, aby v další části zjistil, že se nechal zmást svou předchozí zkušeností a nyní se v termínech ztrácí Přechod trvá typicky 12 – 18 měsíců; čím zkušenější je přeškolovaný programátor, tím delší a bolestivější je jeho přechod 2012 – e-bezpečnost v Kraji Vysočina

Rozhraní × Implementace Rozhraní × Implementace (odkaz dovnitř)

Zásady programování bezpečných aplikací Architektonické zásady Jednoduchost Zapouzdření a rozhraní Průzračnost kódu i aplikace Modifikovatelnost a rozšiřitelnost Jasné rozdělení zodpovědností Neopakovat kód s podobnou funkcí A další… 2012 – e-bezpečnost v Kraji Vysočina

Hlavní zásady Dobře navržená architektura výrazně snižuje pravděpodobnost vzniku slabých míst napadnutelných útočníkem Zapouzdřete vše, co se mění, abyste měli svobodu při pozdějších úpravách Programujte proti rozhraní, ne proti implementaci Pro každou třídu ve vaší aplikaci by měl existovat jediný důvod pro její existencí a tím i také pro její případnou změnu Rozumně oddělujte data na straně jedné a chování a funkcionalitu na straně druhé Kód by měl být co nejjednodušší; čím je kód složitější, tím snáze přehlédneme dírku pro útočníka Minimalizujte dostupnost informací použitelných pro napadení Copyright © 2009, Rudolf Pecinovský ICZ

Maximalizovat soudržnost (cohesion) Míra soudržnosti označuje jak spolu souvisí funkcionalita jednotlivých části daného modulu Řešení úkolu by nemělo být „rozcourané“ po programu Části programu s podobnou funkcionalitou by měly být součástí společné komponenty, a naopak by se v ní neměly vyskytovat součásti řešící něco zcela jiného Úkol, který má daná entita na starosti, má vyřešit komplexně a ne jenom částečně Je-li úkol složitý, rozdělíme jej na úkoly, které budou řešit samostatné entity a entita zodpovědná za celkové řešení bude jejich práci jenom koordinovat http://en.wikipedia.org/wiki/Cohesion_(computer_science) 2012 – e-bezpečnost v Kraji Vysočina

Minimalizovat provázanost (coupling) Při definici každé entity bychom měli minimalizovat počet entit, které daná entita pro splnění daného úkolu oslovuje Používám-li ke splnění svého úkolu jinou entitu, stávám se na ni závislým Každá závislost je zárodkem dominového efektu: jakákoliv změna v dané entitě vyžaduje překontrolování všech entit, které jsou na ní závislé Zákon bohyně Demeter: Metoda objektu by měla volat pouze metody, které patří danému objektu, parametrům předaným dané metodě, objektům, které sama vytvořila, objektům komponent, které obsahuje Odkazy http://en.wikipedia.org/wiki/Coupling_(computer_programming) http://en.wikipedia.org/wiki/Law_of_Demeter 2012 – e-bezpečnost v Kraji Vysočina

Zapouzdření a rozhraní Zapouzdření: Zveřejněte, co umíte, ale tajte, jak to děláte Programátor musí u každé entity (třída, objekt, metoda, …) jasně oddělit, co musí okolní program o dané entitě vědět, aby ji mohl použít, a co definoval jenom proto, aby daná entita plnila svůj úkol http://en.wikipedia.org/wiki/Encapsulation_(computer_science) http://en.wikipedia.org/wiki/Information_Hiding Programujte proti rozhraní, ne proti implementaci Programátor by nikdy neměl využívat toho, jak je některá část programu definována, leda by tato skutečnost byla přímo uvedena v dokumentaci a stala se tak součástí rozhraní používané entity (třída, objekt, metoda, …) http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Interface_(object-oriented_programming) http://en.wikipedia.org/wiki/Interface_(computer_science) 2012 – e-bezpečnost v Kraji Vysočina

Jednoduchost KISS (Keep it simple, Stupid!) Principle of good enough (POGE) Jednoduchý kód je vytvořen rychleji, obsahuje méně chyb, je robustnější a snadněji se modifikuje Často se také formuluje : vytvoř to nejjednodušší, co ještě bude fungovat http://en.wikipedia.org/wiki/KISS_principle http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html http://en.wikipedia.org/wiki/Principle_of_good_enough Nevytvářejte YAGNI (You aren’t going to need it) Řada programátorů má nutkavou potřebu vytvářet podprogramy, které by se mohly hodit; vytvářejte je, až budou opravdu potřeba, protože snižují robustnost kódu – viz princip KISS http://en.wikipedia.org/wiki/YAGNI 2012 – e-bezpečnost v Kraji Vysočina

Průzračnost kódu i aplikace Kód, v němž se nevyznáme, se hůře zabezpečuje proti případným záměrným útokům Tvořte kód pro potenciálního „modifikátora“ Každá aplikace, která za něco stojí, bude v budoucnu upravována => pište tak, aby byly případné budoucí úravy co nejjednodušší http://c2.com/cgi/wiki?CodeForTheMaintainer Princip minimálního překvapení (Principle of least astonishment) Nenuť mne přemýšlet (Don’t make me think) Kód by měl být srozumitelný s minimálním mentálním úsilím Aplikace by měla respektovat zavedené zvyklosti a očekávání a nevymýšlet si na budoucího uživatele (ani programátora) žádné překvapující obraty http://en.wikipedia.org/wiki/Principle_of_least_astonishment http://en.wikipedia.org/wiki/Don%27t_Make_Me_Think 2012 – e-bezpečnost v Kraji Vysočina

Modifikovatelnost a rozšiřitelnost Připravenost kódu k modifikacím zvyšuje pravděpodobnost, že modifikace budou udělány čistě a nevzniknout skryté slabiny Při návrhu programu bychom měli počítat s tím, že jedinou konstantou současného programování je jistota, že zadání se brzy změní Programujte proti rozhraní, ne proti implementaci Zapouzdřete vše, co se může měnit, abyste měli svobodu při pozdějších úpravách Jednou z možností je „schovat“ potenciálně měněný kód za interface ISP – Interface segregation principle http://en.wikipedia.org/wiki/Extreme_programming#Embracing_change 2012 – e-bezpečnost v Kraji Vysočina

OCP – Open/closed Principle Jednotlivé části kódu by měly být uzavřeny vůči přímým modifikacím, ale otevřeny vůči dalším rozšířením Jakmile je kód jednou dokončen, mělo by se do něj zasahovat pouze při opravách objevených chyb; nové funkce by měly být realizovány pouze přidáním dalšího kódu Ohlídejte, aby nikdo nemohl měnit chování vaší třídy a jejich instancí Umožněte zájemcům definovat potomka vaši třídy, který bude lépe vybaven pro řešení některých speciálních situací http://en.wikipedia.org/wiki/Open_Closed_Principle 2012 – e-bezpečnost v Kraji Vysočina

Jasné rozdělení zodpovědností Oddělení zodpovědností (Separation of concerns – SoC) Potřebujeme usnadnit budoucí rozhodnutí kam sáhnout, abychom kód požadovaně upravili, a současně minimalizovat množství potřebných zásahů Každá úloha by měla být přidělená jediné entitě (metodě – třídě – balíčku), která je pak zodpovědná která je pak zodpovědná za jeho vyřešení Centrální vedení (armáda, Paleček) Různá funkcionalita by měla být řešena různými částmi kódu, které by se měly překrývat pouze minimálně To ovšem neznamená, že by různé části kódu nemohly používat společné entity http://en.wikipedia.org/wiki/Separation_of_concerns Toto pravidlo platí i obráceně – viz dále 2012 – e-bezpečnost v Kraji Vysočina

SRP – Single Responsibility Principle Single Responsibility Principle – Princip jediného odpovědného (objektu) Pro každou třídu ve vaší aplikaci by měl existovat jediný důvod pro její existencí a tím i také pro její případnou změnu Každá část kódu by měla být zodpovědná za jedinou věc, měla by mít jediný, dobře definovaný úkol a všechny schopnosti entity by měly být nasměrování k její realizaci Entita by se neměla rozptylovat starostmi o více věcí najednou ISP – Interface segregation principle Sada specializovaných rozhraní je výhodnější než jedno univerzální Při dodržení obou zásad pak každá změna zadání vyžaduje změnu pouze na jednom místě kódu http://en.wikipedia.org/wiki/Single_responsibility_principle 2012 – e-bezpečnost v Kraji Vysočina

Princip korektní abstrakce Každá důležitá část funkcionality by měla být implementována na jednom místě. Řeší-li několik částí kódu podobnou funkci, měli bychom je abstrahovat jako obecnější princip a společné jádro pak definovat na jednom místě Příklad: Jízdenkový automat Činnosti: zadat cestu – převzít peníze – vrátit nazpět – vytisknout jízdenku – vydat jízdenku Zobecněný úkol: obsloužit zákazníka http://en.wikipedia.org/wiki/Abstraction_principle_(programming) 2012 – e-bezpečnost v Kraji Vysočina

DRY - Don’t repeat yourself Zopakovaný kód přináší nebezpečí špatné modifikace při budoucích úpravách kódu Objevuje-li se stejný či podobný kód na více místech, musíme při každé modifikaci oběhnout všechna tato místa a všude příslušný kód správně opravit DRY - Don’t repeat yourself ; DIE – Duplication is Evil Programování stylem copy–paste je cestou do pekel Některá řešení existujících duplicit Nahradit literály pojmenovanými konstantami Opakující se kód „vytknout“ do samostatných metod Skupiny opakujících se metod „vytknout“ do společného předka Použít návrhový vzor (Služebník, Stavitel, Dekorátor, …) http://en.wikipedia.org/wiki/Don%27t_repeat_yourself 2012 – e-bezpečnost v Kraji Vysočina

LSP – Liskov Substitution Principle Potomek musí být schopen kdykoliv plnohodnotně vystupovat v roli svého předka (vydávat se za instanci předka) Používat dědičnost pouze v případě kdy potomek je speciálním případem předka LSP porušuje i potomek, jenž je příliš speciálním případem předka (Obdélník  Čtverec) Nevýhodou dědičnosti je porušování zapouzdření Metody potomka pracují s daty definovanými v předku Potomek musí občas znát implementační detaily předka (metoda setRozměr(int,int) u čtverce) Někdy musí dokonce předek znát implementační detaily potomka Dávat přednost skládání před dědičností Copyright © 2009, Rudolf Pecinovský ICZ

Příklady špatného použití dědičnosti Obdélník potomek úsečky, úsečka potomek bodu Kruhová výseč je potomkem kruhu Kvádr je potomek obdélníku Letadlo jako potomek křídla Cyklista přeskakující potok po kamenech je potomek žáby XObdélník a Terč z modré učebnice Zde najdete podrobné vysvětlení, proč je v daném případě použití dědičnosti nevhodné včetně ukázek problémů, k nimž požití dědičnosti v tomto případě vede Copyright © 2009, Rudolf Pecinovský ICZ

A další… Neukládejte důvěrné informace jako běžný text Verifikujte všechny vstupy uživatele Vyvarujte se předčasných snah o optimalizace 60 % zkrachovalých projektů krachuje právě kvůli předčasným snahám o optimalizaci kódu Nechovejte se podle hesla: Proč řežete tupou pilou? — Nemáme čas ji nabrousit Sledujte nové trendy v programování OOP, návrhové vzory, nová paradigmata, paralelní programování Sledujte nové technologie Frameworky, jazyky Naučte se anglicky, nebo změňte povolání 2012 – e-bezpečnost v Kraji Vysočina

Pachy v kódu 2012 – e-bezpečnost v Kraji Vysočina http://www.codinghorror.com/blog/2006/05/code-smells.html 2012 – e-bezpečnost v Kraji Vysočina

Uvnitř tříd 1/4 Dlouhé metody Komentáře Dlouhé seznamy parametrů Kratší metody se lépe čtou a jsou celkově pochopitelnější Kratší metody obsahují méně chyb a snáze se udržují Komentáře Všechny veřejné metody by měly mít dokumentační komentáře; jejich vynechání je omluvitelné pouze u těch nejjednodušších metod se samovysvětlujícími názvy (většinou „getry“ a „setry“) Komentáře by měly vysvětlovat PROČ a ne CO; neměly by duplikovat kód Nutnost použít komentáře bývá často příznakem toho, že metoda je příliš složitá a bylo by ji vhodné rozdělit na několik metod jednodušších Dlouhé seznamy parametrů Snižují srozumitelnost kódu Zavání tím, že kód bude zbytečně složitý Často je výhodné nahradit seznam parametrů přepravkou 2012 – e-bezpečnost v Kraji Vysočina

Uvnitř tříd 2/4 Opakování stejného či podobného kódu Potenciální problémy při úpravách kódu Musíme si pamatovat, kam všude jsme upravovaný kód zkopírovali Na všech místech jej správně upravit Příliš složité podmínky a větvení V převážné většině případů se po rozbití složitých podmíněných konstrukcí kód nejenom zpřehlední, ale také zrychlí Kombinatorická exploze V mnohých případech se objevuje množství variant kódu, které se navzájem liší pouze v maličkostech Často pomáhá vhodné zavedení genericity nebo použití návrhového vzoru Dekorátor Názvy typů v názvech metod Pokud musíte náhodou upravit název typu, musíte pak upravovat i názvy postižených metod 2012 – e-bezpečnost v Kraji Vysočina

Uvnitř tříd 3/4 Velké třídy Kryptické názvy tříd, metod a proměnných Jsou stejně obtížně čitelné a spravovatelné jako dlouhé metody Většinou porušují řadu další zásad, především zásadu, že každý objekt (a tím je i třída) má být zodpovědný za jedinou, přesně definovanou věc Kryptické názvy tříd, metod a proměnných Z názvu by mělo být vždy patrné, co má daný objekt na starosti a za co je zodpovědný Nekonzistentní názvy Stejná věc by se měla pokaždé nazývat stejně Java: length × size Mrtvý kód Nepoužívaný kód by měl být odstraněn dříve, než jej někdo omylem použije, a to nejspíš spatně Díky správě verzí se k němu můžeme v případě potřeby vrátit 2012 – e-bezpečnost v Kraji Vysočina

Uvnitř tříd 4/4 Zbytečná obecnost Podivuhodná řešení Pomocné atributy Tvořte kód, který řeší současné problémy, a nepřemýšlejte zbytečně nad řešením problémů, které by možná mohly někdy nastat – až nastanou, budou se řešit Podivuhodná řešení Řešení problému by mělo být přímočaré a průzračné Podivuhodná řešení jsou často zbytky po duplikovaném a následně všelijak přizpůsobovaném kódu Pomocné atributy Množství pomocných, dočasných atributů bývá příznakem špatně navrženého kódu 2012 – e-bezpečnost v Kraji Vysočina

Příklad důsledku špatného názvu proměnné public Vec odeberVec(String vec) {//Špatný název parametru for (Vec cokoli2: seznamVeci) { if (vec.getNazev().equals(vec)) {//Plete proměnné seznamVeci.remove(vec); return vec; } return null; public Vec odeberVec(String nazevVeci) { //Dobrý název for (Vec vec: seznamVeci) { if (vec.getNazev().equals(nazevVeci)) {//Neplete se 2012 – e-bezpečnost v Kraji Vysočina

Mezi třídami 1/5 Podobné třídy s rozdílnými rozhraními Třídy, které jsou si podobné uvnitř, ale liší se navenek, je vhodné upravit tak, aby i jejich rozhraní byla podobná či dokonce stejná Posedlost primitivy Nepoužívejte sadu primitiv jako náhradu objektu, který by všechna data sdružoval pod jednou střechou Datové třídy Třídy s instancemi určenými pouze k úschově dat jsou podezřelé; objekt by měl uschovávat data proto, aby s nimi mohl něco dělat Existují i výjimky – např. přepravka; tam je ale jasný cíl Shluky dat Vyskytují-li se často pohromadě nějaká data, nejspíš k sobě patří => uvažujte o objektu, který tato data sdruží 2012 – e-bezpečnost v Kraji Vysočina

Mezi třídami 2/5 Odmítnuté vazby Nevhodné důvěrnosti Pokud dceřiná třída nepoužívá žádnou funkčnost své rodičovské třídy, je dědičnost nejspíše zbytečná Nevhodné důvěrnosti Jednotlivé třídy by měly mít co nejméně společného Třídy, které toho dělají příliš mnoho spolu bývají příznakem nevhodného návrhu Nevhodné zveřejňování Třída by měla minimalizovat zveřejňování jakýchkoliv informací o svých útrobách, tj. o své implementaci Cíleně minimalizujte zveřejňování takovýchto informací a posilujte tak zapouzdření 2012 – e-bezpečnost v Kraji Vysočina

Mezi třídami 3/5 Líné třídy Prostředníci Zřetězení zpráv Každá třída by měl mít pádný důvod pro svoji existenci. Zbytečně definované třídy pouze zvyšují celkovou složitost projektu. Máte-li třídu, která skoro nic nedělá, zamyslete se nad tím, nebylo-li by výhodnější rozpustit její funkčnost mezi ostatní třídy Prostředníci Pokud třída většinu své funkčnosti na někoho deleguje, je v projektu pravděpodobně zbytečná Dávejte si pozor na třídy, které slouží pouze jako obaly na instance jiných tříd a jejich funkcionalitu Prostředníci bývají „převlečené závislosti“ Zřetězení zpráv Dlouhé posloupnosti volání metod a dočasných proměnných potřebné k získání potřebných dat většinou přinášejí skryté závislosti 2012 – e-bezpečnost v Kraji Vysočina

Mezi třídami 4/5 Špatně umístěná metoda Rozptýlené změny Domino Metoda, která intenzivně používá atributy a metody jiné třídy by měla být nejspíš definována ve třídě, jejíž členy používá Rozptýlené změny Vyžaduje-li změna v jedné části třídy nutnost upravit i jinou část, promyslete si, jestli třída neobsahuje dvě relativně nezávislé části, a nebylo-li by ji proto vhodné rozdělit na dvě třídy tak, aby případné změny byly vždy omezeny na jedinou třídu Domino Vyvolá-li změna v jedné třídě kaskádu změn v závislých třídách, je vhodné uvažovat o takové refaktoraci, po níž bude změna omezena pokud možno na jedinou třídu 2012 – e-bezpečnost v Kraji Vysočina

Mezi třídami 5/5 Paralelní hierarchie dědičnosti Občas se stává, že s každou definicí potomka jedné třídy musíte současně definovat i potomka jiné třídy; v takovém případě je vhodné se zamyslet nad tím, zda by nebylo vhodné obě hierarchie dědičnosti nějak sloučit Nekompletní knihovní třída Máme-li knihovnu, jejíž obsah nemůžeme změnit, a potřebujeme-li metodu, která v této knihovně není definovaná, často její definici „připíchneme“ k jiné třídě; vhodnější by ale bylo definovat separátní knihovní třídu, která bude schránkou na takovéto metody Rozmělněné řešení O rozmělněném řešení hovoříme tehdy, je-li k dosažení řešení potřeba příliš mnoho (třeba 5) tříd dané vrstvy; v takovém případě bychom měli uvažovat o úpravě návrhu 2012 – e-bezpečnost v Kraji Vysočina

Literatura (odkaz dovnitř) http://www.codinghorror.com/blog/2006/05/code-smells.html 2012 – e-bezpečnost v Kraji Vysočina

Rudolf Pecinovský mail: rudolf@pecinovsky.cz ICQ: 158 156 600 Děkuji za pozornost Rudolf Pecinovský mail: rudolf@pecinovsky.cz ICQ: 158 156 600 2012 – e-bezpečnost v Kraji Vysočina

2012 – e-bezpečnost v Kraji Vysočina

Pgm Používaná písma a objekty Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Demi) Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Medium) Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Cond) Příliš žluťoučký kůň úpěl ďábelské ódy (Heavy) Příliš žluťoučký kůň úpěl ďábelské ódy (Franklin Gothic Book) Příliš žluťoučký kůň úpěl ďábelské ódy (Comic Sans MS) Příliš žluťoučký kůň úpěl ďábelské ódy (Consolas) Příliš žluťoučký kůň úpěl ďábelské ódy Příliš žluťoučký kůň úpěl ďábelské ódy Opakování Program Keyword Příliš žluťoučký kůň úpěl ďábelské ódy 2012 – e-bezpečnost v Kraji Vysočina