Jak zabezpecit volani REST API

Ahoj,rad bych si nechal od zdejsich vyvojaru poradit s moznym resenim zabezpeceni REST API. Provozuji mensi API, ktere zatim vyuziva pouzw jeden web. Skrze formular (jakysi widget) jsou data z posilana do API. Neni s tim problem, mam nejakou uroven zabezpeceni, apod. Mozna neni uplne top, ale zatim to staci. Nyni je ale moznost rozsireni funkcionality tak, ze do API bude moci pristupovat treba 20 webu. Kazdy takovy web bude zobrazovat nas widget. Aby pro majitele techto webu byla implementace co nejjednodusi, dostanout ode me vlastne jen tri radky kodu. Jeden bude pro nacteni JS souboru a druhy pro nacteni CSS souboru (stejne jako kdyz do webu nacitate nejaky plugin) a treti bude DIV objekt s nekolika parametry "data-". Tyhle tri prvky se postaraji o vykresleni formulare, ktery se bude prave do API posilat pomoci AJAXu. Veskery kod, ktery odeslani formulare obsluhuje je externe nacteny z nasi strany. To mam vyzkouseno, funguje. A ted nyni k tomu zabezpeceni.Administrace zmineneho API nam umozni pro kazdy takovy widgetovy formular na cizim webu definovat domenu, ze ktere bude API volano, dale je tam IDcko toho widgetu a token. Pri odeslani formulare do API overuji pres HTTP Basic Auth klasicky ID toho widgetu spolecne s tokenem a pak je tam jeste porovnani, zda je dotaz z povolene domeny. Zda se mi to ale malo a tohle pouziti API dalsim subjektem asi nezabrani.Asi by API melo nejdrive vygenerovat dalsi secret key, ktery potom vlozi do formulare jako hidden pole. Ani to mi ale neresi myslenku velke bezpecnosti. Nezabrani to tomu, ze si nekdo ten nas widget muze z nejakeho webu zkopirovat, dat si ho k sobe na web s jejich pristupovymi udaji (id widgetu a token samozrejme uvidi v HTML kodu) a zacit nam do API posilat data, ktera vlastne budou sparovana s tim uctem, z ktereho webu on to zkopiroval. A myslim, ze i domena se da nejak podstrcit, takze ani na $header se asi neda spolehnout. Snadno by tak mohly do API napada fejkove pripady..Jak se tohle resi jinde? Porad premyslim nad moznosti, jak to udelat spravne.Dekuji Vam za tipy.

Nevim co tam mas tak duleziteho, ze se bojis zneuziti dat. Pokud se ti to zda malo, tak to holt zpoplatni - placene veci se jen tak nerozdavaji ...Ohledne podstrceni domeny, vyzkousej https://www.w3schools.com/php/func_network_dns_get_record.aspKlientovou IP i domenu znas ( $_SERVER ), tak to jen porovnas s DNS_A zaznamem jestli vzajemne sedi :)

Dle mého se asi při vyšším zabezpečení nevyhneš něčeho u klienta na backendu, vzít data z formuláře, přidat salt unikátní pro každého klienta, vytvořit hash a ten poslat společně s daty. U sebe pak můžeš stejným způsobem se znalostí saltu vypočítat hash a zkontrolovat, že jej "podepsal" správný web.

vypadá, že o tom přemýšlíš dobrým směrem, takže základní pravidla ti nepomohou. Problematika, na kterou narážíš je komplexní a na to jsi sdělil málo informací.Vidím tam dvě slabá místa. Token, který sděluješ klientovi chceš buď vůbec nebo co nejméně vystavovat na webu, pro transakční komunikaci musíš používat dočasný identifikátor, aby to co jde vidět nejčastěji při komunikaci bylo minimálně zneužitelné.Ověření, že druhá strana je opravdu tím, za koho se tváří je další velký problém, od toho tady je třeba oauth (či oauth2) protokol, používají třeba sociální sítě, Google a další. V prostředí vysoce zabezpečených integrací zase používáme kerberos, ale to jsou technologie těžké na integraci.Ty máš ale vše na klientovi, takže nemůžeš využít servovou část k tomu, abyste si vyměnili dočasný token pro danou komunikaci. Zbývají ti teda jen soft pravidla, kdy můžeš kontrolovat origin, browser, ip adresu, čas atd., podle toho sestavovat míru důvěryhodnosti a pak případně ty nejméně důvěryhodné vyřazovat. Všechno co jde vidět v prohlížeči lze i vidět pro útočníka, tyhle soft pravidla třeba aplikuje GA.Mimochodem, nechávat na stránky stahovat cizí JS kód považuji osobně za velké bezpečnostní riziko, bohužel se porušované všude možně.

Napsal winexec;1582968

Nevim co tam mas tak duleziteho, ze se bojis zneuziti dat.

Pokud se ti to zda malo, tak to holt zpoplatni - placene veci se jen tak nerozdavaji ...

Ohledne podstrceni domeny, vyzkousej https://www.w3schools.com/php/func_network_dns_get_record.asp

Klientovou IP i domenu znas ( $_SERVER ), tak to jen porovnas s DNS_A zaznamem jestli vzajemne sedi :)

Data se ale posílají očividně z prohlížeče, takže IP návštěvníka na DNS webu sedět nebude...

Napsal TomášX;1582977

Data se ale posílají očividně z prohlížeče, takže IP návštěvníka na DNS webu sedět nebude...

Ano, pokud je to z prohlizece, tak je to k nicemu. Bral jsem, ze klient = nejaky web (tzn server s IP) tahajii z jeho API nejake data, ktere nasledne zpracuji / zobrazi ...

Napsal musil.david;1582962

... Administrace zmineneho API nam umozni pro kazdy takovy widgetovy formular na cizim webu definovat domenu, ze ktere bude API volano ...

Napsal winexec;1582968

Nevim co tam mas tak duleziteho, ze se bojis zneuziti dat.

Pokud se ti to zda malo, tak to holt zpoplatni - placene veci se jen tak nerozdavaji ...

Ohledne podstrceni domeny, vyzkousej https://www.w3schools.com/php/func_network_dns_get_record.asp

Klientovou IP i domenu znas ( $_SERVER ), tak to jen porovnas s DNS_A zaznamem jestli vzajemne sedi :)

Uplne jsi nepochopil muj problem. Ten widget form je jakasi zadost, ktera nam spadne do systemu. A je samozrejme blbost, aby si to zkopcil na web nekdo dalsi, kteremu to nechceme poskytnout a padaly nam tam zadosti z jeho webu. Nejde o zadny utajeny formular a zneuziti dat. S IP adresou je taky problem. Mensi hostingy ji casto meni. Treba u Forpsi byl hrozny problem napojit platebni branu Comgate, ktera ma overeni IP adresy a ten rozsah je u Forpsi az 300 IP adres.

Napsal kdosiodjinud;1582969

Dle mého se asi při vyšším zabezpečení nevyhneš něčeho u klienta na backendu, vzít data z formuláře, přidat salt unikátní pro každého klienta, vytvořit hash a ten poslat společně s daty. U sebe pak můžeš stejným způsobem se znalostí saltu vypočítat hash a zkontrolovat, že jej "podepsal" správný web.

To je prave otazka. Zatim je to na tom mem jednom webu a tam si fakt ciste v backendu vygeneruju v API klic pro tu jednu relaci, ale nikde ty prvotni udaje pro API spojeni nejsou videt, protoze je to ciste PHP curl a nikde se to nevypisuje. S tim obyc html formularem je to problem, protoze je v nem vsechno videt.

Napsal TomášX;1582976

Mimochodem, nechávat na stránky stahovat cizí JS kód považuji osobně za velké bezpečnostní riziko, bohužel se porušované všude možně.

Ty jsi pochopil muj problem uplne presne. Je to vlastne presne jako GA. Ja potrebuju, aby majitel webu snadno vlozil do sveho webu kod, ktery pak vzdalene natahne formular a zajisti odeslani.Bohuzel me nenapadlo, jak to jinak udelat. Samozrejme, pokud by to nejak slo, klidne to u sebe zmenim. Dulezite je dosahnout vysledku.Kdyz si vygeneruju ve facebook developers nejaky widget, taky si pak vkladam to HTML kod, ktery zajisti vzdelene nacteni likeboxu, apod. A ja potrebuju zkratka neco podobneho. Pokud to jde jinak nez pres vlozeny JS kod, budu rad za informaci. Rikas, ze je to nebezpeci. Ale podobne treba vlozim do webu, abyh zobrazil jQuery Datepicker a taky je to vlastne externi kod preci. I to je nebezpeci? I kdyz je to vlastne duveryhodny zdroj, od ktereho data beres.

Nevím, zda to chápu dobře, ale na to API chodí požadavky přímo z JS v prohlížeči?Pokud ano, požadavky nebudou mít nikdy IP toho webu (hostingu).Budou mít různé IP uživatelů (jejich poskytovatele připojení).Jde-li jen o to, aby ten JS widget nepoužíval nikdo jiný na svém webu, pak kontroluj Origin.Na API víš, jaké originy akceptuješ, ostatním nedáš data.Bežné prohlížeče odesílají regulérní Origin (nepodvrhují) a mají i bezpečnostní restrikce (viz CORS).Díky tomu, i když by si někdo zkopíroval JS na svůj web, jeho návštěvníkům nebude fungovat.API nedá data, protože dostane reálný Origin z prohlížeče, který neakceptuješ.Neošetří ti to, aby ti někdo ukradl data, nebo poslal podvržený požadavek na API.Zabrání to ale tomu, aby ten tvůj widget poskytoval včetně komunikace s API na svém webu, který nemá tebou akceptovaný Origin.Pokud chceš ošetřit API, aby nikdo nepovolaný nedostal data (aby ti je nikdo nekradl posíláním falešných požadavků na API atp.), pak bys musel požít techniky, které popisoval TomášX výše.

Nepomuze? https://jwt.io/

Aol Blerk ERROR 1 is the message that you may perceive if there is an error in the authentication method for AOL Mail. This error occurs due to settings in your browser, mainly if you're using an older or outdated browser, but you no need to worry because the following troubleshooting steps can solve this aol Blerk error 1.https://www.contactyahoohelpdesk.com/aol-blerk-error-1/---------- Příspěvek doplněn 08.05.2020 v 11:03 ----------Most of the users are facing problem while accessing roadrunner email. It’s a basic problem for the users who are using emails and it can be fix easily. So the users no need to worry roadrunner email provides the easy way to resolve your roadrunner email problems. Click on the link given and follow the guidelines. https://www.contactyahoohelpdesk.com/roadrunner-email-problems/

nebezpečí je stahovat cokoliv z cizího webu, nikdy nevíš, kdy je někdo napadne a podstrčí tam obsah, nemáš kontrolu nad jejich zabezpečením a děje se to opakovaně, reklamní systémy to stejné, jejich kontrola je nedostatečná. Nejde vůbec o to, jaké data máš ty na stránkách, ale že tvůj web je pak využit k napadení návštěvníka nebo k útokům na jiné.Při integraci třetí strany pro formuláře se z toho důvodu používá iframe, tak aby jsi neměl přístup na web, který tě vložil.Skorozacatecnik zmínil ještě důležitou věc, pokud web, na který se integruješ má striktně nastavený CORS, tvoje požadavky neprojdou, ověř si to dopředu, má to sice málo webů, ale občas se to objeví.JWT či jiný způsob jak před každým odesláním formuláře si nejdříve vyžádat jednorázový token je dobrý způsob a mělo by to v tomhle připadě být samozřejmost, ale základní problém to neřeší.Měj logy, počítej s tím, že budeš občas něco ručně odstraňovat a kontroluj to, lepší způsob zabezpečení bez spolupráce servové části nebo počítače návštěvníka není, jen to hlídej a minimalizuj riziko.

Dekuji vsem za odpovedi, ale tak rikam si... proc neudelat ten iframe ze jo...Vzdy to pak resi vsechno. Zadne jquery odesilani, problem s CORS, vse bude u nas... Jen se musim zamyslet nad tim, zda se stejne nevystavim tomu, ze si to proste nekdo zkopiruje k sobe na web.

ano a pokud nepotřebuješ komunikovat s webem, iframe je super, jen musíš znát přesné rozměry dopředu