From 090d408db4acbf964920b1a7b042e2e5f4a97a00 Mon Sep 17 00:00:00 2001 From: simonaberry Date: Tue, 14 Feb 2017 15:02:02 +0200 Subject: [PATCH 1/3] Add files via upload --- proposals/0002-bruteforceattack.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 proposals/0002-bruteforceattack.md diff --git a/proposals/0002-bruteforceattack.md b/proposals/0002-bruteforceattack.md new file mode 100644 index 0000000..867f4b6 --- /dev/null +++ b/proposals/0002-bruteforceattack.md @@ -0,0 +1,28 @@ +# Feature name + +* Proposal: 0001-after-find +* Authors: [Jonas DB](https://github.com/jonas-db) +* Review Manager: TBD +* Status: **Awaiting review** + +## Introduction +## Motivation + +Assume that we want to know the amount of views of a blog post, so everytime a blog post is fetched with a GET request, the amount of views should be updated. + +## Proposed solution + +Introducing an afterFind cloud code function. This is similar to the existing triggers and provides a uniform way to have triggers for GET/POST/DELETE requests. + +## Detailed design + +Extending the cloud code with an afterFind function + +## Alternatives considered + +If i'm correct, there are two ways to solve this problem: + +create a cloud function, which you call instead of querying a collection +after the fetch request, save the object again with the counter increased + +While the first one is acceptable, the second is not. Although, I think that cloud code is meant for custom code, not for normal query requests. To remain consistent with the other cloud code, I propose the suggestion of afterFind. From 71c75f007958f6781bf928078565bea27b4b3faf Mon Sep 17 00:00:00 2001 From: simonaberry Date: Tue, 14 Feb 2017 15:10:14 +0200 Subject: [PATCH 2/3] Update 0002-bruteforceattack.md --- proposals/0002-bruteforceattack.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/proposals/0002-bruteforceattack.md b/proposals/0002-bruteforceattack.md index 867f4b6..7a24d69 100644 --- a/proposals/0002-bruteforceattack.md +++ b/proposals/0002-bruteforceattack.md @@ -1,28 +1,28 @@ # Feature name -* Proposal: 0001-after-find -* Authors: [Jonas DB](https://github.com/jonas-db) +* Proposal: 0001-brute-force-attack-detection +* Authors: [Simon Berry](https://github.com/simonaberry) * Review Manager: TBD * Status: **Awaiting review** ## Introduction ## Motivation -Assume that we want to know the amount of views of a blog post, so everytime a blog post is fetched with a GET request, the amount of views should be updated. +Cyberthreats are a real problem. Any servers running Parse Server are susceptible to hack attacks. The simplist would be a brute force attack - as there are no in built limits to login attempts. This is particulaly relevant as the default ACL on any new user added is Public Read - so it is fairly straight forward to get the usernames for all the users on a vanilla Parse Server (unless the developer has been good about changing teh User class ACLs). ## Proposed solution -Introducing an afterFind cloud code function. This is similar to the existing triggers and provides a uniform way to have triggers for GET/POST/DELETE requests. +1. Introduce a paramater that allows the developer to specify the maximum number of incorrect attempts (configurable) on a specific username before 'freezing' the account for a given time frame (configurable) + +OR + +2. Introduce an 'AfterLoginAttempt' hook in cloud code that would allow the user to write his own logic to implement an account freeze if a certain number of incorrect logins were attempted ## Detailed design -Extending the cloud code with an afterFind function +Don't know the Parse Server code well enough to suggest detailed implementation ## Alternatives considered -If i'm correct, there are two ways to solve this problem: - -create a cloud function, which you call instead of querying a collection -after the fetch request, save the object again with the counter increased +could also possibly monitor the log files using a library like this https://github.com/rfxn/brute-force-detection -While the first one is acceptable, the second is not. Although, I think that cloud code is meant for custom code, not for normal query requests. To remain consistent with the other cloud code, I propose the suggestion of afterFind. From e840a6adf6d8161255def332f0667e6c521e936b Mon Sep 17 00:00:00 2001 From: simonaberry Date: Tue, 14 Feb 2017 15:11:41 +0200 Subject: [PATCH 3/3] Update 0002-bruteforceattack.md --- proposals/0002-bruteforceattack.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/0002-bruteforceattack.md b/proposals/0002-bruteforceattack.md index 7a24d69..75bf8e8 100644 --- a/proposals/0002-bruteforceattack.md +++ b/proposals/0002-bruteforceattack.md @@ -12,11 +12,11 @@ Cyberthreats are a real problem. Any servers running Parse Server are susceptibl ## Proposed solution -1. Introduce a paramater that allows the developer to specify the maximum number of incorrect attempts (configurable) on a specific username before 'freezing' the account for a given time frame (configurable) +* Introduce a paramater that allows the developer to specify the maximum number of incorrect attempts (configurable) on a specific username before 'freezing' the account for a given time frame (configurable) OR -2. Introduce an 'AfterLoginAttempt' hook in cloud code that would allow the user to write his own logic to implement an account freeze if a certain number of incorrect logins were attempted +* Introduce an 'AfterLogin' hook in cloud code that resolves a promise if login was successful or rejects a promise if login was unsuccessful. This would allow the user to write his own logic to implement an account freeze if a certain number of incorrect logins were attempted ## Detailed design