By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
PreferencesDenyAccept

Responsibility Disclosure Policy

‍

Last Updated: September 5, 2021

‍

At Lark the security of our systems, and our users’ data, is a top priority. No matter how much effort we put into our security, there might still be vulnerabilities or security issues present. If you discover a security issue in the Lark environment , kindly inform us so we can take corrective actions to address it as quickly as possible.  

‍

To contact us with your findings, please fill the following form: Vulnerability Disclosure Form and provide the required details that will allow us to understand, validate and remediate the issue.

‍

We are also active on OpenBugBounty to attract valuable findings: OpenBugBounty.

‍

The following are the areas considered In-Scope:
  • https://www.lark.com- Only if you can take over the site or found critical web application issue.
  • Any site accessible online which belongs to Lark Health
  • Lark Health Android App (Send and email to security@lark.com to get an account to test the app)
  • Lark Health iOS App (Send and email to security@lark.com to get an account to test the app)‍
  • https://www.careers.lark.com – Only if you can change the job description or add a new job posting.

‍

Dos:
  • Do provide sufficient information to reproduce the problem, so we will be able to resolve it as quickly as possible. A proof of concept (PoC) video/screenshot along with the explanation is a must if you want us to validate the finding. If a PoC is not submitted, we can not work on your finding.
  • Do report the vulnerability as quickly as is reasonably possible, to minimize the risk of hostile actors finding it and taking advantage of it.
Don’ts:
  • Don’t reveal the vulnerability or problem to others until it is resolved.
  • Don’t build your own backdoor in an information system with the intention of then using it to demonstrate the vulnerability, because doing so can cause additional damage and create unnecessary security risks.
  • Don’t utilize a vulnerability further than necessary to establish its existence.
  • Don’t copy, modify or delete data on the system. An alternative for doing so is making a directory listing of the system.
  • Don’t make changes to the system.
  • Don’t repeatedly gain access to the system or share access with others.
  • Don’t use brute force attacks, attacks on physical security, social engineering, distributed denial of service, spam or applications of third parties to gain access to the system.

‍

The following areas are considered out of scope:

‍

  • Vulnerabilities that require access to an already compromised account (unless access to an account exposes other accounts)
  • Policies as opposed to implementations – email verification, password length or reuse, etc.
  • Missing security headers or ‘best practices’ (except if you are able to demonstrate a vulnerability that makes use of their absence)
  • Vulnerabilities in our open source software (unless you have a proof of concept of how the specific vulnerability can be used on the Lark app)
  • Denial of Service attacks (DoS) or Distributed Denial of Service (DDoS)
  • DoS vulnerabilities which cause application “slowdown” will be considered P5/Informational, unless the researcher can demonstrate that the bug is severe enough to disable OTHER sessions and site functionality without a large number of resources. Bugs which cannot clearly show the impact on OTHER users without significant resources will be considered DDoS.
  • Social engineering attacks
  • Third party applications we make use of, but do not control (e.g. a blog or newsletter hosted on an external service.)
  • Automated scan reports as Lark conducts it’s own automated scans on the in-scope targets.
  • Subdomain takeovers require strong proof of concept. Lark’s Security team will evaluate if the domain has any business value before rewarding the bounty.
What we promise:

‍

  • We will respond to your report within 14 business days with our evaluation of the finding and an expected resolution date.
  • If you have followed the instructions above, we will not take any legal action against you in regard to the report.
  • We will handle your report with strict confidentiality, and not pass on your personal details to third parties without your permission.
  • We will keep you informed of the progress towards resolving the problem.
  • In the public information concerning the problem reported, we will give your name as the discoverer of the problem (unless you desire otherwise), and
  • As a token of our gratitude for your assistance, we will pay a minimum of $100 through Paypal for every evaluated and confirmed vulnerability.
Focus Areas:
  • SSRF
  • Any Stored XXS
  • Any Remote Code Execution
  • Any Local File Inclusion
  • Any Privilege Escalation
  • Any Business Logic Bypass
  • Access control bypass/Directory traversal
  • Any finding that has significant Business Impact  
  • Common misconfigurations on the mobile app
Guidance on Common Findings / Known Issues

The following are an intended design or are in the process of being remediated, please avoid spending time here as you are more likely to earn a bounty when hunting on our Focus Areas (see above)

  • Failure to Invalidate Session > On Password Reset and/or Change  – support.lark.com Please note, other authorization and session-based vulnerabilities can be valuable
  • Text/HTML Injection is of less value to the team, please focus on other XXS (stored) type findings
  • No Rate Limiting on ‘Forgot Password’ or ‘Email-Triggering’, if you can find other ways to leverage the password reset then you are welcome to submit your finding.
  • Lack of DMARC record
  • Any security headers missing such as HSTS etc.,
  • Email HTML Injection
  • Website enumeration
  • Clickjacking
  • Session tokens in URL

‍