Odpověď na téma: 42 – kraj ZL – obory 01, 18

[Ondřej Budín]

Vážený pane Jando, vážená poroto,

dovolte mi využít možnosti tohoto fóra a připojit se k diskuzi ohledně práce „Webový systém Hvězdárny Zlín“.

S vývojem webových aplikací mám více než šestileté zkušenosti. Jedna webová aplikace je také součástí mé práce „Cesta k IPv6-only síti SŠ-COPT Kroměříž“ v podobně školního intranetu.

Už při letmém pohledu na ukázky PHP kódu v prezentaci ve videu mi bylo jasné, že něco není v „pořádku“.

Na mnoha místech totiž chybí ošetření výpisu textu pomocí funkce htmlspecialchars(), která nám se správným nastavením zajistí korektní ošetření speciálních znaků, jež se mohou objevit v databázi uživatelským vstupem, či jinou cestou.

Aplikace sice provádí nějaké ošetření před uložením dat do databáze, nicméně tato technika není doporučovaný způsob. Jednak připravíme uživatele o možnost vkládat do textu speciální znaky, což je někdy potřeba, ale hlavně tím neošetříme výpis z již kompromitované databáze. Je tak možné, aby útočník do stránky načetl svůj vlastní škodlivý kód, kterým může klidně vylákat z návštěvníků webu i např. údaje do internetového bankovnictví nebo donutit uživatele si nainstalovat do počítače malware.

Navíc, s tím souvisí další problém, kdy pan Janda předem omezil znaky, které se mohou vyskytovat v uživatelském heslu. Omezení znaků v heslu nedává vůbec smysl, je to zbytečná komplikace pro uživatele. Řada uživatelů používá aplikaci správce hesel, která hesla generuje automaticky a samozřejmě, kvůli bezpečnosti, i se speciálními znaky. Takový uživatel by měl problém se na tomto webu zaregistrovat.

Omezení znaků v heslu zavání také otázkou, co autora práce k tomuto kroku vedlo? Pokud totiž jsou hesla ihned ukládána pomocí hashovací funkce password_hash() v PHP, což je takřka jediný způsob, jak s hesly nakládat správně a bezpečně, není pro omezení znaků vůbec žádný důvod. Leda, že by se hesla v databázi ukládala v prostém textu, což by byl další bezpečnostní faul. Mimochodem, funkce password_hash() je hashovací, nikoli šifrovací, jak je uvedeno v práci SOČ. Toto je opravdu důležitý rozdíl.

Po pár minutách strávených procházením webu, jsem narazil na další, a to opravdu velký, bezpečnostní problém. Zjistil jsem, že interní sekce je dostupná i bez přihlášení uživatele. Což se v prohlížeči projeví vykreslením interní nástěnky a prázdných editačních formulářů.

Formuláře jsou sice prázdné, nicméně pokud si je vyplním ručně a zadám ID uživatele, mohu jako nepřihlášený uživatel upravovat libovolný uživatelský účet a například pomocí příkazu níže může útočník změnit opravdu triviálně e-mail, pomocí kterého si následně změní také heslo a získá tak přístup do jakéhokoli účtu.

curl 'http://webzas.wz.cz/web_zas/pages/interni-sekce/upravit-vlastni-ucet.php' -H 'Content-Type: application/x-www-form-urlencoded' --data 'jmeno=admintest2&prijmeni=admin&datumnarozeni=2002-04-03&profilovy-obrazek=&ujmeno=admin&email=admin4%40admin.com&telefon=678541988&heslo=%40%23%26%24%24&status=Admin&datum-vzniku=20.+4.+2020+ve+12%3A31&pocet-prispevku=Ano&id=2&upravit=Upravit'

Toto je opravdu vážný problém, díky kterému v budoucnu může kdykoliv dojít k úniku osobních údajů všech registrovaných návštěvníků a porušení GDPR. A navíc nelze vyloučit, že se v kódu nevyskytuje více takových chyb. To by spolehlivě pomohl odhalit audit kódu a strojové otestování webu.

Dále aplikace při interní chybě zobrazuje příliš podrobností, které by se neměli zobrazovat, ale zapsat do logu na serveru. Tyto chybové hlášky totiž také dokáží útočníkovi prozradit velice cenné informace.

[errno] => 1064
[sqlstate] => 42000
[error] => You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near “ at line 1

Práce na seznámení s webovými technologiemi (např. PHP, SCSS) je to pěkná, nicméně – v zájmu Hvězdárny Zlín a jejich návštěvníků – důrazně nedoporučuji tuto webovou prezentaci nasazovat do ostrého provozu. Mohu doporučit ošetření všech výpisů proměnných, revidovat práci s hesly a zcela přeprogramovat všechny skripty, které pracují s osobními údaji uživatelů nebo se týkají interní sekce.

Jelikož jde o webovou prezentaci, ve které se zpracovávají osobní údaje, měl by kód revidovat zkušenější programátor, který zná principy fungování webových aplikací a ví, jak se řeší bezpečnost.

A pro další projekt mohu doporučit vyzkoušet nějaký PHP framework včetně šablonovacího systému (skvělé je https://nette.org), který dokáže vyřešit tyto bezpečností záležitosti za programátora.

S pozdravem a přáním pevného zdraví
Ondřej Budín