About Company
Guiding Principles
Data Security
Careers
Download the app
Faster & complete healthcare experience
Practo for Patients
Practo for Providers
Help
Contact us
Terms of service
About Practo
Guiding Principles
Data Security
Careers
For Patients
For Providers

Responsible Disclosure policy

At Practo, we take safety and security of our customers’ data very seriously and stand guard to the trust put in us by our users.


We understand the importance and value of the role played by security researchers and ethical hackers in keeping the internet safe. Therefore, we support their responsible efforts in not only identifying potential vulnerabilities but also reporting them responsibly.


We urge you to review the Responsible Disclosure Policy before you test and/or report an issue with any of our applications. We assure you that Practo will never pursue any legal action against users who report the issues, as long as they follow these guidelines.


Who can participate in the program?

Anyone who doesn't work for Practo or partners of Practo who reports a unique security issue in scope and does not disclose it to a third party before we have patched and updated will be eligible to take part in this program.

Responsible Disclosure policy:

  • - Report your finding by writing to us directly at secure@practo.com without making any information public.
  • - We will respond as quickly as possible, generally takes 24-48 hours.
  • - In best interest of our customers and their data, please do not publicly disclose the issue until it has been addressed by Practo within a reasonable timeframe.
  • - In order to keep everyone safe, please act in good faith towards our users' privacy and data during your disclosure. We won't take legal action against you or administrative action against your account if you act accordingly.
  • - Make every effort to avoid privacy violations, disruption to production systems, degradation of user experience and destruction of data during security testing. This would include Brute Force, DoS, Spamming, Scraping, Social Engineering etc.

Reporting guidelines

Please include the following information when sending us the details:

  • - Operating System name and version.
  • - Client name and version.
  • - Plugin names and version installed in the client.
  • - Steps necessary to reproduce the vulnerability including any specific settings required to be reproduced (If this contains more than a few steps, please create a video so we can attempt to perform the same steps).
  • - A copy of the source code following your successful test.
  • - What is the impact of the issue.
  • - What are some scenarios where an attacker would be able to leverage this vulnerability?
  • - What would be your suggested fix?

Scope

  • - All subdomains of practo.com i.e. *.practo.com
  • - Practo mobile apps -- Android, iOS

Not in Scope

Phishing attacks

Phishing attacks using social engineering tricks to abuse users such as Self-XSS and Open-redirection. Open-redirection is not considered vulnerable on its own. Google has a more detailed explanation in its bug bounty pages. User education is one of the more effective measures against phishing and we periodically train our employees to detect and avoid phishing attempts.

Wordpress Users Disclosure

Multiple independent researchers have reported this issue to us in the past. If you think https://blog.practo.com/?rest_route=/wp/v2/users/ is vulnerable because it reveals the users, please check out our below explanation:
  1. This doesn't expose any information that is not explicitly intended to be public through the HTML pages. https://www.google.com/search?q=site%3Ablog.practo.com%2Fauthor is the same information that is accessible via the JSON API and exposing the author information is intentional.
  2. The JSON API returns only the slugs of the authors and not the username of all the active WordPress users.
  3. We don't use password-based authentication as you can find out here and hence even if the username is known, there is little that can be done to exploit it.
  4. As an aside, Google mentions "user enumeration" is not a vulnerability that qualifies for their bug bounty program.

Wordpress DoS CVE-2018-6389

Multiple independent researchers have reported this issue to us in the past. Please check out our below explanation on why we think this issue doesn't affect us:
  1. https://blog.practo.com and other WordPress instances of Practo are hosted by a third-party called WPEngine. They take care of maintaining the infrastructure and WordPress updates. Also, since this is separate from the rest of our production infrastructure like https://www.practo.com/, the impact of a Denial of Service is limited to only the blogs and may be other customers of WPEngine.
  2. The above CVE was discussed in WordPress Support forum and this comment by Wordfence plugin developer explains how similar this CVE is to a generic DoS/DDoS attack and any amplification characteristics of this particular endpoint won't matter to the outcome.
  3. So, the right mitigation for all of these DoS/DDoS attack vectors would be to rate-limit the request instead of changing the behavior of the endpoint.
  4. Unfortunately, we cannot use Wordfence plugin because it is disallowed by WPEngine and it says "This duplicates many security as well as caching functions that exist natively in our environment and can cause issues for them".
  5. I have contacted WPEngine support and they have responded saying that they are already aware of the CVE and have "specific mitigations for this issue running here". So, I'm marking the issue as invalid in our internal tracker.

Wordpress CORS in wp-json

Multiple independent researchers have reported that urls like https://help.practo.com/wp-json/oembed/1.0/embed?url=https%3A%2F%2Fhelp.practo.com%2Fsecurity%2Fdata-security-measures%2F&format=xml are CORS enabled and hence can be used to steal session information. Please check out our below explanation on why we think this issue doesn't affect us:
  1. The issue reported is not exploitable as the CORS headers are set only for the specific endpoint which doesn't expose any sensitive data like SID. (Your PoC screenshot doesn't show any SID in the response despite the header saying "Extract SID")
  2. There is a stackexchange q&a for the exact same issue where it was concluded that it is not a security issue.

SPF Misconfiguration

Again we have received multiple reports regarding SPF record being misconfigured. The following is our analysis of the issue, where we stand and how we can improve things:
  1. The misconfiguration(?) in the SPF record is due to the last part of the record (~all) that means all mail that doesn't have a valid SPF source will be marked as 'Soft-fail' and not 'Hard-fail'. In order to hard-fail the mails, the last part of the SPF record should be "-all" instead of "~all".
  2. The behavior of 'Soft-fail' is dependent on the recipient mail provider which has its own complex logic involving heuristics, machine learning and crowd-sourcing to determine whether to mark it as Spam or deliver to inbox. Gmail currently thinks(or you may have marked it as 'Not Spam' to customize your Gmail spam heuristics) that mails sent from emkei.cz's IP are not spam. Email providers are quirky like that and using DMARC is the preferred long-term solution for this.
  3. We have already put DMARC policy in report-only mode for practo.com domain and are currently fixing the SPF and DKIM configuration for legitimate but failing sources.
  4. Once the remaining legitimate sources are whitelisted, we can make the SPF record return a "Hard-fail" as default but more importantly we can enforce DMARC policy and tell Gmail and other complying email providers to definitely block non-whitelisted sources.
  5. As an aside, even gmail.com's SPF server record uses "~all" (soft-fail) instead of the hard-failing "-all" which suggests how less important SPF records are in phishing detection.
  6. Also, we think that phishing emails like these cannot be prevented with measures like SPF or even DMARC since almost nobody verifies the source of the email and the attacker can as well use a domain that has proper SPF and DMARC but is not owned by Practo like practo.xyz or even practa.com. We already train our employees and sometimes our end users to not reveal their credentials like password or OTP to anyone and this is the only feasible way we can protect us and our users from phishing.

Our responsibility

Once we receive the details from you, we will ensure to acknowledge the issue within 24-48 hours. We’ll assess the issue and provide you with an estimated timeframe for addressing the reported vulnerability. We will notify you once the vulnerability is fixed. And last but not least, our gratitude and sincerest thanks to you for helping us keep user data and services safe and secure by featuring you in our security hall of fame 🗗.

Legal terms

By participating in Practo’s Responsible Disclosure program (the “Program”), you acknowledge that you have read and agree to Practo’s Terms of Service as well as the following:

    - Your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.

    - You are solely responsible for any applicable taxes, withholding or otherwise, arising from or relating to your participation in the Program, including from any bounty payments when we run bug bounty programs in the future.

    - Practo reserves the right to terminate or discontinue the Program at its discretion.