Responsible Vulnerability Disclosure Program

Introduction

Please read and understand this document in its entirety. The document explains the guidelines, scope, exclusions, and the Responsible Vulnerability Disclosure Policy that BYJU’S has created for security researchers to submit vulnerability reports, for the systems in scope as outlined on this page.

BYJU’S recognizes the value external security researchers can bring to the security of BYJU’S systems, and we welcome and seek to acknowledge eligible contributions from security researchers, as outlined below. If you believe you have found a security vulnerability, we encourage you to let us know right away. We will investigate all legitimate reports, acknowledge the reporter and do our best to quickly fix the problem.

Before reporting, though, please review this page, including our responsible disclosure policy, acknowledgement guidelines, scope of the program, and our exclusions.

Responsible Vulnerability Disclosure Policy

For you to participate in the BYJU’S Responsible Vulnerability Disclosure Policy, we require that

You find and report vulnerabilities in the assets listed in scope. Any vulnerabilities reported for assets that are not in scope may not be acknowledged regardless of whether the reported security issue is fixed by BYJU’S or not.
You submit the bug report with as many details as possible. The bug report structure expected is outlined in this document.
You ensure that any vulnerability research for an account related feature is done using an account that you have created. If using any other account to demonstrate a vulnerability, you will need to obtain explicit written permission from the said account owner which will need to be produced upon request.
You make a good faith effort to avoid privacy violations and disruptions to others, including (but not limited to) unauthorized access to or destruction of data, and interruption or degradation of our services. You must not intentionally violate any applicable laws or regulations, including (but not limited to) laws and regulations prohibiting unauthorized access to data.
If you accidentally access another account’s data, sales information, order details, customer information or any information that is not created by you in the first place without authorization while investigating an issue, you must immediately stop any testing activity that will result in further access and data leakage and notify BYJU’S immediately with details of all the information that was accessed (including a description of the contents of the information that was accessed). Continuing to test and access data may demonstrate a lack of good faith and disqualify you from being acknowledged as a security bug reporter and may potentially invite additional legal scrutiny.
You must be available to provide any additional information when requested regarding a bug submission.
You do not exploit or perform any post exploitation activity as part of the testing. The testing must cease as soon as a bug is discovered. Any activity to capture a “Proof of Concept” video is permitted as long as 4 and 5 above are adhered to.
You give us reasonable time to investigate and mitigate an issue you report before publicly disclosing any information about the report or sharing such information with others. We read all reports within 24 hours of receiving a submission, but the validation and verification may take a little longer. It may take up to 10 business days for us to respond back to you. We request you to maintain issue secrecy and confidentiality while we get back to you.
You must follow the reporting structure as outlined below, maintain communication decorum and not reach out to any employee of BYJU’S or third-party vendors regarding updates, submission policies or any other discussions unless a communication is initiated from BYJU’S.
You are not employed by BYJU’S or any of its affiliates or an immediate family member of a person employed by BYJU’S or any of its affiliates.
You agree that BYJU’S’ Security Team will be the sole decision maker for agreeing to whether a submission qualifies as a bug or not and whether the severity is warranted. Often due to the way the infrastructure and applications are set up, a high severity issue may have less impact due to internal security controls which may not be obvious from the outside. BYJU’S Security Team will ensure to calculate the severity based on all these factors to derive the final severity score, which will be binding to the submission.

Responsible Vulnerability Disclosure Program Process

This section describes the process that will be followed when you submit a bug report to us

A security researcher submits a bug report using the designated report structure and to the designated email address (covered in the next section, Vulnerability Bug Report Submission)
You will receive an automated reply acknowledging your email within 2 hours of the bug submission
The bug report will be evaluated internally and added to an internal bug tracker. If the bug is found to be valid, a bug report ID will be generated. You will not be able to track the bug using this ID but use it only for reference in communication with BYJU’S.
If the security issue has been identified internally or by another security researcher before your submission, you will be notified that your submission is a DUPLICATE issue. Additional information may not be provided by BYJU’S.
In case BYJU’S does not deem the bug to be a security problem or if the submission is for an out-of-scope asset, no further communication will occur. If you think the submission is valid, it is encouraged to provide more details by following the guidelines in this document.
An email will be sent acknowledging the bug with the Bug report ID and an update.
BYJU’S will internally collaborate and create a plan for fixing/mitigating the security problem.
You may request for an update at any point in time, however, please note that due to our internal processes, it may take anywhere between 3 to 10 business days for us to respond to your emails.
Once the security issue is resolved, you will be notified of the fix.
If the BYJU’S team deems the bug does not qualify a fix or is low impact based on internal discussions, you will be notified, and the internal tracking will be closed.
As a final step, with your permission, we would like to have you listed in the BYJU’S Hall of Fame for Security Researchers. We reserve the right to limit or modify the information accompanying your name in the list.

How to submit a Vulnerability Bug Report

High quality submissions allow our team to better understand the issue and relay the bug to the internal team to fix. The best reports provide enough actionable information to verify and validate the issue without any follow up clarifying questions. To ensure minimal follow ups and round trips, we require the following format of the bug report to be followed.

All vulnerability bug reports have to be sent to the following email address. Any submissions to any other email addresses will be ignored

bugreport@byjus.com

This email address must be used only to send vulnerability and security related reports. Any non-security related or non-vulnerability disclosure emails sent to this address will go unacknowledged.

All submissions to this email address must provide the following information

Email Subject: Must mention vulnerability class along with location of the issue. For example: SQL Injection found in account creation page at abc.example.com
Email Body: The email body must contain, at a minimum, the following items

o Technical Description of the Security Issue: Be as detailed here as possible. This should be the longest section. Be as thorough and descriptive here.

o CVSS 3.1 Base Score: This can be calculated using https://www.first.org/cvss/calculator/3.1

o Impact: What is the impact to BYJU’S and/or their customers if this bug is exploited. Please consider a real world threat to the organisation or our customers.

o Steps to Reproduce: Provide as many steps as possible, be as detailed in the steps. If required mention the version number of the tools or browser that was used to replicate the issue.

o References: Any relevant reference URLs that you think would help us understand the issue better.

Proof of Concept Video Attachment: This is mandatory as part of the submission. Bug submissions will not be evaluated without a Video PoC of the bug. You may add a voice overlay to explain what is happening in the video. Please refrain from having irrelevant music, voice or images within the video not directly related to the bug.

Attachments of any other kind will be filtered by our spam filters and will not be received by us. Please do not send PDF or any Office documents (.docx, .xlsx etc.) unless requested for by the team.

Responsible Vulnerability Disclosure Program Scope

An asset or application not explicitly mentioned here is out of scope. All submissions will be evaluated based on whether the submission aligns with the scope requirement as follows

In-Scope Assets

Only the following assets are in scope

BYJU’S Main website (https://byjus.com/ and https://www.byjus.com/)
Blog website (https://blog.byjus.com/)

Out of Scope Assets

The following is a list of assets that are not considered to be in scope for this Responsible Vulnerability Disclosure Program. Finding security issues in the following assets is highly discouraged and any vulnerabilities reported for the assets below may go unacknowledged even though BYJU’S may choose to remediate the security issue.

Please visit this page often to find the latest list of assets in and out of scope of the program.

Any other subdomain or applications of BYJU’S are out of scope if not mentioned in the In-Scope section, until further notice. This includes *.byjus.com, *.tllms.com and *.example.com
All network infrastructure assets of BYJU’S are out of scope. This includes any port scan results and the discovery of non web assets of BYJU’S (see Exclusions and False Positives below for examples)
All mobile applications belonging to BYJU’S are out of scope. This includes all published Android and iOS applications, past and present versions.
learn.byjus.com

Examples of Valid Vulnerability Submissions

The following is non exhaustive list of vulnerabilities that we would consider as valid vulnerability submissions

Remote Code execution
Cross Site Scripting Issues (Reflected, Stored or DOM based)
SQL Injection vulnerabilities
BOLA/IDORs allowing access to unauthorized data
XML injection issues
Server Side Request Forgeries
Logic Bugs that result in a security issue
Authentication, Authorisation or Session Management Issues

The decision of whether a reported submission qualifies to be a Security issue rests with BYJU’S.

Exclusions and False Positives

The following is a non-exhaustive list of submissions we do not consider are security issues to BYJU’S

Spamming, social engineering or phishing attempts
Denial of Service attacks
Broken Hyperlinks that point to content that is no longer present on the Internet
Security issues that can only be reproduced in browsers that are no longer supported by the browser vendor
Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality
Older JavaScript versions in use, unless a Proof of Concept can be shown demonstrating a working exploit
Security issues in third-party integrations with BYJU’S assets
IDOR references to objects that you already have access to
Subdomain takeover bugs that cannot be demonstrated as a valid exploitable security issue. Please refer to https://github.com/EdOverflow/can-i-take-over-xyz to see a list of services that qualify. Additionally, ensure the subdomain is a valid in-scope asset before submitting the issue.
Rate limiting or Brute force issues. This includes WordPress xmlrpc.php or WordPress login brute force submissions.
Username enumeration bugs where a side channel like time delay is used. We may review a submission for an in-scope application that clearly provides a verbose error message (for example: “The username is incorrect”).
Forgot password feature being used to enumerate usernames.
User login and Forgot password feature being used to demonstrate account lockout.
OTP sending to arbitrary numbers or OTP guessing bugs, if the number of requests that can be made are insignificant without getting blocked.
Banner grabbing or server fingerprinting issues (for example: disclosing the server is Apache or nginx)
Web server or software version related bugs including the disclosure of the version number itself. We may review this on a case-by-case basis if a working exploit for the software has been published or if the software is being actively exploited in the wild.
Disclosure of known public files or directories, (e.g. robots.txt)
Clickjacking and issues only exploitable through clickjacking
Missing SPF or DMARC records
Session timeout related bugs
Self XSS issues where the victim is the user planting the attack payload.
Flash or Silverlight related security issues.
Stack traces, application or server errors that do not reveal a significant amount of internal server or application information.
Caching related issues that cannot be used to access resources without authentication.
HTTP 404 or other non-200 code pages.
Password complexity requirements during registration and login.
CSRF issues on Login/Logout functionality, on forms that are available to anonymous users (contact form, registration form etc.)
Accessing content from our CDNs (Content Delivery Network), unless the data is meant to be presented after authorization.
Exposed Login Panels for software, including WordPress being accessible to the world
Directory listings. We may review this as a submission if unauthorized data access is possible.
Full path disclosures due to error pages or verbose stack trace information.
Open redirects that require a shim or a token to proceed to the final target
Email addresses, BYJU’S information in JavaScript or HTML comments.
Expired domains, SSL/TLS certificates or exposure of information via SSL/TLS certificate’s Subject CN or via Certificate Transparency Logs.
Best practice bugs like missing security headers, CSP implementation, HSTS, cache-control headers, SSL/TLS implementations, missing CAPTCHA etc.
Security issues arising out of physical access or theft of BYJU’S property or access to the physical location of BYJU’S offices.
Any automated scanner reports that are not validated and show an impact on BYJU’S in-scope assets
Any other highly speculative bug submission that talks about theoretical damage etc.

Hall of Fame Recognition

BYJU’S will, with your permission, list your name on the BYJU’S Hall of Fame for Security Researchers.

Please note, BYJU’S currently offers no monetary award or swag/goodies for any reported security issues.

Please treat the information on this page as the correct source of information relating to this program. Be wary of any individual or authority impersonating as a BYJU’S representative who claims to provide monetary benefit or swag in exchange for bug reports. We do not have any such association and have not authorized any individual or organisation to obtain security vulnerability reports on our behalf.

Confidentiality

Any information you receive or collect about us, our vendors, our affiliates or any of our users, employees or agents in connection with this program (“Confidential Information”) must be kept confidential and only used in connection with the program.

You may not use, disclose or distribute any such Confidential Information, including without limitation any information regarding your Submission, without our prior written consent. You must get written consent by submitting a disclosure request to the submission email address listed in this document. Please note, not all requests for public disclosure may be approved by BYJU’S.

Rights and Licenses

We may modify the Program Terms or cancel the program at any time.

By making a “submission”, you represent and warrant that the “submission” is original to you and you have the right to submit the “submission”.

By making a “submission”, you give us the right to use your “submission” for any purpose as part of internal case studies, public disclosures or publishing material within and outside of BYJU’S.

Reporting issues on BYJU'S website