Responsible Disclosure Policy

At OpenEduCat, Inc., we take the security of our application seriously and appreciate your assistance in helping us keep it secure. This policy outlines the process for reporting security vulnerabilities in our web application and the steps we will take to address them.

Scope

This policy applies to any security vulnerabilities discovered in our web application, including the web application itself, any related systems, and any associated services.

Responsible Disclosure Process

If you have discovered a security vulnerability in our web application, please follow these steps:

  • Contact us : Please email security@openeducat.org with a detailed description of the vulnerability and how it can be exploited.

  • Provide evidence : If possible, please provide clear and concise evidence of the vulnerability, including any relevant screenshots or code samples.

  • Do not exploit the vulnerability : Do not attempt to exploit the vulnerability for any reason. This includes attempting to access data that you are not authorized to access, modifying data, or disrupting service.

  • Wait for a response : We will respond to your email as soon as possible, typically within 48 hours. We will keep you informed of the status of the investigation and any actions taken.

  • Coordinate disclosure : If the vulnerability is confirmed, we will coordinate disclosure with you, including setting a mutually agreed upon timeline for public disclosure.

Non-Disclosure

We ask that you not publicly disclose the vulnerability until it has been fixed and the relevant parties have been notified. This helps us protect our users and limit the potential for damage.

Legal

This policy is intended to provide guidelines for reporting security vulnerabilities and does not create any contractual or legal obligations. Any activities conducted in accordance with this policy will be done so in compliance with all applicable laws. We appreciate your assistance in helping us keep our web application secure.

Contact

If you have any questions or concerns about this policy or the responsible disclosure process, please contact us at security@openeducat.org.

What to report?

Qualifying vulnerabilities - DO REPORT!

  • SQL injection vectors in public API methods

  • XSS vulnerabilities working in supported browsers

  • Broken authentication or session management, allowing unauthorized access

  • Broken sandboxing of customizations, allowing arbitrary code execution or access to system resources

NON Qualifying vulnerabilities - DO NOT REPORT!

  • XSS vulnerabilities working only in unsupported/deprecated browsers, or requiring relaxed security settings

  • Self-XSS attacks requiring the user to actively copy/paste malicious code into their own browser window

  • "XSS attacks" by admins, e.g. via file uploads (SVG, HTML, JS, ...) or script injection. Administrators are webmasters, security restrictions don't apply to them, this is a feature.

  • Rate-limiting / Brute-forcing / Scripting of components working as designed (e.g. password authentication, password reset, etc.)

  • User enumeration (ability to verify that a username exists). Does not carry much risk, and can't be prevented without deteriorating the user experience.

  • File path disclosures, which do not carry significant risk and do not enable attacks that would be otherwise impossible

  • Clickjacking or phishing attacks using social engineering tricks to abuse users, with the system working as intended

  • Tabnapping or other phishing attacks conducted by navigating other browser tabs

  • Logout CSRF (no plausible attack + not preventable e.g. via cookie tossing or cookie jar overflow)

  • Open redirectors, which are simply one vector for phishing among many others ( see our detailed explanation)

  • Reflected File Downloads, another attack technique that requires social engineering and is not very practical

  • Referer leak (including sensitive tokens) via social media links or ads/analytics requests - very unlikely to be clicked, or to be exploited within validity period by those mainstream companies!

  • More generally, attacks relying on physical or social engineering techniques will usually be rejected

  • Non-permanent Denial of Service (DoS) and distributed DoS (DDoS) that maintain resource exhaustion (cpu/network/memory/...) via a sustained stream of requests/packets

  • Password policies (length, format, character classes, etc.)

  • Missing or partial verification of email addresses, or ways to circumvent it

  • Disclosure of public information or information that does not carry significant risks (directory listing on our downloads archive is a required feature! ;-))

  • Spam-fighting policies and systems such as DKIM, SPF or DMARC

  • Absence of HTTP Strict Transport Security (HSTS) headers, HSTS preloading, and HSTS policies

  • Weak ciphers or SSL deployments details. Our benchmark is an A grade on SSLLab's test yet a maximal compatibility with user browsers. We are currently phasing out TLS 1.0 on openeducat.org, already done for our customer hosting services

  • SSRF attacks, unless they allow access to special protocol handlers (e.g. file://), or can be used in a working scenario to bypass access control on the OpenEduCat Cloud Hosting

  • Issues in default configuration of access control rules (e.g. ACLs and record rules) - please open regular bug reports instead

  • Attack scenarios that include a takeover of user email accounts

If you have any doubt, please ask us first!