Ochrana api proti spamu

28. 7. 2019 22:06:29

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.

28. 7. 2019 22:06:29

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410159

David Musil

(70 hodnocení)

29. 7. 2019 00:16:32

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

29. 7. 2019 00:16:32

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410158

NEzer

29. 7. 2019 11:19:21

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

29. 7. 2019 11:19:21

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410157

TomasX

(4 hodnocení)

29. 7. 2019 16:18:16

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.

29. 7. 2019 16:18:16

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410156

Vojtěch

(2 hodnocení)

29. 7. 2019 21:03:07

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

29. 7. 2019 21:03:07

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410155

TomasX

(4 hodnocení)

29. 7. 2019 21:37:19

Napsal studNa;1537713
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...

29. 7. 2019 21:37:19

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410154

NEzer

29. 7. 2019 22:08:18

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.

29. 7. 2019 22:08:18

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410153

skorozacatecnik

30. 7. 2019 01:35:20

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.

30. 7. 2019 01:35:20

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410152

Vojtěch

(2 hodnocení)

30. 7. 2019 11:02:17

Napsal TomášX;1537721
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.

30. 7. 2019 11:02:17

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410151

TomasX

(4 hodnocení)

30. 7. 2019 12:05:55

Napsal studNa;1537749
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í.

30. 7. 2019 12:05:55

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410150

Vojtěch

(2 hodnocení)

30. 7. 2019 13:54:30

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.

30. 7. 2019 13:54:30

https://webtrh.cz/diskuse/ochrana-api-proti-spamu/#reply1410149

Pro odpověď se přihlašte.

Přihlásit