Príklad
Predstav si e-learningový systém, kde sa študent prihlási do kurzu, učiteľ mu pridelí úlohu a admin spravuje používateľov.
Na prvý pohľad všetko funguje. Lenže:
Výsledok: chaos, bezpečnostné riziko a nedôvera v systém.…
Príklad
Používateľ si kúpi prístup k filmu na 48 hodín. Film si večer pozrie na mobile, ráno chce pokračovať na notebooku – ale systém mu zobrazí hlášku „prístup vypršal“, aj keď ešte nemal.
Naopak, iný používateľ má obsah dostupný aj po 3 dňoch, pretože expirácia sa nesprávne počítala podľa lokálneho času zariadenia.…
Príklad
Predstav si vodiča nákladného auta, ktorý používa elektronické mýto.
Systém eviduje ŠPZ vozidla, prejazdy cez mýtne brány, čas prejazdu a účet dopravcu.
Jedného dňa zákazník požiada o výpis údajov o svojich prejazdoch. Operátor mu však omylom zobrazí aj údaje o inom vozidle, ktoré patrí inej firme.…
Správne nastavené roly a prístupové práva sú základom bezpečnosti a funkčnosti každého systému. Rozhodujú o tom, kto čo môže vidieť, upravovať alebo spúšťať. Nižšie je prehľad najčastejších typov rolí, práv a ich rozdielov.
Príklad
Predstav si klienta, ktorý po rokoch využívania bankovej aplikácie požiada o zrušenie účtu a vymazanie všetkých svojich osobných údajov. Ak systém údaje nesprávne ponechá (napr. e-mail v marketingovej databáze alebo históriu prihlásení v logoch), vzniká riziko porušenia GDPR a vysokých pokút. Tester má preto overiť, že proces výmazu je konzistentný, auditovateľný a nezanecháva citlivé zvyšky.…
Príklad:
Predstav si banku, ktorá zaviedla nový systém na detekciu podozrivých transakcií.
Zákazník napríklad nikdy neposielal peniaze do zahraničia a zrazu zadá prevod vysokej sumy na účet v inej krajine. Systém má takúto anomáliu zachytiť a transakciu označiť alebo dočasne zablokovať.
Ako tester však musíš overiť, či systém funguje správne – či dokáže rozlíšiť bežné správanie od skutočne podozrivého a či zbytočne neblokuje klientov.…
Príklad:
Predstav si, že si tester v banke a máš za úlohu overiť, že bežný zákazník nemá prístup k údajom iného klienta. V praxi to znamená, že ak sa prihlásim ako používateľ A, nesmiem vidieť zostatky, IBANy ani výpisy používateľa B – a naopak.
V jednej firme, kde som testovala, sa stalo, že backend posielal viac údajov, než bolo potrebné.…
Príklad:
Predstavte si mobilnú bankovú aplikáciu, kde sa zákazník neprihlasuje heslom, ale potvrdí vstup buď odtlačkom prsta, rozpoznaním tváre, alebo jednorazovým kódom cez mobilný token. Tento spôsob je dnes bežný v bankovníctve – heslo je slabé miesto, biometria či token výrazne zvyšujú bezpečnosť.
Ako to otestovať?…
1. Overenie toku autentifikácie:
2. Správnosť a jedinečnosť kódu:
Príklad:
Predstavte si interný systém na správu podujatí – organizátori môžu pridávať eventy, upravovať detaily alebo pozývať účastníkov. Dobrovoľníci majú prístup len na čítanie. A bežní používatelia môžu vidieť len verejné podujatia. Všetko beží cez REST API.
Čo všetko treba otestovať:
V niektorých systémoch býva soft delete implementovaný veľmi jednoducho – záznam sa fyzicky neodstráni, len sa v databáze nastaví určitá hodnota (napr. is_deleted = true alebo stav = ‚zmazané‘).
Vďaka tomu sa dá záznam opäť zobraziť úpravou tejto hodnoty, ak je na to oprávnenie. V logoch alebo histórii záznamu býva zaznamenané, kto a kedy záznam zmazal.…
Zmeny roly môžu výrazne ovplyvniť, čo používateľ vidí, čo môže robiť a čo má zakázané. A práve to je výzva pre testerov.
Príklad:
Máme interný systém, kde môže byť používateľ zamestnancom, manažérom alebo adminom. Každá rola má iné oprávnenia – napríklad zamestnanec môže vidieť len svoje dáta, manažér údaje svojho tímu a admin všetko vrátane nastavení systému.…
SQL-injekcia a XSS (Cross-Site Scripting) sú dva najčastejšie útoky, ktoré zneužívajú špeciálne znaky v používateľskom vstupe:
SQL-injekcia
Čo to je?
Útok, pri ktorom útočník vloží do vstupu časť SQL príkazu tak, aby zmenil vykonávanú databázovú operáciu.
Kľúčové znaky:
Single quote ‚ – používa sa na uzavretie reťazcov v SQL.…
