Security overview

Includable takes the upmost responsiblity in keeping the Includable Platform and any data stored by users secure. This page lists the security standards and technologies we use to do this.

FERPA compliance

Includable and Scholica are FERPA (Family Educational Rights and Privacy Act) compliant so your student data is absolutely secure and will never be used to target advertisements without your explicit consent.

HTTPS (SSL) everywhere

All Includable web URLs that require user authentication or otherwise contain personal information are only available through an secure HTTPS connection. This is true for the main Includable and Scholica domains includable.com, scholica.com and scholica.courses, as well as any custom domains set up by Includable customers. Custom domains use Letsencrypt to automate the HTTPS certificate generation process.

Includable servers have been patched for the Heartbleed and POODLE vulnabilities.

Includable supports the TLS 1.0, 1.1 and 1.2 protocols, and does not support the deprecated protocols SSLv2 and SSLv3.

Strict Transport Security (HSTS) is enabled for any application subdomain.

Authentication cookies are saved with SecureOnly and HTTPOnly flags.

Server hosting

Includable database servers are located within the European Entrepreneurial Region (EER). Specifically, our application and database servers are located in data centres in Dublin, Ireland. File storage and our content delivery network uses a series of edge servers in Europe, Asia and the United States.

Data back ups

Password policy

Includable enforces a password policy that requires all user-created passwords to be at least 6 characters long by default. Administrators of Includable Platform accounts are able to add more policy features.

Vulnability disclosure

Includable has ISO 29147 & 30111 compliant vulnability disclosure workflows in place, as well as a bug bounty program. Vulnabilities can be disclosed through security@includable.com.

Disclosure Policy

Verifiable proof the vulnerability exists (screenshot/video/script) is required to receive an award.

For more technically elaborate vulnerabilities, reproduction steps are required. If our security team cannot reproduce and verify an issue, a bounty cannot be awarded.

Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.

Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.

Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.

A good bug report should include the following information at a minimum:

List the URL and any affected parameters

Describe the browser, OS, and/or app version

Describe the perceived impact. How could the bug potentially be exploited?

Missing security-related HTTP headers which do not lead directly to a vulnerability

Eligibility and Coordinated Disclosure

You will be eligible for a bounty only if you are the first person to disclose an unknown issue to Includable. The Includable development team has 30 days to respond to the report, and up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability. Note that posting details or conversations about this report before it has been approved for disclosure or posting details that reflect badly on this program and the Includable brand will result in forfeiture of any award and/or immediate removal from the program.

Vulnability reports log

July 2017

January 2017

MINORFIXED
When adding content through the WYSIWYG editor in multiple locations
in the Courses module, it was possible to add malicious <script> tags.
Version affected: beta-2
Communities affected: StartupSpirit
Version fixed: 2.0.0

August 2016

MINORFIXED
A theoretical XSS attach was possible through the
GET-parameter community on login pages, of which the value was
printed in the resulting HTML without sanitation. This type of
attack is improbable as it would have yielded any interesting
information: the user wasn’t signed in yet.
Communities affected: all

December 2014

MEDIUMFIXED
When entering an empty username in the login form of communities
that use external LDAP authentication, a request to the LDAP would
still be sent, which allowed a theoretical DDoS attach, as some LDAP
servers have rate limiting based on the user that is singing in.
Communities affected: Bernardinuscollege

September 2014

HIGHFIXED
Custom domain names do not use SSL, which allows network spoofing to
find passwords, especially on large corporate networks with many
users logging in to Includable every few minutes.
Communities affected: Bernardinuscollege
Implemented solution: SSL is required for all authentication
attempts (update: all custom domains are now automatically provided
with a SSL certificate).

PGP key

If you wish to secure your email transactions with us, please use our PGP key below.