Security tools in email systems that automatically follow links in email can execute a Parse Server email verification link without any user interaction required. This could potentially be exploited by signing up with an email address that is part of an email system that uses such a security tool.
The issue is that the email verification link is a GET request. The underlying issue is that an automated 3rd party system performs an action on behalf of the user. At this point we only seem to know that there are some that perform GET requests (for whatever reason), but there may be others that also perform POST requests (for whatever reason).
Parse Server currently does not seem to follow the recommendations of RFC2616 which say:
In particular, the convention has been established that the GET (...) SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".
"SHOULD NOT" is to be interpreted as "not recommended" in RFC2119:
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
Looking at the use case of email verification, we could assume that it is "not acceptable" to use a GET request for a use case with such implications.
It was internally discussed that this is not a security vulnerability of Parse Server but rather an improvement. We consider it the email system owner's responsibility to consider potential implications of the tools they use.
Steps to reproduce
Set up Parse Server to require email verification
Sign up use with email address of an email system that auto-follows link in email
Actual Outcome
Parse Server considers the email verified.
Expected Outcome
Parse Server should not consider the email verified but require a manual step by a human.
Suggested Solution
Allow POST (and GET) requests for the email verification endpoint. So anyone can implement their own POST flow if they find this something they have to address immediately. That would also not break existing functionality and we can easily backport it to Parse Server 4.x. In Parse Server 5, such a flow can be easily constructed as a custom route with the new PagesRouter. After that, we can look to implement this as a default flow in Parse Server, if someone submits a PR.
Considerations:
It is not reasonably possible to perform a POST request from an email, so the initial request from the email will remain a GET request.
The GET request could open a webpage that requires the user to manually execute a POST request to verify the email.
Automatically executing a POST request on a website is likely not a good idea, as there may be 3rd party systems that follow the GET request and execute the JavaScript on the webpage.
🚀 You can help us to fix this issue faster by opening a pull request with a failing test. See our Contribution Guide for how to make a pull request, or read our New Contributor's Guide if this is your first time contributing.
New Issue Checklist
Issue Description
Security tools in email systems that automatically follow links in email can execute a Parse Server email verification link without any user interaction required. This could potentially be exploited by signing up with an email address that is part of an email system that uses such a security tool.
The issue is that the email verification link is a GET request. The underlying issue is that an automated 3rd party system performs an action on behalf of the user. At this point we only seem to know that there are some that perform GET requests (for whatever reason), but there may be others that also perform POST requests (for whatever reason).
Parse Server currently does not seem to follow the recommendations of RFC2616 which say:
"SHOULD NOT" is to be interpreted as "not recommended" in RFC2119:
Looking at the use case of email verification, we could assume that it is "not acceptable" to use a GET request for a use case with such implications.
It was internally discussed that this is not a security vulnerability of Parse Server but rather an improvement. We consider it the email system owner's responsibility to consider potential implications of the tools they use.
Steps to reproduce
Actual Outcome
Parse Server considers the email verified.
Expected Outcome
Parse Server should not consider the email verified but require a manual step by a human.
Suggested Solution
Allow POST (and GET) requests for the email verification endpoint. So anyone can implement their own POST flow if they find this something they have to address immediately. That would also not break existing functionality and we can easily backport it to Parse Server 4.x. In Parse Server 5, such a flow can be easily constructed as a custom route with the new PagesRouter. After that, we can look to implement this as a default flow in Parse Server, if someone submits a PR.
Considerations:
Environment
Server
5.0.0-alpha.1
Logs
n/a