3.5 Zkouškové okruhy

Tato podkapitola obsahuje vypracované odpovědi na otázky k ústní zkoušce z předmětu Etické Hekování pro třetí kapitolu.

Otázka 06: Typical protocols used by web applications: DNS, TLS, HTTP. Server Name Indication (SNI), HTTP methods.

Typické protokoly: Webové aplikace komunikují primárně přes sadu protokolů – od rozkladu jména na IP přes DNS (Domain Name System), šifrování komunikace v TLS/DTLS až po samotný aplikační protokol HTTP (ve verzích 1.1, 2 přes multiplexované TCP či 3 běžící nad QUIC na UDP). Existují i další, např. obousměrný WebSocket.

SNI (Server Name Indication): Jedná se o rozšíření protokolu TLS, při kterém webový prohlížeč již v první šifrovací zprávě (ClientHello) vkládá jméno domény (hostname), na kterou se chce připojit. Umožňuje to jednomu serveru na stejné IP adrese hostovat vícero různých domén s různými HTTPS certifikáty a hned na začátku předložit ten správný. V TLS 1.0–1.2 (a defaultně i 1.3) je odesíláno jako nešifrovaný plaintext. Standard ECH v TLS 1.3 umožňuje jeho šifrování.

HTTP metody:

  • GET: Získání/vyžádání zdroje ze serveru. Neměl by měnit stav (např. měnit data v databázi). Parametry cestují viditelně přímo v URL. Nevhodné pro odesílání citlivých údajů (hesel), jelikož končí v logách serveru, proxy či historii.
  • POST: Odesílání dat, změna záznamů. Parametry jsou v těle dotazu (Body). Doplňuje se o hlavičky Content-Type a Content-Length. Není limitováno délkou zprávy, data se v logách typicky automaticky neobjevují.
Otázka 07: URL, Same-Origin Policy (SOP), Cross-Origin Resource Sharing (CORS).

URL (Uniform Resource Locator): Odkaz na konkrétní zdroj skládající se ze Schématu (např. http, https), Autority (obsahuje Host / jméno domény a Port), Cesty (Path), Volitelných parametrů dotazu (Query) oddělených &, a Fragmentu #. Znaky jako mezera nebo /, = se musí kódovat (např. URL encoding). Je obvykle uživatelsky přístupné a tvoří základ interakce.

SOP (Same-Origin Policy): Bezpečnostní koncept uvnitř webových prohlížečů bránící kódům a skriptům v přístupu k datům na jiné doméně. Origin je definován trojicí: protokol, hostname, port. Pokud se libovolný z nich liší, prohlížeč sice cílový server kontaktuje, ale výsledek/odpověď nepustí zpět k zobrazení/použití JavaScriptem, čímž izoluje data jednoho serveru od druhého.

CORS (Cross-Origin Resource Sharing): Mechanismus, kterým se dá chránění ze strany SOP obejít, je-li to žádoucí. Cílový webový server může pomocí HTTP hlavičky Access-Control-Allow-Origin výslovně uvést seznam původu (origin), pro které je čtení dat u cizích domén povoleno (např. integrace externího API na vlastní web).

Otázka 08: Authentication and session management in web applications (different mechanisms, relevant vulnerabilities).

Základní mechanismy:

  • Cookie-based: Přiřazení relačního ID uloženého v cookie po přihlášení (Session ID).
  • Token-based: Využití JWT, API klíčů pro stateless autentizaci.
  • Další typy zahrnují Client certifikáty (mTLS) či zabudovanou HTTP autentizaci (Basic, Digest).

Související zranitelnosti (Autentizace): Užívání defaultních účtů (admin/admin), předávání hesel přes HTTP (nebo Base64 encode bez šifrování), uživatelská enumerace, slovníkové/brute-force útoky (slabá politika hesel, žádný lock-out), bypass skrze SQLi.

Správa relací (Session management):

  • Mnoho slabin spočívá ve špatném nastavení flagů u relační cookie. Je potřeba využívat flag Secure (přenos jen přes HTTPS), HttpOnly (zákaz přístupu přes JavaScript bránící ukradení při XSS) a SameSite (obrana před CSRF).
  • Klíčovými problémy bývají dále Session fixation (útočník si vynutí své dopředu vytvořené a platné ID na oběť), Exposed session variables (Session ID jako součást GET URL), špatný odhlašovací proces (staré ID po log-outu server stále akceptuje jako ověřené) nebo nevypršení relace (timeout).
Otázka 09: Cross-Site Request Forgery (CSRF): description, mitigation, common bypass techniques.

Popis: Útok CSRF probíhá tak, že útočník pomocí sociálního inženýrství či lsti přiměje pro danou službu přihlášenou oběť, aby z jejího prohlížeče nevědomky odeslala škodlivý request na aplikační server (např. pomocí formuláře zaslaného na pozadí, modifikace prvku iframe nebo i skrytým obrázkem zavěšeným na GET dotaz). Využívá se toho, že prohlížeč automaticky k takovému požadavku přilepí i ověřovací cookie oběti pro daný web, a z pohledu serveru je tedy akce validní a je spuštěna v jejím oprávněném kontextu (např. převod peněz v bance).

Způsoby mitigace (Obrany):

  • Vyžadování anti-CSRF tokenů – náhodně vygenerované neuhodnutelné tajemství, které se přidává do formulářů / HTTP hlaviček.
  • Ověření hlaviček Origin a Referer.
  • Bezpečné nastavení atributu SameSite na cookies u klienta.

Běžné metody Bypassu:

  • Pokud je pole na CSRF přítomné, ale nevyplněné (odstranění hodnoty).
  • Pokud úplně smažeme klíč tokenu v odesílaném payloadu a aplikace předpokládá chybějící = chráněný.
  • Oklamání změnou POST na GET (Někdy server verifikuje anti-CSRF jen u POST volání).
  • Využití cizího tokenu – například z neautentizovaného profilu (pokud server testuje jenom platnost struktury, a ne vazbu k uživateli).