Christian Tramnitz
5ee619229e
make clear that accessing public information is not considered a vulnerability Reviewed-on: #1
75 lines
3 KiB
Plaintext
75 lines
3 KiB
Plaintext
verdigado & Netzbegruenung Security and Vulnerability Reporting Policy
|
|
|
|
1. Services Covered by this Policy
|
|
|
|
This policy covers all services directly operated by us (verdigado eG &
|
|
Netzbegruenung). Services can be identified by the following means:
|
|
- The website has a .well-known/security.txt that links to this policy.
|
|
- The reverse DNS of an IP address resolves to one of the following
|
|
domains: *.verdigado.net, *.verdigado.com, *.netzbegruenung.de
|
|
|
|
2. Acceptable Use
|
|
|
|
We generally invite security researchers to search for vulnerabilities
|
|
in our services. We kindly ask to not put any actual user data or
|
|
production systems at risk.
|
|
|
|
3. Classification of Vulnerabilities
|
|
|
|
A) We will consider a vulnerability report most likely as relevant if it
|
|
reports one of the following problems:
|
|
1. The vulnerability can be used to directly access non-public
|
|
information that either reveals further security relevant problems or
|
|
contains user data, credentials, or sensitive data in general.
|
|
2. The vulnerability can be used to disrupt the orderly operation of a
|
|
service (Denial of Service).
|
|
3. The vulnerability can be used to manipulate data within the service.
|
|
4. XSS, CSRF, RCE, authentication/authorization bypass, SQL inections,
|
|
etc are considered relevant.
|
|
|
|
B) We will consider a vulnerability report most likely as NOT relevant if
|
|
it reports one of the following problems:
|
|
1. Missing security features, for example HTTP headers, if they are not
|
|
actually preventing a vulnerability.
|
|
2. Publicly accessible information such as version strings of used
|
|
software and previously publicly known information in general.
|
|
3. Security vulnerablities that can only be used within the scope of the
|
|
used account.
|
|
|
|
4. Reporting Vulnerabilities
|
|
|
|
Report vulnerabilities via e-mail to security@verdigado.com.
|
|
|
|
Please make sure that you include the following information:
|
|
- Which service is affected
|
|
- How can the bug be used/exploited
|
|
- Explanation of the risk
|
|
|
|
Reports will be answered within 48 hours. If you have not received an
|
|
answer within that time frame, feel free to contact us again.
|
|
|
|
For used open source software, we recommend to file bug reports and/or
|
|
pull requests against the upstream repositories. This includes hardening
|
|
instructions in the installation documentation.
|
|
|
|
5. Bug Bounties / Rewards
|
|
|
|
The amount of reward payed depends on the severity of the found
|
|
vulnerability. We usually do not pay rewards if vulnerabilities can be
|
|
found in mass scans with of-the-shelf software.
|
|
|
|
Only responsible disclosures are eligible for rewards.
|
|
|
|
6. Acknowledgement
|
|
|
|
We list recognized reports of vulnerablities online if the reporting
|
|
security researcher agrees. The name, contact e-mail address, and type
|
|
of vulnerability can be included in the list. Our public
|
|
acknowledgements can be found at
|
|
https://security.verdigado.com/acknowledgements.html.
|
|
|
|
7. About this Policy
|
|
|
|
This policy is MIT licensed. Feel free to suggest modifications and
|
|
additions at https://github.com/digitalfabrik/security-policy.
|