Založení a design webu a eshopu taneční školy
Zobrazují se odpovědi 1 až 18 z 18

Jak zabezpecit volani REST API

  1. 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['Origin'] 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.

  2. Co se právě děje na Webtrhu?
  3. 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_n...get_record.asp
    Klientovou IP i domenu znas ( $_SERVER ), tak to jen porovnas s DNS_A zaznamem jestli vzajemne sedi :)

  4. 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.

  5. 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ě.

  6. Citace Původně odeslal winexec Zobrazit příspěvek
    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_n...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...

  7. Citace Původně odeslal TomášX Zobrazit příspěvek
    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 ...

    Citace Původně odeslal musil.david Zobrazit příspěvek
    ... Administrace zmineneho API nam umozni pro kazdy takovy widgetovy formular na cizim webu definovat domenu, ze ktere bude API volano ...

  8. Citace Původně odeslal winexec Zobrazit příspěvek
    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_n...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.

  9. Citace Původně odeslal kdosiodjinud Zobrazit příspěvek
    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.

  10. Citace Původně odeslal TomášX Zobrazit příspěvek
    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.

  11. 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.

  12. Nepomuze? https://jwt.io/

  13. 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.

  14. 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.

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

  16. Citace Původně odeslal TomášX Zobrazit příspěvek
    ano a pokud nepotřebuješ komunikovat s webem, iframe je super, jen musíš znát přesné rozměry dopředu
    Ale porad je to o tom, ze nekdo si ten iframe muze dat z ciziho webu na ten svuj a bude to padat do systemu s identifikatorem toho, komu to ukradl... Protoze iframe budu nacitat z urcite URL, kde budou v GET parametru urcite identifikatory.

  17. @musil.david: Těch 20 webů služby tvého API používá na základě nějaké osobní dohody s jejich majiteli/provozovateli - předpokládám to správně? Víš, jaké jejich servery používají technologie/na čem běží (ASP, PHP, Java, …)? Je možnost, že by souhlasili s tím, že by si formulář odeslali "k sobě", na vlastní server, - a ty bys jim na to dodal jednoduchý skriptík -, kterým by si data zašifrovali a poslali je na tvůj server?

  18. Citace Původně odeslal crs Zobrazit příspěvek
    @musil.david: Těch 20 webů služby tvého API používá na základě nějaké osobní dohody s jejich majiteli/provozovateli - předpokládám to správně? Víš, jaké jejich servery používají technologie/na čem běží (ASP, PHP, Java, …)? Je možnost, že by souhlasili s tím, že by si formulář odeslali "k sobě", na vlastní server, - a ty bys jim na to dodal jednoduchý skriptík -, kterým by si data zašifrovali a poslali je na tvůj server?
    Osobni dohoda samozrejme ano. Myslenka byla takova, ze fungovat to bude prave nezavisle na technologii, protoze teoreticky to u 20 z nich mohu zjistit. Ale kdyz jich bude do budoucna treba 200, jakoze o tom uvazujeme, tak uz to tak nepujde delat. Tva otazka k odeslani na jejich server si myslim, ze je spojena druhou otazkou. A tam bych chtel byt opravdu nezavisly.

    Zkratka Google Analytics jsou super pripad. Jendoduchy kod si da do webu "kazdy" a uz to meri. Na druhou stranu, tady je problem to odeslani formulare. Tady nekdo rekl, ze to u nekoho na webu muze bloknout CORS.

  19. Citace Původně odeslal musil.david Zobrazit příspěvek
    Dekuji vsem za odpovedi, ale tak rikam si... proc neudelat ten iframe ze jo...
    Iframe ti to myslím ještě víc zkomplikuje. Je to v podstate samostatny dokument a požadavky z něj na API pak myslím nabudou obsahovat Origin toho volajícího webu, jen parametry z URL toho ifrme. Díky bezpečnostním restrikcím se z toho iframe dokumentu nedostaneš výš (do top window/frame). Taktéž cookies budes mít oddělené. Dá se to tusim řešit na straně serveru, aby ty iframe nešly loadovat do neznámých dokumentů, ale přiznám se, už si to přesně nepamatuju.

    Co se týká bezpečnosti, jak psal tomáš, tak ano, iframe bezpečnější, ale internet byl navrzen právě tak, aby se daly zdroje linkovat do jednoho dokumentu a jede na tom celý svět. Tím nechci snížit ten bezpečnostní pohled, je to spíš jen otákza priorit. Třeba do účetnictví nebo CPanelu by si asi GA nikdo nenasadil, naopak na blog, proč ne.


    Citace Původně odeslal musil.david Zobrazit příspěvek
    Tady nekdo rekl, ze to u nekoho na webu muze bloknout CORS.
    S CORS nebude problém, když si na straně serveru ošetříš HTTP OPTIONS požadavky. Pak můžeš na své straně definovat, koho povolíš a komu CORS blokne komunikaci.

Spolupracujeme: Jooble.org, Aximum - profesionální překlady Hostujeme u Server powered by TELE3