Autorizace a autentifikace

Autorizace a autentifikace

Autentifikace

• často autentizace
• ověření totožnosti
• způsob přihlašování do aplikace
• přístupové údaje
• biologický zámek
• přístupové karty
• ...
• často více faktorů či fází

Autorizace

• způsob ověření totožnosti
• omezení, co může uživatel dělat
• různé způsoby
• role
• jednotlivé oprávnění
• ACL
• má přístup k specifickým zdrojům?

Způsoby uchovávání přihlášení

Session

• ukládá se na serveru
• při prvním přístupu se vytvoří nová session
• kód k session pošle server klientovi
• při každém dalším přístupu se session obnoví
• často kód v cookies či jiném úložišti
• můžeme ukládat další metadata

Session výhody

• datům může přistupovat pouze server
• věříme informacím
• při ztrátě kódu session zůstávají data na serveru
• možné např. i sdílet session mezi více aplikacemi

Session nevýhody

• potřeba ukládat data na server — často mnoho dat
• nutné řešit mazání, ukládání a podobné problémy
• bezpečnostní problémy — leak session
• problémy session v URL (PHPSID) a hloupost uživatelů

Session

Práce

Zkusme vymyslet naivní implementaci session. Porovnáme ji s již existujícími řešeními ve vašich jazycích a frameworcích pro backend.

Přihlašovací token

• ukládá se na klientovi
• localstorage, cookie, sessionstorage
• při přihlášení se vytvoří token a uloží se na klientovi
• při každém dalším přístupu se token odesílá na server v hlavičce
• často neukládáme žádná další data

Typy tokenu

Náhodný řetězec

• uchovává se u klienta a serveru
• neuchovává žádné informace přímo
• nutné ukládat seznam tokenů
• jednoduchá deaktivace tokenu (máme je uložené)

JWT

• JSON Web Token
• čitelný formát, který je však zabezpečen podepsáním
• může obsahovat další informace
• base64
• https://jwt.io/

JWT

• header.payload.signature
• části header a signature nemáme (logickou) šanci upravit
• část payload často obsahuje:
• data
• časovém omezení — expirace, not before, issued at
• vydavatele
• problém s odhlášením — musí nám říct klient a my musíme nějakým způsobem token deaktivovat

JWT

Práce

Ukážeme si, jak se s JWT pracuje v nějakém jazyku a jak se používá.

OAuth 2.0

• autorizační framework
• často se používá i jako pouze autentizace
• definuje standardy jak probíhá přihlašování
• především komunikace třetích stran s API
• přístup bez nutnosti uživatele
• založen na přístupových tokenech

Proč?

• chceme přistupovat k datům uživatele jako aplikace třetí strany
• nechceme uživatele zatěžovat přihlašováním
• nechceme mít uživatelovi přihlašovací údaje
• chceme mít jasně definované co může aplikace s mým účtem dělat
• chceme mít možnost deaktivovat přístup aplikace k mým datům

Role v OAuth

• resource owner = přiřazení práv k prostředkům
• resource server = příjímání požadavků s tokenem
• client = aplikace dělající požadavky
• authorization server = autorita vydávající tokeny

    +--------+                               +---------------+
    |        |--(A)- Autorizační požadavek ->|    Majitel    |
    |        |                               |   prostředku  |
    |        |<-(B)- Autorizační povolenka --|               |
    |        |                               +---------------+
    |        |
    |        |                               +---------------+
    |        |--(C)- Autorizační povolenka ->|  Autorizační  |
    | Klient |                               |     server    |
    |        |<-(D)--- Přístupový token -----|               |
    |        |                               +---------------+
    |        |
    |        |                               +---------------+
    |        |--(E)--- Přístupový token ---->|     Server    |
    |        |                               |   prostředků  |
    |        |<-(F)------- Prostředek -------|               |
    +--------+                               +---------------+
                    

Autorizační povolenka

• = authorization grant
• různé způsoby
• Client credentials grant — posílají se informace klienta, pouze interní aplikace
• Authorization Code — viz minulý slide, klient nevidí token
• Implicit — rovnou se vrací token, není refresh token

Refresh tokens

• nepovinný obnovovací token
• díky němu lze při expiraci přístupového tokenu získat nový
• autorizační server

Access tokens

• = přístupový token
• náhodný textový popis
• zašifrovaná zpráva (podepisuje aut. server)
• často i JWT

Registrace klienta

• pro přístup třetích stran do přihlašování je nutné zaregistrovat klienta
• informace o aplikaci
• typ klienta
• zpětné odkazy

Více o OAuth2

https://oauth.net/2/

IETF

https://www.youtube.com/embed/KT8ybowdyr0

https://documentation.openiddict.com/guides/choosing-the-right-flow.html

Způsob řešení práv v systému

Způsob řešení práv v systému

• máme aplikaci a uživatele
• chceme omezit:
• co uživatel vidí
• co uživatel může dělat
• různé pohledy dle typu aplikace
• často kombinujeme různé způsoby na míru aplikace

Role

• máme roli a uživatele, uživatel může mít více rolí a role může mít více uživatelů
• v kódu při určitých akcích (např. mazání) kontrolujeme, zda má uživatel danou roli
• v databázi


• levely rolí
• mějme: admin, user, guest
• je tedy jasné, že admin je ale zároveň i user a tak dále

Role

• problémy s rozšiřováním aplikace — rozdělování částí aplikace mezi více rolí
• často mnoho rolí, není jasný vztah mezi nimi
• nějaké zdroje jsou určeny jen pro jednu skupinu uživatelů, ale zde často jednáme pouze s typem zdroje
• různé způsoby tvorby rolí — pevně stanovené v kódu, dynamické v databázi
• docela jednoduché

Oprávnění

• máme pevně stanovené oprávnění pro každou akci — USER_READ, USER_WRITE, USER_DELETE
• tyto role přímo nastavujeme uživatelům nebo (dynamickým) rolím
• velká možnost přizpůsobení a konfigurace
• oprávnění je hodně, můžeme v podstatě nekonečně dělit a rozšiřovat
• znovu problém s viditelností různých specifických zdrojů
• skoro jistě (min. z frontendové pohledu) potřebujeme k USER_DELETE i USER_READ
• co když chceme smazat jiného uživatele, který je nadřazené role? kdy je nadřazená?

Access Control List

• = ACL
• každý zdroj má svůj seznam oprávnění
• každý uživatel má svůj seznam oprávnění
• při každé akci se kontroluje, zda má uživatel oprávnění
• můžeme přesně nastavit ke každému zdroji oprávnění
• problém se složitým nastavením

Kombinace všeho

• často kombinujeme všechny tři způsoby
• role pro základní rozdělení
• oprávnění pro detailní nastavení
• ACL pro specifické zdroje
• často např. i oprávnění globální vs. pro zdroj

Oprávnění portálu

Práce

Zkuste zjistit či vymyslet, jak je na mém školním portálu vyřešen systém oprávnění.

Testování serverů

Testování obecně

• testování lze ručně a automatizovaně
• ruční testování? — časově náročné, chybové
• automatizované testování? — rychlé, opakovatelné, nutné naprogramovat
• chceme si být jistí, že server funguje tak, jak má
• existuje spousta teorie — black/white-box, způsoby, ...

Co testovat?

• jednotlivé endpointy
• repozitáře, služby a další
• jednotlivé třídy

Specifikace

• již se budeme zaměřovat jen na jednotkové testy a testy endpointové
• endpointové — voláme HTTP endpointy a zjištujeme výstup
• jednotkové — testujeme jednotlivé služba odděleně

Problémy

• nutné řešit stav aplikace
• restování stavu, posílání dat
• závislosti dat mezi sebou

Testování

Práce

Ve vámi vybraném jazyku a frameworku si napíšeme jednoduché jednotkové testování a poté zkusíme i testování endpointové.

Útoky na backendu

XSS

• Cross-Site Scripting
• útočník vkládá do stránky kód, který se spustí
• např. input komentáře, vloží se HTMl a to se na frontendu vykreslí jako kód
• útočník může získat cookies, hesla, ... od všech, kdo se podívají na stránku
• řešení?

CSRF

• Cross-Site Request Forgery
• útočník využívá toho, že uživatel je přihlášený
• útočník vytvoří stránku, která po otevření pošle požadavek na server
• útočník může např. smazat účet, změnit heslo, ...
• řešení?

Další útoky

Práce

Zjistěte, jaké další útoky útoky existují na backend/frontend a jak se proti nim bránit.