Vulnerability Disclosure

Safe Harbor

When reporting vulnerabilities in compliance with this policy, SchooLinks commits to:

1. Not pursuing legal action against you or your organization.
2. Considering your findings within the scope of this policy in good faith.
3. Working with you to understand and resolve the issue promptly.

As long as your research follows this policy, we consider it authorized and will work to ensure that no action is taken against you.

Rules of Engagement

By submitting reports or otherwise participating in the Vulnerability Disclosure program, you agree that you have read and will follow the below Rules of Engagement of this program.

1. Never use a finding to compromise/exfiltrate data or pivot to other systems. Use a proof of concept only to demonstrate an issue.
2. If sensitive information, such as personal information, credentials, etc., is accessed as part of a vulnerability, it must not be saved, stored, transferred, accessed, or otherwise processed after the initial discovery. All copies of sensitive information must be returned to SchooLinks and may not be retained.
3. Researchers may not, and are not authorized to engage in any activity that would be disruptive, damaging or harmful to SchooLinks, its brands, customers, employees or users. This, among others, includes: social engineering, phishing, physical security, and denial of service attacks against users, employees, or SchooLinks and its affiliates as a whole.
4. Out of concern for the availability of our services to all users, please do not attempt to carry out Denial-of-Service (DoS) attacks, leverage black hat SEO techniques, spam people, or do other similarly questionable things. We also discourage using any vulnerability testing tools that automatically generate significant volumes of traffic.
5. Your testing must not violate any law.
6. Researchers may not publicly disclose vulnerabilities (sharing any details whatsoever with anyone other than authorized SchooLinks employees), or otherwise share vulnerabilities with a third party, without SchooLinks’s explicit written permission before the evaluation period ends (45 days).
7. SchooLinks will not give you any access to our systems to conduct white hat research.

Scope of the Program

Systems

Any system or service that handles sensitive data belonging to SchooLinks or SchooLinks clients is in the scope of the program. The vast majority of the sensitive content can be found on the following domains:

1. schooinks.com

Examples:

1. Main products:
2. https://app.schooLinks.com
3. https://transfer.schooLinks.com
4. Support Pages
5. https://support.schooLinks.com

Types of vulnerabilities

In general, any design or implementation issue that substantially affects the confidentiality or integrity of user or customer data is in the program's scope.

1. Cross-Site Scripting (XSS)
2. Cross-Site Request Forgery (CSRF), except exclusions listed under the out-of-scope section
3. Authentication or Authorization Flaws (Broken Access Control)
4. Sensitive Data Exposure
5. Security Misconfiguration
6. Server-Side Request Forgery (SSRF)
7. SQL injection (SQLI)
8. Server-Side Template Injection (SSTI)
9. Remote Code Execution (RCE)
10. Local or Remote File Inclusions

While the above list represents our primary focus for security research, we are interested in reports for all vulnerabilities that can lead to sensitive data disclosure or can cause serious business disruption.

Out-of-scope vulnerabilities & accepted risks

Approximately 90% of the submissions we receive through our vulnerability reporting program are ultimately deemed to have little or no practical significance to product security. The experience of reporting an issue and not qualifying for a reward can be disappointing to less experienced researchers – and the high volume of submissions makes it harder for us to spot valid, high-impact reports.In the spirit of openness, we decided to publish examples of some of the most common non-qualifying report types, with a brief explanation of our reasoning behind not treating them as a security risk or otherwise not paying out rewards.

Invalid attack scenarios

1. Any physical attack against the user's device, SchooLinks property or its data host providers;
2. Social engineering of SchooLinks staff or contractors;
3. Configuration issues on end-users machines. (for example, password storage or cache settings);
4. Attacks requiring a Man-in-the-Middle, with no other possible exploitation;
5. Attacks affecting only the users of outdated browsers, plugins or OS.

Ability to discover platform users by email addresses

When you sign up for a SchooLinks account and create a profile, we display the email in multiple places and generally allow it to be discovered by others who already know your email address.In this spirit, we do not treat reports of locations that allow you to discover email addresses, for example, login or commenting capabilities, as a security vulnerability.

Open redirectors

Open redirectors take you from a SchooLinks URL to another website chosen by whoever constructed the link. Some members of the security community argue that the redirectors aid phishing, because users may be inclined to trust the mouse hover tooltip on a link and then fail to examine the address bar once the navigation takes place.Our take on this is that tooltips are not a reliable security indicator, and can be tampered with in many ways, so we generally hold that a small number of properly implemented redirectors offers fairly clear benefits and poses minimal practical risk.

Reflected file download

A so-called "Reflected File Download" (RFD) is a technique that allows the attacker to force the browser to initiate a file download from a given origin with partially-controlled content. That might be used to create a social engineering attack, in which users trust that the file is, for example, a legitimate software installer coming from a website users trust.We understand this attack technique, but at the same time believe it's not a very practical one. When deciding whether to execute a file, users rely on the context in which the file download was initiated, not on where the file was actually hosted. In some browsers, this information is not even displayed by default, and one can see it only on a Downloads page. RFD can be used to create a social engineering attack, but there are other, more practical ways to achieve the same.

CSV Excel formula injection

Occasionally, we get reports describing Excel formula injection into CSV files. Specifically, the reports mention that one of our products with an 'export to CSV' feature can be abused to inject Excel formulas into a generated file downloaded by the user. The attack scenario mentions that, under certain circumstances, those formulas could be executed by the application opening the CSV file (Microsoft Excel is commonly mentioned). The consequence is not just running arithmetic operations on a victim's machine (though we all like =1338-1), but may amount even to running arbitrary commands.CSV files are just text files (the format is defined in RFC 4180), and evaluating formulas is a behavior of only a subset of the applications opening them - it's rather a side effect of the CSV format and not a vulnerability in our products which can export user-created CSVs. The application should mitigate this issue by importing/interpreting data from an external source, as, for example, Microsoft Excel does by showing a warning. In other words, the proper fix should be applied when opening the CSV files rather than when creating them.In conclusion, we don't think the risk introduced by this behavior is significant enough to warrant a change in our product.

Lack of HTML sanitization where data is not intended to be rendered as HTML

Sometimes, we get reports that the API does not perform appropriate validation of user-supplied input, which is reflected back to the user. When such information is rendered as HTML content, it can be used to execute a cross-site scripting attack. In such cases, we take this as a severe security vulnerability that needs to be resolved as soon as possible. However, when input is rendered as a JSON or text file, it is not considered a security issue, because the browser will not execute any JavaScript.

Campaign preview is accessible if Campaign ID is known

This is an intentional design decision aimed at allowing easy sharing of preview links.

Logout CSRF

For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify.

Clickjacking

When evaluating reports of cross-site request forgery (CSRF) or clickjacking vulnerabilities, we always try to understand their impact when actually exploited. If a successful attack does not change the state of SchooLinks accounts in any way, or if the change is very inconsequential, the report will usually not qualify for a reward.

Similarly, cross-site request forgery for actions that do not require authentication, or can only be performed using other unpredictable values (passwords, secret invitation codes, etc.) are often also deemed to be non-issues.

Issues that result in Denial of Service (DoS)

We are aware that any issue resulting in Denial of Service is unpleasant and such scenarios should be prevented. However, any issue that could result in Denial of Service of SchooLinks webpages, servers at the network or application layer, or in any other system SchooLinks uses is unlikely to cause sensitive data disclosure. Therefore, reports addressing DoS will not qualify for a reward.

Commonly reported SSL/TLS vulnerabilities

Bug hunters sometimes report that the SSL/TLS configuration of one of our services is vulnerable to some of the SSL/TLS vulnerabilities disclosed in recent years. In this context, CRIME, BEAST, and POODLE are often mentioned, together with the usage of the RC4 cipher.

We always carefully validate each report, and the issues mentioned above often turn out to be invalid.

SPF softfail (~all) policy

We take email security seriously and work to ensure nobody can impersonate @schoolinks.com email addresses. Our goal is that all DMARC-compatible email services reject illegitimate spoofed emails or mark them as spam.

The softfail (~all) policy achieves this goal and is a deliberately chosen trade-off.

Issues related to software or protocols not under SchooLinks control

We are more than happy to be notified that any of the software, services or protocol we may use are vulnerable. However, we cannot reward you for anything not under our control.

Vulnerabilities found in systems offered by SchooLinks vendors where SchooLinks doesn’t have control, should additionally be reported directly to the vendor according to their disclosure policy (if any).

Issues without clearly identified security impact

Although we wanted to give you an overview of what kind of reports on vulnerabilities will most likely not qualify for a reward, we cannot list them all here. In general, any reported issue that cannot lead to sensitive data disclosure will probably be ruled out for any reward. Examples of such reports are usually issues identified by automated scanners, such as patches for security updates without known or practical exploits.

Report a Vulnerability

If you believe you’ve identified a security vulnerability on the SchooLinks platform and any of the associated tools used to provide you services on SchooLinks, please reach out to security@schooLinks.com providing the following:

1. Outline of the bug or description of the vulnerability,
2. Proof of exploitability that leads to sensitive data disclosure or modification (for example, a screenshot, or video).

Expectations

When collaborating with us according to the program rules, you can expect us to:

1. Work with you to understand and validate your report, including timely initial response to the submission;
2. Remediate any proven and, from our side, confirmed in-scope vulnerabilities promptly;
3. Recognize your contribution to improving our security if you are the first to report a unique vulnerability, and your report triggers a code or configuration change;
4. Reward your contribution if eligible for a reward in a timely manner.

Reward Eligibility

SchooLinks may reward responsible disclosure of vulnerabilities that can lead to sensitive data disclosure or cause significant business disruption. Contributors of identified and exploitable concerns verified by SchooLinks may be offered a reward at our discretion.

Eligibility for any monetary compensation is limited to the first person to report an unknown issue. We would usually offer a bounty based on the severity score. The severity final score is always determined by SchooLinks.You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

We would automatically decline any reward payouts if you are:

1. A resident of, or make your Submission from, a country against which the United States has issued export sanctions or other trade restrictions (for example, Cuba, Iran, North Korea, Sudan and Syria);
2. A person sanctioned by any country where SchooLinks and its subsidiaries have a registered business;
3. Associated with a terrorist or criminal organization;
4. Employed by SchooLinks or its subsidiaries (including former employees or contractors that conducted work for SchooLinks within the prior 12 months);
5. An immediate family member of a person employed by SchooLinks Inc. or its subsidiaries or affiliates.

Other disqualifiers:

1. Overwhelming our teams with messages;
2. Use of hateful or threatening language when communicating with us;
3. Reports on 0-day and other CVE vulnerabilities published for less than 60 days.

Reward Offers

SchooLinks offers rewards for properly submitted and reports that meet our eligibility requirements. Additionally rewards are offered for vulnerabilities based on their severity, determined by their potential impact and likelihood of exploitation. The ranges are as follows:

1. Critical vulnerabilities (e.g., remote code execution, significant data exposure) – up to $200
2. High vulnerabilities (e.g., privilege escalation, major information leaks) – up to $100
3. Medium vulnerabilities (e.g., limited information exposure, security misconfigurations) – up to $50
4. Low vulnerabilities (e.g., minor issues that do not directly impact security) – up to $20
5. Informational – Eligible for acknowledgment but may not qualify for a bounty

Please note that bounties are awarded at SchooLinks' discretion and based on the severity of each report. Repetitive or duplicate reports may not qualify for additional bounty rewards.

Contact

Please direct all security vulnerability reports and related communications to:security@schoolinks.com

Thank you for helping us keep SchooLinks secure!

At SchooLinks, we prioritize the security and privacy of our users, data, and systems. We value the contributions of the security research community and are committed to addressing vulnerabilities promptly. This Vulnerability Disclosure Policy (VDP) establishes the guidelines and expectations for reporting security vulnerabilities in our platform.

‍