Skip to main content
Edit incorporating comments.
Source Link
Mike Ounsworth
  • 59.3k
  • 21
  • 162
  • 214

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

It should also be stated here that if you want the company to take you seriously, you need to clearly describe the issue, steps to reproduce, describe how pervasive it is in their application, what damage and attacker could cause with it, and what they should do to fix it. If you just send them the report from a scanner, they will likely ignore you, or worse send a lawyer after you (see below).

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:

Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:

Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

It should also be stated here that if you want the company to take you seriously, you need to clearly describe the issue, steps to reproduce, describe how pervasive it is in their application, what damage and attacker could cause with it, and what they should do to fix it. If you just send them the report from a scanner, they will likely ignore you, or worse send a lawyer after you (see below).

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:

Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

added 1438 characters in body
Source Link
Mike Ounsworth
  • 59.3k
  • 21
  • 162
  • 214

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:

Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:

Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).

Source Link
Mike Ounsworth
  • 59.3k
  • 21
  • 162
  • 214

Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.

Things that are always ok

Use a responsible disclosure process to disclose the finding to the company.

See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt. If not then search around and see if they have a security email address for reporting things like this.

Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.

Things that are sometimes ok

Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).

Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.

Things that are never ok

Hacking the website yourself.

This is undoubtedly illegal in every country that has laws about this.

Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).