Responsible disclosure is a method to report system vulnerabilities that allows the recipient sufficient time to identify and apply necessary countermeasures before making information public.
Security is core to our values, and we value the input of security researchers acting in good faith to help us maintain a high standard for the security and privacy for our users, this includes encouraging responsible vulnerability research and disclosure.
By following this controlled and ethically correct reporting model, the sender helps companies identify and resolve system flaws, providing a valuable and efficient contribution to increasing the security of our services and avoiding damage or disruption to the systems involved.
To send a detected vulnerability, write to email@example.com following the instructions below.
How it works
The reporter should never perform any activity that can disrupt the impacted system or service or cause any data leakage/loss, also refraining from accessing data not strictly necessary to prove the existence of the vulnerability. Any activity on the impacted system/service must be carried out in full compliance with the provisions of the present policy.
Additionally, the use of intensive or invasive scanning tools is not allowed.
Responsible disclosure implies that the reporting person has not disclosed data to any other parties without consent.
Specifically, whoever activates the procedure should:
- Send the information via email to firstname.lastname@example.org with the following details:
- Personal data (name, surname, and, if applicable, organization for which the person works)
- The type of vulnerability identified
- The complete URL(s) impacted by the flaw
- A detailed description of the problem encountered
- If necessary, a compressed archive (zip) with all the files which can help in reproducing the flaw (i.e. images, screenshots, text files with description details, PoC, source code, scripts, pcap traces, logs, source IP addresses, …).
The maximum dimension of the archive cannot exceed 10MB. If the archive is password protected please specify the password in the body of the mail.
- Observe strict secrecy on all information pertaining to the vulnerabilities discovered, and therefore commit not to reveal any of these, entirely or partially, or in any form make them available to third parties for a period of not less than 90 days, allowing SkipsoLabs the required time to identify and apply the necessary countermeasures.
In especially complex cases, SkipsoLabs reserves the right to extend this period, giving appropriate notice to whoever sent the information.
- In the cases where the information regarding the vulnerabilities comes from a legal entity (public or private), corporation, consortium or other associative body, the sender must take the necessary steps to limit access to said information to those employees who require the use of the affected system for their work activities, enacting all suitable and appropriate measures to maintain confidentiality and above mentioned limits while accessing and using the information.
Once a notice has been received, Skipso is committed to following up as follows:
- Send an email to the reporting person/entity to acknowledge reception of the mail with the information outlined above
Within 30 days from this confirmation SkipsoLabs will send a second email with an evaluation of the relevance of the vulnerability and the results of an initial analysis.
- Adequately manage the vulnerability report so as to respect the timeline indicated previously and, in case of an eligible report on a vulnerability that is not already being handled, publicly thank the sender in the Hall of Fame section, if the necessary authorization accompanied the original mail.
Skipso does not offer economic rewards.
Moreover, Skipso reserves the right not to manage reports which do not respect the criteria indicated in this procedure.
Skipso stresses the importance of assuming responsible behavior even after the release of any patch as the rollout process can be long and complicated.
Therefore, we ask a careful evaluation of information released in this regard, with the objective of safeguarding user security.
Below you will find some examples of vulnerability categories that are considered eligible for publication in the Hall of Fame:
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- Injection (i.e. SQL injection, user input)
- Broken Authentication and Session Management
- Broken Access Control
- Security Misconfiguration
- Redirect / Man in the Middle attacks
- Remote code execution
- Underprotected API
- Privilege Escalation
On the other hand, the following situations are not covered by this Responsible Disclosure initiative and therefore are not eligible for the Hall of Fame:
- Situations which are not inherent to security aspects (i.e. unavailability of a service, bugs in the UI, etc.) and therefore managed through traditional channels of customer care.
- Problems regarding phishing or spam and vulnerabilities inherent to social engineering techniques; these must be signaled through the platform's contact form.
- Results of automatic tools for vulnerability assessment/penetration testing (i.e. nessus, nmap, …).
- Reports on the use of weak configurations of the TLS protocol, or reports on non-compliance with best practices, such as, for example, the lack of security headers.
Skipso reserves the right to update this Responsible Disclosure procedure at any time.
We would like to thank everyone who disclosed responsibily a security issue, recognizing their valuable contribution in increasing the security of our services.
- Amit Shrivastav(linkedin.com/in/amit-shrivastava-vapt-cyber-security-auditor-146b6a248) | DNSSEC
- Aditya Yadav (linkedin.com/in/aditya-yadav-2aa70829a) | Incomplete Redirection
- Omkar Ghanwat (linkedin.com/in/omkar-ghanwat-124408222) | Broken Link Hijacking
- Parth Narula(https://www.linkedin.com/in/parth-narula-86283821a) | Broken Link Hijacking
- Riccardo Brigatti (https://www.linkedin.com/in/riccardo-brigatti) | Insecure Direct Object Reference (IDOR)
- J Mohamed Usman (twitter.com/jmdusman) | Caching misconfiguration
- Manab Jyoti Dowarah (linkedin.com/in/manab-jyoti-dowarah-a02305211) | HTML Injection
- Nikhil Rane (linkedin.com/in/nikhil-rane-31733a217) | Sensitive data exposure
- Lakshit Mahajan (linkedin.com/in/lakshit-m-3a781021b) | Outdated dependencies
- Jenish Panchal (linkedin.com/in/jenish-panchal-a82802218) | Security misconfiguration
- Satyam Singh (linkedin.com/in/satyam-singh-893306221) | HTML Injection
- Nikhil Rane (linkedin.com/in/nikhil-rane-31733a217) | HTML Injection
- Rohan Prasad Gupta (linkedin.com/in/rohan-gupta-2209a9190) | Security misconfiguration
- Shubhranshu Gorai (linkedin.com/in/shubhranshu-gorai-a9070b1a7) | Security misconfiguration
- Anonymous | DNS misconfiguration
- Shivam Pravin Khambe (twitter.com/ShivaRa42316756) | XSS vulnerability
- Suraj Satish Kharade (linkedin.com/in/suraj-kharade-17a1561a4) | DNS misconfiguration
- Suraj Satish Kharade (linkedin.com/in/suraj-kharade-17a1561a4) | Security misconfiguration
- Raju Basak (twitter.com/Abhishe74207143) | Security misconfiguration