Zabezpečenie aplikačného programového rozhrania

Obsah práce

1.	Princíp aplikačného programového rozhrania
2.	Zabezpečenie aplikačného programového rozhrania
3.	Analýza aplikácie SAPI
4.	Návrh a implementácia aplikácie SAPI

Cieľom zabezpečenia systému, ktorý má prístup na internet alebo môžu k nemu pristupovať neoprávnení používatelia, je: ochrana pred nepovoleným prístupom do systému, ochrana pred neoprávnenou manipuláciou s dátami, bezpečná komunikácia a prenos dát. Nevyhnutnou časťou zabezpečenia je správny návrh API, čo zahrňuje správne definovanie dátových typov, rozsahov a koncových bodov. Pri aplikácií návrhu to núti vývojára tieto definície z návrhu dodržať. Rozdelenie zabezpečenia:
Autentifikácia
Proces, v ktorom sa overuje identita používateľa. Mechanizmus pomocou ktorého sa priraďujú identifikačné a autentizačné údaje z prichádzajúcej žiadosti. Identifikačné a autentizačné údaje sa porovnávajú s tými, ktoré sú uložené v databáze autentifikačného servera . Proces autentifikácie je rozdelený na dve fázy:

1. Identifikácia: Fáza, v ktorej používateľ poskytuje identifikačné údaje systému, ako e-mail, meno používateľa alebo prihlasovacie ID. Systém si vyžiada identifikačné údaje (Kto si?). Používateľ odpovedá zadaním údajov (napríklad Maťo) .
2. Autentizácia: Slúži na overenie identity používateľa jedinečným overovacím prvkom, ako heslo, certifikát alebo vygenerovaný kľuč. V tejto fáze si systém vyžiada autentizačné údaje (Tvrdíš, že si Maťo. Ak si to ty, preukáž sa jedinečným prvkom). Akonáhle používateľ zadá autentifikačné údaje, systém ich následne vyhľadá v databáze a porovná (citlivé údaje, ako heslo sú zakódované a systém ich musí rozkódovať). Ak sa údaje zhodujú, používateľ je overený, a ak sa nezhodujú, systém upozorní používateľa na zle zadané údaje .
   

Autorizácia
Nasleduje hneď po autentifikácii. Nastavuje práva a rolu používateľa, ktorý sa prihlasuje. Každý používateľ môže mať jednu alebo viacero rolí, z ktorých plynú určité práva. Z tých následne vyplýva, ku ktorým dátam ma používateľ prístup a ku ktorým nie .

Zabezpečenie REST API

Systém, ktorý sa pokladá za REST API by mal byť bezstavový, to znamená, že žiadosť autentifikácie alebo autorizácie by nemala závisieť od súborov cookie alebo relácií (sessions). Preto každá požiadavka z REST API by mala prísť s istým druhom autentifikačných údajov, ktoré sa pre každú požiadavku overujú na serveri . Postupy pre zabezpečenie REST API:

• Jednoduchosť: zahŕňa výber vhodného (jednoduchého) spôsobu zabezpečenia. Je zbytočné používať komplexné zabezpečenie, ak nie je treba), pretože sa tak zvyšuje chybovosť zabezpečovacej metódy .
• Používanie HTTPS: používaním zabezpečeného hypertextového prenosového protokolu (HTTPS) sa zaistí ochrana pred odpočúvaním komunikácie a je možné bezpečne používať spôsoby autentifikácie, ako sú jednoduchá autentifikácia a API kľúč .
• Šifrovanie hesla: heslo musí byť vždy zašifrované vhodným šifrovacím algoritmom pre zvýšenie bezpečnosti systému .
• Neposielať informácie v adrese URL: údaje, ako používateľské meno, heslo, token alebo API kľúč, by sa nikdy nemali zobrazovať v adrese URL. Tieto údaje sa môžu zapisovať do záznamov servera (server logs), a tým sa stávajú ľahko dostupné .
  

https://api.domena.sk/pouzivatel/<span>id</span>/akcia?apiKey=abc123  - nevhodné použitie API kľúča

Jednoduchá autentifikácia (Basic authentication)

Patrí k najjednoduchším metódam. Pri tejto metóde odosielateľ žiadosti posiela meno a heslo v hlavičke žiadosti. Meno a heslo sú zakódované pomocou kódovania Base64. Táto metóda nevyžaduje súbory cookie, ID relácií, prihlasovacie stránky alebo ďalšie špeciálne riešenia. Za bezpečnú sa táto metóda pokladá v prípade použitia spolu s HTTPS .
Na obrázku 2.1 môžeme vidieť príklad komunikácie medzi odosielateľom žiadosti a autentifikačným serverom. Žiadateľ pomocou metódy GET žiada o prístup ku zložke domov (home). Server mu posielala stavový kód 401 (Neoprávnený). Následne žiadateľ, po zadaní mena Mato a hesla Heslo (na obrázku 2.1 zakódované pomocou Base64), odosiela žiadosť s jednoduchou autentifikáciou. Server údaje overil a posiela stavový kód 200 (V poriadku).

Obr 2.1 Komunikácia medzi klientom a serverom pri jednoduchej autentifikácii

API kľúč (API key)

Patrí medzi metódy, ktoré sa jednoducho implementujú, avšak poskytujú základné bezpečnostné overenie. API kľúče boli navrhnuté tak, aby opravili problémy, ktoré vznikali pri používaní jednoduchej autentifikácie. Pri tejto metóde je používateľovi priradený jedinečný kľuč, ktorý sa môže generovať na základe IP adresy alebo náhodne serverom. Ak sa používateľ pokúša opätovne prihlásiť do systému, preukáže sa pomocou tohto jedinečného kľúča, že sa jedná o toho istého používateľa, ktorému bol kľuč vygenerovaný. Metóda sa odporúča používať s protokolom HTTPS, pretože je možné komunikáciu zachytiť a vyčítať z nej kľúč .
Komunikácia medzi serverom a klientom pri API kľúči prebieha podobne ako pri jednoduchej autentifikácií, ako je možné vidieť na obrázku 2.2. Žiadateľ pomocou metódy GET žiada prístup k zložke domov (home) a server odpovedá stavovým kódom 401 (Neoprávnený). Pre prístup k zabezpečenej zložke žiadateľ odosiela v hlavičke autorizácie informácia o tom, že sa používa autentifikácia pomocou API kľúča spolu s vygenerovaným API kľúčom. Server API kľúč overí a odpovie stavovým kódom 200 (V poriadku).

Obr 2.2 Komunikácia medzi klientom a serverom s využitím API kľúča

Webový token vo formáte JSON (JWT)

Webový token vo formáte JSON (JWT - JSON Web Token) je štandard (RFC 7519), ktorý definuje bezpečný spôsob prenosu informácií medzi dvoma stranami s použitím formátu JSON. Prenášané informácie sú overené a dôveryhodné, pretože sú digitálne podpísané. Digitálny podpis sa realizuje pomocou hašovaného autentifikačného kódu (HMAC) alebo pomocou kľúčov ECDSA (Elliptic Curve Digital Signature Algorithm) a RSA (Rivest–Shamir–Adleman). Token môže dešifrovať ktokoľvek, ale pre správne overenie je potrebné poznať tajný kľúč (secret). Podpísaný token pomocou digitálnych podpisových kľúčov potvrdzuje, že ten, kto je držiteľom súkromného kľúča je ten, kto ho podpísal. Vygenerovaný token je uložený u používateľa . Webový token JSON sa využíva na:

1. Autorizáciu: Najbežnejší spôsob použitia JWT. Akonáhle je používateľ prihlásený, každá ďalšia žiadosť pre prístup k službám, zdrojom a dátam, bude obsahovať vygenerovaný token pre overenie prístupu používateľa .
2. Výmena informácií: JWT sa využíva na bezpečný prenos informácií medzi dvoma stranami. Využitím digitálneho podpisu pomocou kľúčov si odosielateľ alebo prijímateľ môže byť istý, že komunikuje so správnou stranou. To znamená, že pomocou JWT sa overuje, či odosielateľ alebo prijímateľ je naozaj ten, za koho sa vydáva.

Štruktúra JWT
Webový token vo formáte JSON sa skladá z troch častí, ktoré sú oddelené bodkami a zakódované pomocou Base64url ako je možné vidieť na ukážke kódu [JWTcode], Kde červená časť tokenu je zakódovaná hlavička, oranžová časť je zakódované zaťaženie a modrá časť obsahuje zakódovaný podpis .

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIi
wibmFtZSI6Ik1ldGVqIiwiYWRtaW4iOnRydWV9.
WzxPY5cMpf7zZfEKFcoF4EKF7uFSRTDjW5RxY12q4QY [JWTcode]

Kód 2.1: Webový token JSON

Hlavička (Header)
Hlavička zvyčajne obsahuje dva údaje: typ tokenu (na ukážke kódu 2.2 typ), čiže JWT, a algoritmus digitálneho podpisu, ktorý sa využíva. Na ukážke zdrojového kódu [JWTheader] sa využíva HS256. Zakódovaná hlavička pomocou Base64url reprezentuje prvú časť tokenu .

{
    "alg": "HS256",
    "typ": "JWT"
}

Kód 2.2: Hlavička JWT

Zaťaženie (Payload)
Druhá časť tokenu je zaťaženie, v ktorom sú definované požiadavky. Požiadavky sú údaje o danej entite (väčšinou o používateľovi) a ďalšie dáta. Požiadavky môžeme rozdeliť do troch skupín :
Registrované požiadavky
Súbor preddefinovaných požiadaviek, ktoré nie sú povinné ale odporúča sa, aby boli používané. Patria tam:

• vydavateľ (issuer, "iss"): identifikuje vydavateľa, ktorý vydal JWT token. Spracovanie tejto požiadavky je špecifické pre každú aplikáciu.
• subjekt (subject, "sub"): identifikuje subjekt pre vydanie JWT. Hodnota musí byť upravená tak, aby bola jedinečná pre vydavateľa (issuer) alebo globálne.
• publikum (audience, "aud"): identifikuje príjemcov, ktorým je JWT token určený.
• čas expirácie (expiration time, "exp"): definuje čas expirácie vydaného tokenu.
• čas akceptovania (not before, "nbf"): definuje čas, pred ktorým JWT nemôže byť akceptovaný na spracovanie.
• čas vydania (issued at, "iat"): definuje čas, v ktorom bol JWT vytvorený.
• JWT ID ("jti"): definuje jedinečný identifikátor pre JWT.
  

Verejné požiadavky
Používatelia JWT môžu tieto požiadavky ľubovolne definovať. Aby sa predišlo kolíziám, mali by byť definované v oficiálnom registri (IANA JSON Web Token Registry).
Súkromné požiadavky
Sú to požiadavky, ktoré si môže vytvoriť každý používateľ JWT na súkromné účely. Nepatria k registrovaným požiadavkám a nie sú zaznamenané ani vo verejnom registri.
Ukážka kódu zaťaženia [JWTpayload] v sebe obsahuje registrovanú požiadavku subjekt (sub) a vlastné požiadavky meno (name) a administrátor (admin). Po zakódovaní Base64url sa zaťaženie nachádza na druhej pozícií tokenu.

{
    "sub": "123456789",
    "name": "Matej",
    "admin": true
}

[JWTpayload]

Podpis (Signature)
Pre vytvorenie podpisu je potrebné mať zakódovanú hlavičku (header), zakódované zaťaženie (payload), tajný kľúč (secret) a algoritmus uvedený v hlavičke. Pri použití HMAC a SHA256 algoritmu sa podpis vytvorí spôsobom, ako na ukážke zdrojového kódu [JWTsignature]. Podpis overuje, že správa sa počas prenosu nezmenila a v prípade tokenov podpísaných súkromným kľúčom, či je odosielateľ JWT ten, za koho sa vydáva .

{
   HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret)
    
}

[JWTsignature]

Žiadosť pomocou JWT
Ukážka kódu [JWTreq] zobrazuje žiadosť pomocou HTTP metódy GET na koncový bod definovaný v adrese URL. Hlavička autorizácie obsahuje JWT token označený ako Bearer.

{
  "method": "GET",
  "url": "http://localhost:3000/nsoric/auth/application/1",
  "headers": {
  "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
    .eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZ
    SI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
    .SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
    }
}

[JWTreq]

Štandard OAuth

Je to štandard určený pre používateľov internetu a umožňuje prístup web stránkam alebo aplikáciám k dátam používateľa, bez zadania hesla, pomocou serveru overenia tretích strán. Pri tejto metóde sa používateľ prihlási do systému. Systém si vyžiada autorizáciu vo forme tokenu. Používateľ posunie žiadosť na autorizačný server, ktorý odmietne alebo povolí túto žiadosť. Po tomto kroku je token poskytnutý používateľovi a potom žiadateľovi autorizácie. Overenie tokenu môže prebehnúť kedykoľvek a môže byť použitý viackrát, pokiaľ je platný. Výhodou tejto metódy je, že používateľ nemusí opätovne zadávať heslo. Systém, ktorý požaduje používateľove dáta, dostane prístup len k dátam, ktoré požaduje a nie ku všetkým dátam .
Rozdelenie štandardu OAuth
Rozdeľuje na dve verzie: OAuth 1.0 (staršia verzia) a OAuth 2.0 (novšia verzia). Princíp OAuth 2.0 vychádza z OAuth 1.0, ale spolu nie sú kompatibilné. OAuth 2.0 je rýchlejšia a jednoduchšia na implementáciu ako OAuth 1.0. Hlavné rozdiely medzi OAuth 1.0 a OAtuh 2.0 sú :
OAuth 1.0

• Prenosovo nezávislá: pri prenose nemusí využívať HTTPS.
• Využíva šifrovanie a hlavne digitálne podpisy: digitálne podpisy sú používané pre potvrdenie integrity a autenticity správy. Zaisťujú, že správa bola odoslaná zo špecifikovaného miesta a nebola sfalšovaná počas prenosu.
• Každá správa je individuálne šifrovaná: ak je jedna časť správy podpísaná nesprávne, celá komunikácia sa pokladá za neplatnú.
  

OAuth 2.0

• Prenosovo závislá: väčšina bezpečnostných opatrení je delegovaná na HTTPS.
• Využitie bearer tokenu: bearer token je možné jednoducho integrovať do systému, ale nie je najvhodnejší z hľadiska bezpečnosti, pretože môže byť skopírovaný alebo ukradnutý.
• Jednoduchšia práca: s OAuth 2.0 sa dá jednoduchšie pracovať a implementovať v systéme, ale je náročnejšie túto metódu poriadne zabezpečiť.
• Väčšia flexibilita: OAuth 1.0 sa využíva len pre webové aplikácie. OAuth 2.0 sa môže využívať pre webové aplikácie, mobilné aplikácie alebo desktopové aplikácie.
• Lepšie rozdelenie povinností: spracovanie rôznych požiadaviek môže byť rozdelené.
  

Spôsoby získania prístupového kódu
OAuth 2.0 využíva rôzne spôsoby ako získať prístupový token. Môžme ich rozdeliť do štyroch skupín:

1. Udelenie autorizačného kódu (Authorization code grant): vydá kód, ktorý sa použije pre získanie prístupového tokenu. Tento kód sa po prihlásení uvoľní do klientskej aplikácie. Prístupový token je vydaný na strane servera.
2. Implicitná podpora (Implicit Grant): prístupový token sa vydá okamžite po prihlásení.
3. Poverenie klienta (Client Credential Grant): prístupový token sa vydáva na strane servera. Slúži na overenie aplikácie nie používateľa.
4. Udelenie hesla (Password Grant): prístupový token je udelený okamžite a žiadosť obsahuje všetky informácie pre prihlásenie (meno, heslo, id klienta, tajný kľúč klienta).

Obr. 2.3 Ukážka komunikácie pri implicitnej podpore

Zúčastnení aktéri
Na obrázku 2.3 je zúčastnených viacero aktérov, ktorí vystupujú pri komunikácií.
Používateľ: osoba, ktorá chce byť autorizovaná pre získanie prístupu k dátam.
Aplikácia: webová aplikácia, ktorú chce používateľ použiť.
Autorizačný server: vykonáva autentifikáciu a autorizáciu a generuje token.
Dátový server: obsahuje dáta, ku ktorým chce používateľ získať prístup.
Postup autorizácie na obrázku 1.3

1. Prihlásenie do aplikácie: používateľ sa chce prihlásiť do aplikácie a klikne na tlačidlo prihlásenie pomocou OAuth.
2. Presmerovanie na autorizačný server: aplikácia presmeruje používateľa na autorizačný server spolu s parametrami. Použité parametre sú:
   

id aplikácie: identifikuje aplikácie.
adresu presmerovania: adresa, kam autorizačný server pošle autorizačný kód.
typ odpovede: definuje typ odpovede, ktorú posiela autorizačný server.
rozsah: obsahuje povolenia, ktoré bude používateľ požadovať.
stav: voliteľný parameter, slúži na získanie stavu aplikácie.

1. Kontrola žiadosti: server kontroluje všetky parametre žiadosti.
2. Zobrazenie prihlasovacieho formulára: používateľovi sa zobrazí prihlasovací formulár, kde musí zadať meno a heslo.
3. Vloženie mena a hesla: používateľ vloží meno a heslo aby sa prihlásil.
4. Kontrola mena a hesla: autorizačný server skontroluje, či sú meno a heslo správne.
5. Odoslanie prístupového tokenu na adresu presmerovania: autorizačný server vygeneruje prístupový token a odošle ho na adresu špecifikovanú v žiadosti.
6. Vytvorenie žiadosti s prístupovým tokenom: aplikácia vytvorí žiadosť na dátový sever spolu s prístupovým tokenom.
7. Kontrola tokenu: dátový server skontroluje platnosť tokenu.
8. Kontrola prístupového tokenu autorizačným serverom: dátový server odošle token na autorizačný server a žiada jeho validáciu.
9. Vrátenie požadovaných dát: ak je všetko v poriadku, dátový server vráti požadované dáta.
10. Zobrazenie dát: aplikácia zobrazí požadované dáta používateľovi.