Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simple anti-abuse system - throttle addiding annotations per-IP #29

Open
glowka opened this issue Jun 20, 2018 · 3 comments
Open

Simple anti-abuse system - throttle addiding annotations per-IP #29

glowka opened this issue Jun 20, 2018 · 3 comments
Labels

Comments

@glowka
Copy link
Collaborator

glowka commented Jun 20, 2018

We do not have any antibot system, so limit adding annotations to 20 per hour and 50 per 24h, per one IP.

@glowka
Copy link
Collaborator Author

glowka commented Oct 2, 2018

@kaglowka Actually we are even much weaker than we thought.

We should also throttle number of sessions per IP, because now we use LazySignup application which means that every first request (also GET) for given client triggers creating a user, so we can be easily DoSed by almost anyone. It does not need to be creating new annotation. Making request to any GET endpoint, ignoring session token we send in response, then another request and so on and we are down because of one kid having fun using pure cURL.

@glowka
Copy link
Collaborator Author

glowka commented Oct 2, 2018

Possible solution

Optimally for every new installation of extension we should open a page with Captcha and that way validate the session. If somebody cleans his cookies, as soon as client discovers proper 4XX response stating that session validation is required, we should open tab with Captcha again. Once validation is finished, the tab that discovered the 4XX reloads and everything goes smooth again.

Captcha validation of every new session will guarantee number of session will not raise above reasonable amount that is equal to number of real users of our extension and that is perfect state :)

@glowka glowka added the security label Oct 2, 2018
@kaglowka
Copy link
Contributor

kaglowka commented Oct 3, 2018

Yes, that is an issue. Lazy signup was initially meant as a shortcut to more quickly test the application prototype. Thanks for the idea -- the solution you are mentioning actually looks sustainable in the long term and has a big advantage -- we can manage action permissions for an unlogged user depending purely on what actions we want them to be able to access and not restricting it for security reasons.

How about doing it for v3.1? (since 3.0 will be accessible only to non-hostile users and can already be tested in the meantime).

@glowka glowka removed the should-have label Oct 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants