REST API editace a mazani

17. 5. 2023 15:22:20

Ahoj,

opet bych se rad zeptal na neco praktickeho. Mozna resim blbosti, ale pokud pouzivam pristup do API skrze nejakou jinou aplikaci a napriklad edituji clanek, posilam pak zmenena data na /articles/3 .

Pri vytvoreni clanku si k nemu generuji jakysi bezpecnostni token (100 znaku) a pokud ho edituji, je nutne poslat do API znovu tento token a dojde k overeni pristupu k zaznamu. Token je nacten pri otevreni editacniho okna do formulare.

Zkratka to myslim tak, ze pri editaci neoveruji jen existenci clanku dle ID clanku 3, ale zaroven jeste overuji, zda to neni treba jen nejaky bot nebo utok, protoze ten by token neznal.

Nijak me tohle reseni neomezovalo, ale kdyz jsem premyslel o mazani /articles/3 , tak tam uz mam problem, protoze uz do tohoto requestu nemohu vlozit data.

Je overovani pres token zaznamu zbytecne a ma mi stacit to, ze API odmitne pozadavek, pokud to prijde z nejakeho neznameho systemu/uzivatele, apod., a interni pristup a overeni skrze token uz resit nemam?

Diky za odpovedi.

17. 5. 2023 15:22:20

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1516955

TomasX

(4 hodnocení)

17. 5. 2023 15:40:51

použij hlavičku nebo get parametr. Fakticky body u DELETE požadavku nebylo nikdy žádnou speckou zakázáno, některé frameworky to podporují, některé ignorují, poslední RFC https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.5 mluví pouze o doporučení, že by se body nemělo použít pokud si člověk není plně jistý.

Netuším o jakém tokenu mluvíš, ono toho může být více. Podle kontextu pravděpodobně mluvíš o CSRF tokenu, což je mechanismus, který chrání právě proti volání aplikace z nelegitimního zdroje, např. zákeřná stránka obsahuje formuláře, který směruje na tvoji aplikaci, CSRF takovému podvržení efektivně brání, popsané to máš třeba na wiki https://cs.wikipedia.org/wiki/Cross-site_request_forgery. CSRF token by měl být svázaný s tvoji session a pro jeho získání je potřeba vyrenderovat stránku s formulářem.

17. 5. 2023 15:40:51

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1516954

franta.hosek

18. 5. 2023 09:10:14

Nevyjadril jsem se uplne presne, tak jeste jednou. Nejde o CSRF token ani o zadnou ochranu na urovni komunikace zdroj pozadavku vs. API.

Jde o to, ze pokud ukladam zaznam do DB (treba clanek), tak ukladam nazev clanku, perex, obsah, datum vytvoreni, datum publikovani, atd. Krome toho, ze clanek pri ulozeni dostane unikatni ID, tak mu vygeneruji unikatni token. A to prave nevim, zda neni navic.

Tento token pouzivam jako dalsi overeni. Jo, mozna je to zbytecne. Tzn., kdyz pak clanek nekdo upravuje a bylo by to treba skrze API, tak nejenom ze overim pri prvotni komunikaci s API platnost toho zdroje volani, ale prave ze pri pozadavku ten clanek editovat nebo mazat pozaduji krome IDcka clanku jeste prave ten token. Jo, je to asi navic...

Proste kontrola typu "jo, znas ID, super, to se da uhodnout, ale az tim ze znas i token dokazujes, ze k tomu zaznamu mas plny pristup a nejsi fejk pozadavek, atd.".

Cim vic o tom mluvim, tim vic mi to tak pripada :)

18. 5. 2023 09:10:14

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1516953

TomasX

(4 hodnocení)

18. 5. 2023 09:47:41

krátce řečeno, je to volovina :).

Takovéhle použití tokenů má význam v tom, že pak každá verze článku má svůj "token" a pokud děláš úpravu, musíš znát verzi (token) revize, kterou upravuješ, můžeš takhle vynutit, aby se vždy upravovala jen poslední revize a nedošlo k přepsání práce někoho jiného. Jednoduše řečeno.

Znalost tokenu jako bezpečnost vypadá jako antipatern. Oprávnění k článku bys měl ověřovat přes ACL, tj. editor a vlastník může článek upravit, tomu pak předchází přihlášení, identitu si poté držíš v sezení a proti ní ověřuješ jestli článek může vidět, upravovat, smazat. Token jako statické heslo k článku je špatně.

18. 5. 2023 09:47:41

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1516952

Ondřej Marek

19. 5. 2023 21:28:09

Takové schéma jsem za 12 let programování neviděl. Asi víme proč. Je to úplně mimo. Tyhle věci mají řešit policy a middleware.

19. 5. 2023 21:28:09

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1516951

Ladislav Vondráček

(2 hodnocení)

16. 9. 2023 16:42:48

Jestli nechceš, aby ti mohli tipovat ID, tak máš dvě možnosti.

1) Nepoužívej jako ID číselnou řadu. Velmi populární je dnes UUID.

2) ID zašifrovat. Můžeš si udělat nebo asi i najít jednoduchý (de)šifrovací nástroj, který před odesláním response změní ID na změť znaků a po přijetí requestu zpětně převede na ID.

16. 9. 2023 16:42:48

https://webtrh.cz/diskuse/rest-api-editace-a-mazani/#reply1520477

Pro odpověď se přihlašte.

Přihlásit