Problematika zabezpečení REST rozhraní

[Ladislav Zitka]

Důrazně doporučuji REST api nezabezpečovat. Ušetříte si tím hromadu starostí, které to zabezpečení přinese.

Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.

[Reklama]

[Ladislav Zitka]

Důrazně doporučuji nic nevymýšlet, věřte, že s nějvětší pravděpodobností to jen pos...te. Pro zabezpečení API se nejčastěji používá Basic authentication nebo JWT. Obojí je standardizované, jednoduché a nerozumím tomu, proč by implementace měla zabírat 33MB. Na obojí najdete plný pytel knihoven a bude vám to fungovat napříč jazyky a implementacemi (frameworky). Jestli si kvůli autentizaci taháte nějakou obří knihovnu, doporučuji se zamyslet, zda ji opravdu potřebujete.

Pro zabezpeceni API se pouziva nejcasteji Basic auth nebo JWT -> to je vystup z nejakeho globalniho pruzkumu, nebo jen subjektivni nazor, co kde pouzivate sam na projektech? :-)

[Eržika]

Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.

Všechny api by měli být veřejné, citlivé části jako private s omezením na firewallu na ip. Zabezpečení "heslem, oauth2, jwt,.." na api je přežitek. Stejně tak jako všechny zdrojové kódy by měli být povinně opensource.

[Eržika]

private api s omezením na firewallu na ip

Aby mě nikdo nenařkl že zabezpečení na ip je nebezpečné, či že ip se často mění (tak určitě), tak stačí namísto IP využít TXT DNS record a vůči němu se api ověří. Vzhledem k https+dnssec je to lepší než jakékoliv jiné zabezpečení.

[perceptron]

Security v praxi bývají docela molochy a mám teď na mysli Spring Boot Security, která mi zhoršila start aplikace tak o 15% a o dalších 15% mi zvětšila výstupní Jar-with-dependencies.

spring security vam da oauth ak chcete a out of box vyriesi cors, csrf, prip. jwt a dalsie veci ktore na vasej urovni naimplementujete po deadline a zle

15% narast startu je drobnost. 15% narast JAR - z 30 mega na 45? nosite jar na disketach?

[Reklama]

[.]

Ok no, tak jdu stavet burzovni system s verejnym API pro management fondu a nebudu to zabezpecovat, diky za super radu.

Všechny api by měli být veřejné, citlivé části jako private s omezením na firewallu na ip. Zabezpečení "heslem, oauth2, jwt,.." na api je přežitek. Stejně tak jako všechny zdrojové kódy by měli být povinně opensource.

A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.

[Eržika]

A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.

A kdo zde mluví o uživatelích? V průvodní otázce se mluví přesně o aplikaci v js a backendu v rest, který chce zaheslovat.

Mám nějaký backend, jedno v čem napsaný, a chci mu zaheslovat REST. Frontend je zcela zvlášť, v javascriptu.

Takže frontend běží na nějakém serveru. server nemá pevnou ip? Pokud by šlo o api pro uživatele tak by tam přeci byl oauth, či jwt. Ale api je lepší míti public odpadne tím hromada starostí.

Mj fyi Eržika jak by vám moje jméno mělo napovídat je ženského původu. Ale chápu že si myslíte že cikánky nemohou programovat, že jen smrdíme na dávkách. Na dyskrymynace jsem ale zvyklá takže ok

[.]

A tu fixní IP adresu pro uživatele zabezpečíte jak, pan{e,í} fundamentalist*o.

A kdo zde mluví o uživatelích? V průvodní otázce se mluví přesně o aplikaci v js a backendu v rest, který chce zaheslovat.

Mám nějaký backend, jedno v čem napsaný, a chci mu zaheslovat REST. Frontend je zcela zvlášť, v javascriptu.

Takže frontend běží na nějakém serveru. server nemá pevnou ip? Pokud by šlo o api pro uživatele tak by tam přeci byl oauth, či jwt. Ale api je lepší míti public odpadne tím hromada starostí.

Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Mj fyi Eržika jak by vám moje jméno mělo napovídat je ženského původu. Ale chápu že si myslíte že cikánky nemohou programovat, že jen smrdíme na dávkách. Na dyskrymynace jsem ale zvyklá takže ok

Žádné dyskrymynace jsem se na vás nedopustil, možná, že jste si nevšimla, ale příspěvek jsem směřoval tak, abych oslovil všechna možná pohlaví. Je mi jedno, zda jste žena, muž nebo transvestita. Fajn, přejete si, abych Vás oslovoval jako ženu, to je super, ale z názvu nicku (navíc anonymního) nelze na internetu vyvozovat opravdu nic.

[gadzo]

zabezpecte pomocou token based authentication, mozete si ukutit sam, ale radsej pouzite nejaky framework/kniznicu , usetrite si nervy.
ak erzika je naozaj erzika , tak klobuk dolu , niekdo smrdi na davkach, niekto v kode [ code smell ]
ale urcite je lepsie smrdiet v kode :-D

[_Tomáš_]

Typl bych si ze duvodem bude, ze basic auth nepodporuje logout.

Tak credential je pouze enkodovane v Base64 a posila se po lince. Samozrejme TLS to prekryje, ale dalsi problemy jsou napr.:
- Heslo se posila stale dokola pro kazdy request v hlavicce
- Chybi dalsi rozsirene protekce jako Nonce, TTL, request timestamp, apod.pro zamezeni reply utoku

Ale jako, pokud se jedna o interni systemy, tak to nemusi byt problem, pokud se o dalsi bezpecnost staraji firewally, nebo dalsi prvky. Samozrejme stale to plati pouze pro TLS secured pripojeni.

Diskuze je o REST rozhraní, nemusí se očekávat, že se přihlašovací údaje budou zadávat v prohlížeči. Odhlášení chybí by design, není ale běžné, že by se aplikace na pozadí sama odhlašovala, to je běžnější pro interakci s uživatelem.

Zmíněné problémy je možné vyřešit zabalením do oauth, spnego, které timestampy, Nonce, TTL mají. Mimochodem, velká část korporátních SSO používá spnego s interním AD a poté REST s basic auth zase takový problém není .

[Eržika]

zabezpecte pomocou token based authentication, mozete si ukutit sam, ale radsej pouzite nejaky framework/kniznicu , usetrite si nervy.
ak erzika je naozaj erzika , tak klobuk dolu , niekdo smrdi na davkach, niekto v kode [ code smell ]
ale urcite je lepsie smrdiet v kode :-D

A já furt myslím že lepší je nezabezpečovat nic. Cikáni vám stejně ukradnou všecko i když to zabezpečíte. Zbytečná práce s tím. Však to píšu od začátku. Pro nás je nejlepší nemít zabezpečené nic. Máme pak jednoduší práci.

Ehm proč bych měla používat jiné jména než je moje skutečné? Vy to tak někdo děláte?  A proč?

[Eržika]

Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Máte pravdu. Jsem jen blbá ženská a tak mám pomalejší vedení. Frontend sice běží na nějakém serveru, ale to není důležité, požadavky posílá klient ze své ip. Jsem prostě blbá, ženskž by neměli programovat oni mi to říkají furt kluci tady v kanclu.

[.]

Možná jsem negramotný, ale mohla byste mi ukázat v příspěvku slovní spojení server a frontend, ze kterého jste vyvodila, že frontend běží na serveru? Javascriptová frontend aplikace běží zpravidla na klientském počítači v prohlížeči.

Máte pravdu. Jsem jen blbá ženská a tak mám pomalejší vedení. Frontend sice běží na nějakém serveru, ale to není důležité, požadavky posílá klient ze své ip. Jsem prostě blbá, ženskž by neměli programovat oni mi to říkají furt kluci tady v kanclu.

Jestli jste blbá ženská, to opravdu nevím, protože se neznáme, stejně jako vy nevíte, jestli jsem blbej mužskej. Ale vztahovačná jste poměrně dost.

Naznačil jsem, že by mne zajímalo, jak jste to myslela s tím serverem. Protože pod pojmem javascriptová aplikace posílající REST dotazy si já představím React nebo Angular JS aplikaci, která se sice na začátku stáhne z webového serveru, ale veškerá komunikace probíhá z klienta. Klasická webová stránka téměř nikdy neposílá REST požadavky.

[Eržika]

Protože pod pojmem javascriptová aplikace posílající REST dotazy si já představím React nebo Angular JS aplikaci, která se sice na začátku stáhne z webového serveru, ale veškerá komunikace probíhá z klienta.

Ano samozřejmě máte pravdu také jsem se v minulém příspěvku opravila.

Klasická webová stránka téměř nikdy neposílá REST požadavky.

Tady si dovolím nesouhlasit. REST komunikace probíhá ve standartních aplikacích také a to jak na straně frontendu (dotáhneme si pomocí js nějaká data z ext. rest rozhraní) a nemusí být nutně jen v uber top technologiích jako react/angular. Ale tam samozřejmě ten požadavek probíhá také ze strany klienta jak jsme si již vyjasnili.
Nicméně máme ještě kategorii rest požadavků ze strany serveru. Tj vyplním nějaký formulář, odešlu jej postem (či ajaxem či jakkoliv) na backend té app a ten se sám spojí s jiným rest api (či soapem, atp), odešle mu data, něco si uloží třeba i k sobě do db a vrátí nějaký výsledek na frontend zpátky. Tam ta komunikace ale probíhá server-server tedy i z ip serveru a naprosto nezáleží, že ten frontend je napsaný v reactu, jelikož má vlastní backend. Což je dosti častý případ. Mylně jsem si původně myslela tento případ, proto ta zbytečná diskuze.

Předpokládám ale, že zadavatel otázky myslel váš případ, tedy frontend v angularu bez jakéhokoliv backendu, s tím že komunikuje přes rest.

[Eržik]

private api s omezením na firewallu na ip

Aby mě nikdo nenařkl že zabezpečení na ip je nebezpečné, či že ip se často mění (tak určitě), tak stačí namísto IP využít TXT DNS record a vůči němu se api ověří. Vzhledem k https+dnssec je to lepší než jakékoliv jiné zabezpečení.

 Eržiko, mate asi rada bdsm, protoze ve vetsim prostredi skoncite s whitelistem dlouhym jak frontou na davky. Na testovani v kancliku dobry, reseni pres proxy je rozhodne elegantnejsi pro uzivatele "klient ma pristup na jejich webitko na testovacim serveru pres usr/pwd". Https+dnssec mi pripada sympaticky na rest apicka, jinak trochu zalezi co je treba, ale nejakej stunel muze taky poslouzit dobre. Mam asi uchylku, ale obecne nejak tak rad strkam apky do tunelu kdyz to jde.