layout: true --- class: middle, center, inverse # Hogyan tervezz biztonságos API-t? ### Becz Tamás, Balasys ??? - A balasysnál régen foglalkozunk proxy alapú tűzfalakkal - Elég jók vagyunk a protokolokban való könyékig turkálásban - Többek között most APIkkal is csinálunk ilyeneket - Nyilván ~15 percben maximum gondolatébresztőket fogok tudni adni --- class: middle, center # Miért is fontos ez? ??? - Mindenhol APIk vannak - fintech - iot Kb bárki, aki ad magára, APIkat használ --- class: middle, center  ??? - Mit jelent ez security szempontból - Tipikus security ábra - Ráadásul még egy kicsit egyszerűsített is, lehetne rajta még jó pár dolog --- class: middle, center  ??? - Az API meg ott van bent - Tipikusan CRUDot csinál a db belsejébe - Ott már nem védenek a külső layerek, észnél kell lenni --- class: middle, center # Ez még mindig a jó öreg web ??? - Ne kövessük el azokat a dolgokat amiket már megtanultunk --- class: middle, center # Info szivárgás ??? Megtanultuk, hogy nem adunk ki mindenféle fölös infót --- class: top, center ## Régen  -- ## Most  ??? - hwsw forum 2005ből --- class: middle, center  ??? API specifikus: - leakelő tracek - Headerek (py X-Powered-By) - Ma már legalább általában nem az a default - Biztos hasznos lesz endpointok - Nem szűrt, biztos hasznos lesz adatok ### Átkötés a TLSre, mint az info védelmi burka --- class: middle, center # TLS ??? - Ha TLS van, minden van - Igabából nem - A TLS fontos, de ha nem azt használod authra, akkor csak a csatorna megbízhatóságát adja, a kliensét nem --- class: middle, center  ??? - Jobb volna, ha ezt valami egységesen csinálná, mert a TLS nehéz tudomány - És sajnos nem olyan, mint egy "átlagos" enterprise project, hogy ha egyszer leszállítottuk a feature setet, akkor azzal hosszan jól ellesz a cég, sajnos állásában megromlik - Szilárd tanúsítványkezelés __holnap délután__ --- class: middle, center # Kerüld az in-house security megoldásokat ??? - Ne találd ki magadnak, nem fog menni. - Nem triviális - Van egy csomó ügyes srác, akik a proci pipelineját hackelik - Van egy csomó okos matekos, akik próbálnak megbízható protokolokat rajzolni. Néha sikerül :) - Drága, mert mindig bonyolult - password manager példa - Igazából végigverni az alapokat konzekvensen, az legalább ugyanilyen nehéz, de azt muszáj lesz neked megcsinálni, mert más nem fogja --- class: middle, center ## 1 HTTP session != 1 business session ??? - egy kliens tranzakció sok HTTP tranzakció - egy API connection sok kliensért felelhet - A REST nem RPC => Ha RPCt akarsz, akkor arra is vannak toolok. json-rpc, soap, valami - REST esetén szükségszerűen a kliensnél van a state/flow control - elég nehéz kontrollálni, mindenképp mindig validálni kell, hogy azt lehet-e - ebből azért több dolog következik ... mert ... --- class: middle, center # A kliens nem megbízható ??? - Persze, ez triviális, de hát mondtam, hogy ez lesz :) --- class: middle, center # Autentikáció / Authorizáció ??? - Először is, tudni kell, hogy ki ő - Persze, használj oauthot -- ## Oauth ??? - Legyél vele tisztában, hogy ezzel outsourceoltad az authentikáció problémáját, és ez nem mindig jó - Szóval arra is a kapcsolatra igen kell figyelni, mert potenciális sebezhetőség, és ugyanúgy külső kapcsolat - redirect_urlt ellenőrizni kell - ha lehet, ne legyen pattern - Ahova küld a redirect, ott semmiképp se tarts redirect_to paramétert - Ahova küld a redirect, ott a külső linkek reffererként meg tudják kapni az auth codeot - Nem teszünk tokent meg kódot urlbe, headerben a helye - Hanyagoljuk az implicit grantet (response_type=token) - Használd a state fieldet a CSRF elkerülésére - Tárold ésszel a secreteket, mert az data at rest, és próbáld csökkenteni a life cycle-t --- class: middle, center # Kliens adatok biztonsága ??? - State taracking miatt Ehhez nyilván le kell tenni userhez adatokat, lesz valami cookie, valami token, valami akármi - Amit visszakérsz, azt garantálni kell, hogy intact-e - JWT pl, de legyél vele tisztában, hogy alapból az nem encrypted - szerializáció - A built in szerializáció kényelmes, és veszélyes. Invest early, később nehezebb - Az API által kezelt blobok továbbra is veszélyesek, egyrészt kergess benne vírusokat, másrészt ha kezeled, akkor ott is vannak szerializációt érintő támadások. --- class: middle, center ## Validáció ??? - Az input data továbbra is nem trusted data - Remek eszközök vannak, csak arra azért figyeljünk, ezek a development folyamat támogatására vannak kihegyezve --- name: jsonbase ## JSON schema .left-column[ ### Schema ```json { "type": "object", "properties": { "name": { "type": "string" }, "e-mail": { "type": "string", "format": "email" } } } ``` ] --- template: jsonbase .right-column[ ### Data ```json { "name": "Jhon Doe", "e-mail": "jhon@example.com" } ``` ] -- .right-column[] --- template: jsonbase .right-column[ ### Data ```json { "name": "Jhon Doe", "e-mail": "jhonexample.com" } ``` ] -- .right-column[] --- template: jsonbase .right-column[ ### Data ```json { "name": "Jhon Doe", "email": "jhonexample.com" } ``` ] -- .right-column[] --- template: jsonbase .right-column[ ### Data ```json { "name": "Jhon Doe", } ``` ] -- .right-column[] --- template: jsonbase .right-column[ ### Data ```json { } ``` ] -- .right-column[] --- template: jsonbase .right-column[ ### Data ```json { "phonenumber": "555-63-15" } ``` ] -- .right-column[] --- name: jsonbase ## JSON schema .left-column[ ### Schema ```json { "type": "object", "additionalProperties": false, "required": ["name", "e-mail"], "properties": { "name": { "type": "string" }, "e-mail": { "type": "string", "format": "email" } } } ``` ] --- class: middle, center, inverse # Köszönöm a figyelmet!