Ochrana api proti spamu

Ahoj,

dělám nástroj na odesílání web push notifikací a jeho součástí je jednak REST api to jsem zabezpečil přístupovým tokenem, ale pak tam ještě mám api pro JS a to nevím jak zabezpečit.

Funguje to tak, že stránka, která chce použít tento nástroj si přidá script na web a tento script odesílá data na server. Jde o data typu byl zobrazen dotaz na odběr notifikace, samotný odběr notifikací, informaci o zobrazení notifikace a kliknutí na notifikaci, přiřazení/odebrání tagu k odběrateli...

Jak zabránit tomu, aby to kdokoliv mohl jen, tak zasmanovat blbostma? Je dobrý a dostatečný omezit počet requestu počet reqestu na ip?

Používám PHP a Nette.

Díky za rady.

Nevim, zda chapu tvuj problem. Resis situaci, ze se bojis toho, ze pristupovy token do API poslany treba v hlavicce pod parametrem Authorization se da snadno vycist ze zdrojoveho kodu javascriptu a takovy clovek ti pak snadno muze lezt do aplikace?

Nedavno jsem cetl na tohle diskuzi a jedina snadna rada byla o2auth...

Token je jen pro komunikaci mezi servery a v JS nebude.

Ale v komunikaci mezi JS a servrem chci zabránit tomu, aby nebylo možné např.: odeslat statisíce falešných odběrů push notifikací.

Tohle nelze nikdy 100% ochránit. Existuje řada postupů, které riziko minimalizují. Nette má v modulu pro formuláře implementovaný CSRF, ten sníží množství požadavků tím, že před každým si musí útočník vyžádat jednorázový token ze serveru.

Poté si musíš implementovat nějakou formu QoSu (quality of service) v podobě limitů např. na počet požadavků ze 5s, za 1m, za 24h atd. pro každou stránku (aplikační token) zvlášť, klidně ve vztahu k IP (tam ale pozor na ipv6, těch je obrovské množství a nelze takhle jednoduše limitovat). Stejně tak můžeš detekovat shodnost zpráv (pro začátek třeba pomocí levenshtein distance, na což jsou již funkce v php).

Ke všemu chce mít monitoring a upravovat za běhu. Pokud se třeba aplikace stane oblíbená ve firmě, která jede přes jednu bránu, všichni zaměstnanci mohou být pod jednou IP a tím zablokuješ spousty lidí (stejně špatně fungují systémy naší státní správy a je to pak peklo v tom pracovat).

Poté samozřejmě můžeš implementovat double opt-in a další formy ověření. Svoji službu si tady moc detailně nepopsal, lze si těžko dovozovat co vlastně děláš a jak to technicky budeš mít řešené a k čemu to je.

Zkus CloudFlare (nebo nějakou alternativu), vlastní řešení se dnes už nevyplatí.

Původně odeslal studNa ↪

Zkus CloudFlare (nebo nějakou alternativu), vlastní řešení se dnes už nevyplatí.

Cloudflare pro api z js? Myslím, že to není nejlepší řešení vzhledem k tomu jak se chová. Pořád to ale nezabrání zneužití, pouze chrání backend proti přetížení, což je trochu jiná disciplína...

Nejleší co mě napadá je přiřadit každému klientovy nějaký access token se kterým pak bude komunikovat s api a každý endpoin bude mít omzetený maximální počet reqestů pro access token na den. A pokud z jednoho ip bude vznikat moc access tokenů přijde mi upozornění a já budu moci tyto tokeny smazat a to co udělali se veme zpět.

Tady bych se držel toho, co psal TomsaX (pokud tedy chápu správně, že ten JS bude na veřejném webu). Když by to šlo vyřešit, měl by to ošetřené například Google Analytics - viz například zkreslení obchodních metrik při nesmyslných objednávkách - řeší se to až nad nasbíranými daty.

Původně odeslal TomášX ↪

Cloudflare pro api z js? Myslím, že to není nejlepší řešení vzhledem k tomu jak se chová. Pořád to ale nezabrání zneužití, pouze chrání backend proti přetížení, což je trochu jiná disciplína...

Otázka ale nebyla o tom, jak zabránit zneužití, ale jak předejít spamu (což Cloudflare spolehlivě řeší). Řešit cílené zneužívání v tomto případě ani nedává smysl, teoreticky ten skript může implementovat web s vysokým trafficem a pak nemáš šanci rozlišit, jestli ti ty požadavky generuje robot nebo ne. To se obvykle řeší až nad sesbíranými daty, jak píše skorozacatecnik.

Stejně tak přes CloudFlare snadno vyřešíš rate limits nebo IP blacklist. Ez pz.

Původně odeslal studNa ↪

Otázka ale nebyla o tom, jak zabránit zneužití, ale jak předejít spamu (což Cloudflare spolehlivě řeší). Řešit cílené zneužívání v tomto případě ani nedává smysl, teoreticky ten skript může implementovat web s vysokým trafficem a pak nemáš šanci rozlišit, jestli ti ty požadavky generuje robot nebo ne. To se obvykle řeší až nad sesbíranými daty, jak píše skorozacatecnik.

Stejně tak přes CloudFlare snadno vyřešíš rate limits nebo IP blacklist. Ez pz.

a jak CloudFlare zabrání zaspamování API blbostmi? :) Stejně ty limity budou ve stovkách. Zkoušel jsi vůbec někdy v praxi dát API za CloudFlare gateway? Užitečné věci právě proti spamu jako Web Application Firewall nebo Browser Integrity Check musíš mít vypnuté, protože požadavek na API probíhá na pozadí. Zůstane ti pár věcí v Page Rules, které se ale spíše hodí pro globální projekty s větším provozem a load balancing přes země a kontinenty. Nic moc užitečné pro rate limiting na IP či token či nějaké chytřejší kontrolování a filtrování, nejužitečnější věci jsi vypnul a pohodlně se to určitě nenastavuje. Může být trochu nápomocný JS Challenge, ale pokud je kód na cizím webu, jako v tomhle případě, užitečné to přestává být.

Jak jsem psal v prvním příspěvku, záleží jaká je cílovka a k čemu aplikace je určena. Běžně velké české firmy stojí za jednou ipv4 a pak přes ní jde spousta requestů, rate limiting, který je na CloudFlare tohle moc nezohledňuje a neumožňuje dostatečně jemné nastavení pro malé lokální projekty, takže běžně nastavuješ něco jako 200 requestů per IP per hour. Osobně to považuji za příliš složité, zejména, když tazatel má očividně možnost aplikaci upravit a tuhle funkci si tam přidat. Pokud mám již vše přes CloudFlare, dá se to i na tohle znásilnit, ale zrovna pohodlné a jednoduché to není.

CloudFlare umí částečně odstínit "robotické" požadavky (z konkrétní IP, z běžných IP rotátorů nebo Tor sítě). To, co píšeš ty, deleguje všechny požadavky na aplikaci a protože tu filtrovací logiku budeš mít až na úrovni aplikace (nikoliv třeba LB nebo proxy), budeš muset o to víc škálovat železo, abys byl schopný zpracovat každičký požadavek.

Kdyby to bylo tak jednoduché, jak tvrdíš, tak služby jako CloudFlare nemají co žrát. Ale oni mají. Protože je snazší (pohodlnější a levnější) používat takovou službu, než si to řešení psát sám.