Zabezpečenie REST API rubrika: Folklór

2 PeterBocan
položil/-a 2.1.2015

Ahoj, mám na Vás otázku: ako zabezpečiť kriticky dôležité REST API? Klientská aplikácia (NodeJS) volá REST API a predáva mu kritické informácie. Bude na to SSL stačiť, alebo mám použiť napr. OAuth?

Ďakujem za odpoveď.

Komentáře

  • Petr Voneš : http://devel.cz/otazka/jak-zabranit-volani-rest-api-zvenci — 2.1.2015
  • PeterBocan : Moje REST API ale nie je verejné. Napadá mi použiť Whitelist ... — 2.1.2015
  • Kilmar : Ak tam dáš SSL môžeš naraziť na obmedzenie v počte obslúžených spojení za sekundu. Ak potrebuješ aby tá API "lietala" nedávaj tam SSL. Ak je to neverejné api nieje o čom, SSL vôbec potrebné nieje a všetky requesty, ktoré ti na API pridu mimo whitelistu zahoď. — 9.1.2015
  • podhy : kilian.atlantis: pokud tam nedá SSL tak nemůže ani věřit tomu co za data na to API přijdou (bez SSL se tedy v tomto případě nedá obejít). Navíc náročnost otevírání SSL spojení se dá snadno obejít tak, že nebudu otvírat další nová spojení a použiji stávající a pak je degradace výkonu minimální — 9.1.2015
  • Kilmar : podhy: možno tomu trochu nechápem, keď vieš že request môže prísť len z jednej možnej IP a všetko ostatné zahadzuješ ako tým klesá dôverihodnosť (v pripade uzavreteho systemu)? Keďže pôvodne zvažuje whitelist, asi nepôjde o web stránku a asynch. request, keďźe tam je IP clienta zakaždým iná (nikdy som s node.js nepracoval) takže som si to predstavil ako sitúaciu keď z mojej client aplikácii napríklad v pythone volám nejaku REST api. Nepoužitie SSL a WHITELISTU kde su IP strojov z kade request môže prísť + použitie nejakého security tokenu pre identifikáciu uživateľa mi príde ok, ale možno mi niečo ušlo. Tým udržovaním spojenia myslíš keep alive ? Ako ti to pomoze napriklad pri 10 paralelnych spojeni ? Myslím, že v jeho príapade máš pravdu keď bude komunikovať len s obmedzeným počtom strojov tak je to viac menej jedno. — 9.1.2015
  • podhy : kilian.atlantis: pokud ten systém bude fungovat v nějaké oddělené VLAN tak samozřejmě není problém nemít SSL (ale tolik výkonu to stejně nesežere, takže je to v podstatě jedno teda pokud neplánujete provoz jako má FB), ale jakmile to půjde po netu tak bez SSL nezabráníte man in the middle útokům. Ad SSL: No minimálně je dobré nasadit nějaký druh SSL offloadingu + na co nejmenší režii vám stačí aby klient potom co odeslal data neuzavíral spojení, ale použil stávající, která má už otevřené (nedochází tedy k drahému asynchronímu šifrování) — 9.1.2015
  • PeterBocan : nesmie sa stať aby master odmietol spojenie. To je kritické. Ide o mastera, ktorý bude uchovávať dáta na neskoršiu štatistiku a následne ich aj real-time bude zobrazovať na webe (techológia ASP.NET). Hardvérovo je to momentálne riešené na úrovni VPS (Windows Server) hostingujem to v jednej firme. Výkonovo a parametricky by som to možno porovnal so serverami online hier. — 10.1.2015
  • podhy : Osobně bych vám pro toto spíš doporučil nějakou message queue. Ze slavů to tam můžete sázet ve velkým a master (nebo několik masterů) si to potom může vyzobávat jak bude/budou stačit stačit — 11.1.2015
odkaz
4 bazo
odpověděl/-a 2.1.2015

public a private key, hash_hmac podpisane requesty privatnym klucom, overovanie platnosti timestampu + nonce
ssl

tento system pouziva napr amazon a myslim, ze uz nic lepsie nikto nevymyslel

Komentáře

  • v6ak : Technicky ta odpověď vypadá OK. Asi je to správná odpověď, ale ne dobrá odpověď. Implementovat si vlastní kryptografii musí mít důvod. — 2.1.2015
  • PeterBocan : No to by šlo, len by som s vlastným návrhom zadrbal celkom slušné množstvo času, ktorý by sa dal využiť inde. — 2.1.2015
  • bazo : asi som to napisal moc skratkovito. o ziadnu vlastnu kryptografiu nejde. aplikacii/klientovi co ma pristupovat na api pridelis nejaky verejny identifikator/token moze byt aj email napr a privatn kluc/heslo. do request dat pridas aktualny timestamp, z request dat vytvoris string, tento podpises hash_hmac funkciou s tym privatnym klucom, do url sa prida ten timestamp a podpis. na serveri prijmes data, spravis string takym istym sposobom ako na klientovi, overis podpis takisto ako si ho vytvaral. porovnas timestamp ci je v povolenej tolerancii od serveroveho casu. standarny sposob pouzivany mnohymi api, nevymyslel som to ja, ale odkukal od toho amazonu. robota na max 1h, kym tu cakas na nejaku odpoved tak si to uz mohol mat nakodene — 3.1.2015
  • bazo : tuna je to obsirnejsie popisane http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-au... alebo tu http://restcookbook.com/Basics/loggingin/ — 3.1.2015
  • v6ak : TLS by mělo být odolné replay attacku, řešit nonces a timestamp by nemělo byt nutné. (Jakkoli je to další linie, která může případného útočníka zastavit.) Teoreticky i HMAC je zbytečný, mohl by stačit náhodný token. — 3.1.2015
  • v6ak : A varianta bez TLS (= nástupce SSL) už je implementace vlastního kryptoprotokolu, před čímž varuju. Možné to je, ale zdaleka to není taková sranda. — 3.1.2015
  • chmel : dá se to vyzkoušet např na sha1-online.com . V Ruby: Digest::SHA1.hexdigest( text ) - nemělo by to jít zpětně dekriptit, ale z konkrétního textu to udělá vždy stejný výstup. Takže když předáte druhé straně info co bude obsahem parametru, mělo by to být zabezpečené... — 9.1.2015

Pro zobrazení všech 3 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Folklór

Otázky uživatele PeterBocan