Adds infos about vulnerability disclosures

[flovilmart]

No description provided.

[codecov]

Codecov Report

Merging #4413 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #4413   +/-   ##
=======================================
  Coverage   92.66%   92.66%           
=======================================
  Files         118      118           
  Lines        8346     8346           
=======================================
  Hits         7734     7734           
  Misses        612      612

Impacted Files	Coverage Δ
src/RestWrite.js	93.28% <0%> (-0.19%)	⬇️
...dapters/Storage/Postgres/PostgresStorageAdapter.js	96.94% <0%> (+0.1%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1f22ee3...ead0b12. Read the comment docs.

[dplewis]

The French Approves 🙏

[flovilmart]

You French for real?

[dplewis]

Not at all. I’m going to learn French next year. It will be fun.

[flovilmart]

Ahah! Awesome!

[dplewis]

approved

[montymxb]

This is good. It's about time we had a serious statement about how we handle such issues. We may want to specify a minimum amount of time that should be expected before we can a) respond and b) be able to fix the issue, depending on severity.

[flovilmart]

Good idea, feel free to edit directly in github!

[montymxb]

Just changed the language regarding timetables from first contact to patch applied. If the wording looks good I actually want to change both of those values to days, 7 and 30 respectively.

[flovilmart]

Yep that's good to me!

[montymxb]

@flovilmart Looking back at this I'm wondering if we should also consider adding a small section to the README as well, just pointing to SECURITY.md?

[flovilmart]

Yes, I was realizing it earlier this morning, also probably on http://parseplatform.org and http://docs.parseplatform.org

[montymxb]

Wouldn't be a bad idea

[nbering]

The wording on the responsible disclosure policy looks like it's for a hosted service.

[flovilmart]

Which part? We can always improve!

[nbering]

Sorry. I realized after I posted that it was really vague. It refers to accessing individual user accounts. Sounds like Parse.com security policy more than a self-hosted open source server.

[flovilmart]

Yeah, in the sense that one would be able to poke the accounts / setups of parse-server users and exploit the said vulnerabilities.

[nbering]

Yes, but there is no need for that to be allowable. A security researcher should be able to self-host. They never had that option on Parse.com so an exception would have needed to be made to allow vulnerability discovery. The Parse Platform project cannot authorize people to do penetration testing of other people's servers... so unless you have a sample where people can poke around this doesn't seem like a valid policy.

[nbering]

Sorry... I sound unintentionally negative. Aside from that point this is great work and should serve as an example of responsibility to the community.

[flovilmart]

I would like to make it better, with your help, feel free to rephrase, edit in a subsequent PR.

Even if the ‘account’ is inaccurate, because we don’t host user accounts, it would still be possible for one to test against live deployments of parse-servers, based on discoveries of public data (logs shared etc...). This sentence would encompass that, I’d like a better phrasing too.