Skip to main content
Tarabut
VULNERABILITY DISCLOSURE PROGRAMME AT TARABUT

Responsible Vulnerability Reporting Guidelines​ at Tarabut

At Tarabut, we value the contributions of the security research community in identifying and responsibly disclosing vulnerabilities. Our Vulnerability Disclosure Programme is designed to ensure that any security issues are reported and handled in a secure, responsible manner. Please review the guidelines below before conducting any tests on our services.​

Terms of Disclosure Programme

Tarabut’s Disclosure Policy

Please do not publicly disclose any vulnerabilities without explicit consent from Tarabut, even if they have been resolved. Maintaining confidentiality is key to ensuring responsible disclosure and remediation.

Scope


All our external production assets are considered in scope as part of the vulnerability disclosure program. This includes all applications, network services and systems exposed on domains owned by Tarabut as detailed below: 

  • *.tarabutgateway.io 
  • *.tarabut.com 
The subdomains of tarabut.com, tarabutgateway.io which upon access redirect to 3rd party services should be considered out-of-scope. All vulnerabilities reported should have a clear and demonstrable impact translating to a concrete and meaningful security risk. 

Out of Scope Issues


Certain issues are not covered under our disclosure programme, such as vulnerabilities relying on phishing, denial of service, user enumeration, and missing best practices (e.g., SSL/TLS configurations). Vulnerabilities impacting third-party applications or dependencies used by Tarabut must demonstrate a significant security impact.
  • Social Engineering 
  • Denial of service (DoS) & DDoS attacks 
  • Physical security 
  • Lack of rate limiting issues 
  • Password complexity 
  • User enumeration 
  • Missing best practices in SSL/TLS configuration 
  • Missing best practices in HTTP headers configuration 
  • Missing best practices in DNS records 
  • Issues related to DMARC/SPF/DKIM configuration, email spoofing, or email spam without evidence of an actual security vulnerability. 
  • CSRF against logging out functionality or other non state-changing functions 
  • Access to information which is intentionally "public" 
  • Directory listing 
  • Software version disclosure 
  • Non-Sensitive cookie issues 
  • Issues affecting third party applications or dependencies used by Tarabut, unless a significant security impact is proved (i.e. we expect a full exploit). More generic issues without an actual impact should be reported to the relevant vendor (if the issue is not already publicly known). 
  • Issues only available in self-exploitation scenarios (e.g. self XSS or pasting JavaScript into the browser console) 
  • Clickjacking on pages with no sensitive actions (e.g. on tarabut.com) 
  • Non-Production environments 

Testing Guidelines 

The guidelines below are provided for external security testers in order to guarantee minimal disruption to our services and assure the confidentiality of our customer data. 

  • Act in Good Faith: Only test for vulnerabilities on the systems mentioned within the scope of this program. 
  • Do No Harm: Avoid any activities that may harm the experience or confidentiality of our users, such as DDoS attacks, data corruption, or privacy violations. 
  • Non-Destructive Testing: Do not use automated tools or excessive traffic to test for vulnerabilities. Ensure all testing is non-disruptive. 

Comprehensive Security Testing Protocols

Fuzzing
Exploitation
Cross-Account Access
Filling a Report
Fuzzing

Fuzzing

Dynamic fuzzing should be rate limited to no more than 5 requests per second. The following header should be included along with each HTTO request: 

X-Username:<RESEARCHER_EMAIL_ADDRESS>

Exploitation

Exploitation

Security issues discovered in any Tarabut applications and systems should be explored to the minimum extent possible to demonstrate the presence of the vulnerability. For instance, 

in the context of a SQL injection vulnerability a simple time-based payload or a boolean based one is sufficient to demonstrate the vulnerability, without retrieving the whole database content. 

Cross-Account Access

Cross-Account Access

Researchers should create and use their own test accounts for any Tarabut service requiring authentication. This is particulalrly relevant for vulnerabilities that can result in 

unauthorized cross-account access such as insecure direct object reference, lack of access controls, account hijacking and so on. Under no circumstances should exploitation 

of vulnerabilities like those mentioned above be conducted against other customer accounts. 

Filling a Report

Filing a Report

A vulnerability disclosure report must include: the reporter's name, a description of the vulnerability, proof-of-concept details (i.e., screenshots, log output), affected components, 

estimated severity and potential impact, and any other supporting data. 

Vulnerability reports should be sent to the vulnerability-disclosure@tarabut.com email address. Security researchers are encouraged to encrypt sensitive vulnerability details using our public PGP key.

Have any questions about security?

If you have any questions about the security measures and standards at Tarabut, please email