I am a security member of a small company which recently got contacted by someone claiming to be a Hackenproof member.
They were reporting on our website being indexed by googlebot (metadata, thin page content, anchor text issues) and an XSS vulnerability.

We do not have any legal statement that I know of regarding VDP (vulnerability disclosure policy) yet.

My questions:

1. Basically how to proceed or even should we? (Are they legit?)


2. What is the common expectation from a white hacker?


3. How to validate the vulnerability?

Hackenproof appears to be a website anyone can sign up for, so saying you're a member of Hackproof is equivalent to saying you're a member of Facebook. This is not an exclusive hacker group.

There's no formalized standard way to proceed with such a situation, since your company, your business, the bug, and the white hat are all going to vary greatly. One size doesn't fit all.

In general, it's advisable to be cautious but curious. Be careful, but not paranoid and vindictive. Don't provide any internal information to the white hat, try to get as much information as possible upfront while revealing little or nothing. Many of these people like to talk to show their own expertise. Let them do so. There's little harm that can happen if the information only flows one way. Ask him/her for source code, or a detailed description of the problem. Then analyze the code/description and write your own exploit (and don't compile or run the white hats code), running it against a test instance, preferably as isolated as possible from any other environment.

As far as each parties responsibilities, Most people who claim to be white hat hackers these days will practice responsible disclosure and not release the bug to the world until it can be fixed. Your responsibility is to fix the bug (if it's severe enough) within a reasonable amount of time (several weeks, not years). If your company offers bounties, they should be paid if the bug meets the criteria. If not, the white hat should accept that they likely won't be paid, but you have to accept that they might release the bug to the general public if it's not fixed in a reasonable amount of time.

I don't know that there are any hard-and-fast rules here. Let's treat this as game-theory:

What the researcher wants

Usually:

• Public credit for the discovery, such as a CVE or a research paper.


• Sometimes money in the form of a bug bounty.

What you want

Usually:

• Not to be publicly humiliated.


• To improve the security of your product.

How to proceed

From a game-theory perspective, the win-win situation is for them to disclose the details to you, for you to fix it, and for them to get their public credit. You should set up a phone call with the researcher and ask for a demo -- you stand to gain a lot and stand to lose nothing. Be aware that before they're willing to show you the details, the researcher may want an NDA or some other legal contract ensuring that they get their credit at the end.

To answer each of your questions:

1. Basically how to proceed or even should we?

I recommend proceeding. You will be able to acquire valuable information that can immediately be put towards improving the security of your company. You haven't told us what the researcher has sent you, but they will either have a description of the vulnerability or methods to reproduce it. To proceed you will need from them:

• A description/attack scenario of the vulnerability found. Why is this an issue, what specifically does the bug allow an attacker to do that they shouldn't be able to do, what is the worst case scenario/severity of the finding.




• Reproduction steps. What steps could you give any engineer and allow them to reproduce the bug every time.




• What the hacker is looking for in return. As mentioned it may be permission to publish the finding after fixing or money.




• You might also want or receive remediation advice, risk scores, etc. from the researcher.

VERY IMPORTANT: make it clear to the researcher that you expect them to keep the issue confidential until the issue is fixed. They may counter with a remediation window, e.g. they get to publish and article if the issue is not fixed within 60 days. This is common practice and should be acceptable to most companies with a strong security posture.

2. What is the common expectation from a white hacker?

Depends on the researcher, but they will likely want permission to publish the finding once it's been fixed as well as a monetary reward. Reward prices are based on overall severity and size of the bounty program. Hackerone, a large bug bounty platform, has a matrix that suggests payouts relative to size of the company/bounty program: https://www.hackerone.com/resources/bug-bounty-basics. Determining payout price is a subtle art - I recommend searching hackerone or other bug bounty platforms for similar bugs and basing your payout on what other companies are paying for the same issue.

Again - a common expectation researchers will have is that they get to publish the finding in a certain amount of time regardless of whether it's been fixed by then. 60 days is common, but I wouldn't agree to an amount of time if you're not confident your company can deliver in that window. After the issue is patched, the hacker may want to validate that the fix was implemented correctly.

3. How to validate?

Use the reproduction steps the hacker has given you. They should be clear enough that any engineer can follow the steps exactly and reproduce the bug. If there are any issues here you can go back to the researcher and get clarification. It is the researchers responsibility to supply the company with reproduction steps that outline and identify the bug.

Once the issue is fixed you can invite the researcher to validate the fix and ensure that it was patched completely.