How to proceed with a white-hat hacker claiming a vulnerability?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












81















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?









share|improve this question



















  • 16





    according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

    – kkarakk
    Feb 14 at 7:17







  • 3





    The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

    – Bakudan
    Feb 14 at 11:05






  • 45





    Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

    – Harper
    Feb 14 at 18:25







  • 5





    Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

    – Cubic
    Feb 15 at 12:28






  • 8





    Whatever you do, please don't pull an Oracle and try to sue the white hat.

    – zero298
    Feb 15 at 19:18















81















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?









share|improve this question



















  • 16





    according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

    – kkarakk
    Feb 14 at 7:17







  • 3





    The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

    – Bakudan
    Feb 14 at 11:05






  • 45





    Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

    – Harper
    Feb 14 at 18:25







  • 5





    Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

    – Cubic
    Feb 15 at 12:28






  • 8





    Whatever you do, please don't pull an Oracle and try to sue the white hat.

    – zero298
    Feb 15 at 19:18













81












81








81


19






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?









share|improve this question
















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?






disclosure bug-bounty white-hat






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 13 at 22:52









Anders

49.4k22143163




49.4k22143163










asked Feb 13 at 19:59









VcodeVcode

581128




581128







  • 16





    according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

    – kkarakk
    Feb 14 at 7:17







  • 3





    The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

    – Bakudan
    Feb 14 at 11:05






  • 45





    Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

    – Harper
    Feb 14 at 18:25







  • 5





    Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

    – Cubic
    Feb 15 at 12:28






  • 8





    Whatever you do, please don't pull an Oracle and try to sue the white hat.

    – zero298
    Feb 15 at 19:18












  • 16





    according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

    – kkarakk
    Feb 14 at 7:17







  • 3





    The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

    – Bakudan
    Feb 14 at 11:05






  • 45





    Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

    – Harper
    Feb 14 at 18:25







  • 5





    Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

    – Cubic
    Feb 15 at 12:28






  • 8





    Whatever you do, please don't pull an Oracle and try to sue the white hat.

    – zero298
    Feb 15 at 19:18







16




16





according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

– kkarakk
Feb 14 at 7:17






according to hackenproof.com/#how-it - "Vulnerabilities are submitted and managed via our Coordination platform." are you sure you weren't contacted by hackenproof themselves? their whole business model is to create bug bounty programs for companies like yours that don't really have a security focus. their "members" just compete for bug bounties, they don't contact companies themselves.if it isn't the company then someone seems to be social engineering you

– kkarakk
Feb 14 at 7:17





3




3





The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

– Bakudan
Feb 14 at 11:05





The least you can do is notify the responsible for the security in your company that you've been contacted and told about an xss vulnerability. The part about not revealing information is a common sense.

– Bakudan
Feb 14 at 11:05




45




45





Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

– Harper
Feb 14 at 18:25






Possibly related: [Our office is on fire. We don't have a Fire Response Policy yet. Should we stay put, or write one in a hurry, which is less than ideal obviously?](

– Harper
Feb 14 at 18:25





5




5





Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

– Cubic
Feb 15 at 12:28





Note that under the GDPR you are required to notify the relevant authorities within 72 hours of a data breach. May not apply to you if you don't have any EU customers, but if you do you'll want to get started on that yesterday.

– Cubic
Feb 15 at 12:28




8




8





Whatever you do, please don't pull an Oracle and try to sue the white hat.

– zero298
Feb 15 at 19:18





Whatever you do, please don't pull an Oracle and try to sue the white hat.

– zero298
Feb 15 at 19:18










5 Answers
5






active

oldest

votes


















64














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 (hat) 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.






share|improve this answer




















  • 7





    Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

    – Buffalo5ix
    Feb 13 at 22:00






  • 33





    +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

    – Steve Sether
    Feb 14 at 4:03







  • 14





    @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

    – tim
    Feb 14 at 20:57






  • 7





    @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

    – Ajedi32
    Feb 15 at 19:48







  • 2





    @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

    – Graham
    Feb 19 at 8:16


















60














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.






share|improve this answer


















  • 53





    "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

    – jpmc26
    Feb 14 at 0:59







  • 7





    @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

    – Steve Sether
    Feb 14 at 3:26






  • 7





    I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

    – jpmc26
    Feb 14 at 5:00


















49














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.






share|improve this answer






























    1














    I might be worth noting they are likely pretty new to this too, there are plenty of 'pros' and if that's how you make a living, you likely have a process, but that normally involves some agreement with a company before you start the work. But even then it varies between companies and the sort of job.



    This sounds to me like an enthusiast to me though. I really doubt there is anything to lose from talking to the guy. He may have unrealistic expectations but what do you lose?



    Side note, sorry if this patronising, but I feel it must be said: It's at least conceivable this is intended to be a way in to you being 'had', "can we have a quick chat about some of the implementation details of your system" is something you should probably say 'no' to, even especially if they come offering a carrot.






    share|improve this answer






























      0














      To echo what someone said in a comment, it would be a fair thing to do to try and rule out a scam or extortion. Here's a few things to consider.



      • Is there any mention of payment at all in response for information - even some kind of "administrative fee"? Assuming you have no pre-existing bug bounty, a legitimate researcher is not likely to ask for money - they want the bug fixed and the ability to get credit for finding it. Asking for money could be seen as an extortion attempt or at best unethical.


      • Are the steps to reproduce vague enough that they could not help you reproduce them? Have your engineers investigate them early to know exactly what you have and verify that there is a vulnerability, even if minor. Are they being a little reluctant to give details even though you are following the normal practices? If no matter what you do, the vulnerability remains vague and unconfirmed, you may not be dealing with a legitimate report.


      • Do they seem overly eager to know information about how your software works or even information about your company or business?


      • If the person claims to represent some group, can you verify they actually do?


      The normal way to proceed would be to assure the reporter that you are committed to fix the bug, give a time frame for shipping the fix (they may have already specified a time frame they want, but if that seems unreasonable, negotiate) after which they can publish. Or, see if you can ask for a grace period afterwards in case they re-test and find the vulnerability still exists in some form.



      Giving money in reward is a bit of an ethical dilemma, on the one hand it is good to reward but on the other hand if you don't have a bug bounty it risks encouraging the practice of finding vulnerabilities and expecting payouts, which comes close to black hat behavior. Again, be wary if they brought up the issue of money first, even if you do intend to give some. But if you do, it would be better for all if you set up some sort of formal bug bounty program.






      share|improve this answer






















        Your Answer








        StackExchange.ready(function()
        var channelOptions =
        tags: "".split(" "),
        id: "162"
        ;
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function()
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled)
        StackExchange.using("snippets", function()
        createEditor();
        );

        else
        createEditor();

        );

        function createEditor()
        StackExchange.prepareEditor(
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader:
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        ,
        noCode: true, onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        );



        );













        draft saved

        draft discarded


















        StackExchange.ready(
        function ()
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203521%2fhow-to-proceed-with-a-white-hat-hacker-claiming-a-vulnerability%23new-answer', 'question_page');

        );

        Post as a guest















        Required, but never shown

























        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        64














        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 (hat) 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.






        share|improve this answer




















        • 7





          Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

          – Buffalo5ix
          Feb 13 at 22:00






        • 33





          +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

          – Steve Sether
          Feb 14 at 4:03







        • 14





          @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

          – tim
          Feb 14 at 20:57






        • 7





          @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

          – Ajedi32
          Feb 15 at 19:48







        • 2





          @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

          – Graham
          Feb 19 at 8:16















        64














        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 (hat) 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.






        share|improve this answer




















        • 7





          Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

          – Buffalo5ix
          Feb 13 at 22:00






        • 33





          +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

          – Steve Sether
          Feb 14 at 4:03







        • 14





          @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

          – tim
          Feb 14 at 20:57






        • 7





          @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

          – Ajedi32
          Feb 15 at 19:48







        • 2





          @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

          – Graham
          Feb 19 at 8:16













        64












        64








        64







        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 (hat) 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.






        share|improve this answer















        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 (hat) 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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Feb 14 at 16:58

























        answered Feb 13 at 21:19









        Buffalo5ixBuffalo5ix

        1,337515




        1,337515







        • 7





          Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

          – Buffalo5ix
          Feb 13 at 22:00






        • 33





          +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

          – Steve Sether
          Feb 14 at 4:03







        • 14





          @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

          – tim
          Feb 14 at 20:57






        • 7





          @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

          – Ajedi32
          Feb 15 at 19:48







        • 2





          @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

          – Graham
          Feb 19 at 8:16












        • 7





          Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

          – Buffalo5ix
          Feb 13 at 22:00






        • 33





          +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

          – Steve Sether
          Feb 14 at 4:03







        • 14





          @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

          – tim
          Feb 14 at 20:57






        • 7





          @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

          – Ajedi32
          Feb 15 at 19:48







        • 2





          @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

          – Graham
          Feb 19 at 8:16







        7




        7





        Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

        – Buffalo5ix
        Feb 13 at 22:00





        Thanks for the context! XSS can vary in severity, if they can truly perform unauthorized payment transactions like they say then it is certainly a critical issue. Of course make sure to validate this claim! It's very difficult to talk numbers without a sense of how big your company or security team is - I would consider anything less than $3,000 an insultingly low payout assuming you can really leverage this XSS to drain funds. Otherwise, figure out what the worst thing you can do with this attack is, anywhere from $500-$3000 would be typical for XSS.

        – Buffalo5ix
        Feb 13 at 22:00




        33




        33





        +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

        – Steve Sether
        Feb 14 at 4:03






        +1, good answer. One small critique. Unless a bug bounty has already been established, I don't think you should pay one, even if demanded. This changes the relationship from a social contract into a market contract. Social contracts generally provide more value than market ones and work well for smaller companies since they can maintain social contracts far more easily than large companies can. If you turn it into money, it's a different ballgame entirely. Giving credit where credit is due is more in line with the social contract.

        – Steve Sether
        Feb 14 at 4:03





        14




        14





        @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

        – tim
        Feb 14 at 20:57





        @Buffalo5ix I think the problem is that your answer is framing it as an expectation. Personally, if no bug bounty program is established, my expectation is that the bug is fixed in a timely manner and that I can publish it. I'm not expecting money (and I certainly woudn't demand it, because of the ethical and legal implications). I would frame it as a an optional action that could be used to build good will, instead of an expectation that needs to be met.

        – tim
        Feb 14 at 20:57




        7




        7





        @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

        – Ajedi32
        Feb 15 at 19:48






        @Damon Becoming aware of vulnerabilities in a website (even a website capable of initiating payment transactions) isn't a crime. You don't need to actually carry out an attack to know that it is possible.

        – Ajedi32
        Feb 15 at 19:48





        2




        2





        @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

        – Graham
        Feb 19 at 8:16





        @SteveSether The answer does expect a significant input in time and effort from the bug reporter. Granted there are people who do this just for the recognition, but if you expect them to take a professional attitude to this then it's only fair that the company also takes a professional attitude. Which, like every other subcontracted specialist work, deserves payment in exchange for expertise and time.

        – Graham
        Feb 19 at 8:16













        60














        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.






        share|improve this answer


















        • 53





          "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

          – jpmc26
          Feb 14 at 0:59







        • 7





          @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

          – Steve Sether
          Feb 14 at 3:26






        • 7





          I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

          – jpmc26
          Feb 14 at 5:00















        60














        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.






        share|improve this answer


















        • 53





          "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

          – jpmc26
          Feb 14 at 0:59







        • 7





          @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

          – Steve Sether
          Feb 14 at 3:26






        • 7





          I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

          – jpmc26
          Feb 14 at 5:00













        60












        60








        60







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 13 at 20:50









        Steve SetherSteve Sether

        17.5k63666




        17.5k63666







        • 53





          "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

          – jpmc26
          Feb 14 at 0:59







        • 7





          @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

          – Steve Sether
          Feb 14 at 3:26






        • 7





          I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

          – jpmc26
          Feb 14 at 5:00












        • 53





          "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

          – jpmc26
          Feb 14 at 0:59







        • 7





          @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

          – Steve Sether
          Feb 14 at 3:26






        • 7





          I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

          – jpmc26
          Feb 14 at 5:00







        53




        53





        "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

        – jpmc26
        Feb 14 at 0:59






        "try to get as much information as possible upfront while revealing little or nothing." Easy way to do this: "Thanks for alerting us! Could you provide steps to reproduce?" Reveals nothing, promises nothing, asks for all the info you need. I wouldn't even ask for source code unless absolutely necessary, given that you won't want to execute it.

        – jpmc26
        Feb 14 at 0:59





        7




        7





        @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

        – Steve Sether
        Feb 14 at 3:26





        @jpmc26 I think asking for source code separates the pretenders and probers from the real white hats. Some people might just wasting your time, and source code gets down to the brass tacks.

        – Steve Sether
        Feb 14 at 3:26




        7




        7





        I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

        – jpmc26
        Feb 14 at 5:00





        I am fairly certain that providing legitimate steps to reproduce would be equally difficult if they haven't actually found a vulnerability. If it really is complicated enough to necessitate source code, someone legitimate would probably just provide it when asked for the steps, or at least offer to provide it.

        – jpmc26
        Feb 14 at 5:00











        49














        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.






        share|improve this answer



























          49














          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.






          share|improve this answer

























            49












            49








            49







            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Feb 13 at 20:52









            Mike OunsworthMike Ounsworth

            40k1595141




            40k1595141





















                1














                I might be worth noting they are likely pretty new to this too, there are plenty of 'pros' and if that's how you make a living, you likely have a process, but that normally involves some agreement with a company before you start the work. But even then it varies between companies and the sort of job.



                This sounds to me like an enthusiast to me though. I really doubt there is anything to lose from talking to the guy. He may have unrealistic expectations but what do you lose?



                Side note, sorry if this patronising, but I feel it must be said: It's at least conceivable this is intended to be a way in to you being 'had', "can we have a quick chat about some of the implementation details of your system" is something you should probably say 'no' to, even especially if they come offering a carrot.






                share|improve this answer



























                  1














                  I might be worth noting they are likely pretty new to this too, there are plenty of 'pros' and if that's how you make a living, you likely have a process, but that normally involves some agreement with a company before you start the work. But even then it varies between companies and the sort of job.



                  This sounds to me like an enthusiast to me though. I really doubt there is anything to lose from talking to the guy. He may have unrealistic expectations but what do you lose?



                  Side note, sorry if this patronising, but I feel it must be said: It's at least conceivable this is intended to be a way in to you being 'had', "can we have a quick chat about some of the implementation details of your system" is something you should probably say 'no' to, even especially if they come offering a carrot.






                  share|improve this answer

























                    1












                    1








                    1







                    I might be worth noting they are likely pretty new to this too, there are plenty of 'pros' and if that's how you make a living, you likely have a process, but that normally involves some agreement with a company before you start the work. But even then it varies between companies and the sort of job.



                    This sounds to me like an enthusiast to me though. I really doubt there is anything to lose from talking to the guy. He may have unrealistic expectations but what do you lose?



                    Side note, sorry if this patronising, but I feel it must be said: It's at least conceivable this is intended to be a way in to you being 'had', "can we have a quick chat about some of the implementation details of your system" is something you should probably say 'no' to, even especially if they come offering a carrot.






                    share|improve this answer













                    I might be worth noting they are likely pretty new to this too, there are plenty of 'pros' and if that's how you make a living, you likely have a process, but that normally involves some agreement with a company before you start the work. But even then it varies between companies and the sort of job.



                    This sounds to me like an enthusiast to me though. I really doubt there is anything to lose from talking to the guy. He may have unrealistic expectations but what do you lose?



                    Side note, sorry if this patronising, but I feel it must be said: It's at least conceivable this is intended to be a way in to you being 'had', "can we have a quick chat about some of the implementation details of your system" is something you should probably say 'no' to, even especially if they come offering a carrot.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Feb 15 at 11:03









                    ANoneANone

                    1812




                    1812





















                        0














                        To echo what someone said in a comment, it would be a fair thing to do to try and rule out a scam or extortion. Here's a few things to consider.



                        • Is there any mention of payment at all in response for information - even some kind of "administrative fee"? Assuming you have no pre-existing bug bounty, a legitimate researcher is not likely to ask for money - they want the bug fixed and the ability to get credit for finding it. Asking for money could be seen as an extortion attempt or at best unethical.


                        • Are the steps to reproduce vague enough that they could not help you reproduce them? Have your engineers investigate them early to know exactly what you have and verify that there is a vulnerability, even if minor. Are they being a little reluctant to give details even though you are following the normal practices? If no matter what you do, the vulnerability remains vague and unconfirmed, you may not be dealing with a legitimate report.


                        • Do they seem overly eager to know information about how your software works or even information about your company or business?


                        • If the person claims to represent some group, can you verify they actually do?


                        The normal way to proceed would be to assure the reporter that you are committed to fix the bug, give a time frame for shipping the fix (they may have already specified a time frame they want, but if that seems unreasonable, negotiate) after which they can publish. Or, see if you can ask for a grace period afterwards in case they re-test and find the vulnerability still exists in some form.



                        Giving money in reward is a bit of an ethical dilemma, on the one hand it is good to reward but on the other hand if you don't have a bug bounty it risks encouraging the practice of finding vulnerabilities and expecting payouts, which comes close to black hat behavior. Again, be wary if they brought up the issue of money first, even if you do intend to give some. But if you do, it would be better for all if you set up some sort of formal bug bounty program.






                        share|improve this answer



























                          0














                          To echo what someone said in a comment, it would be a fair thing to do to try and rule out a scam or extortion. Here's a few things to consider.



                          • Is there any mention of payment at all in response for information - even some kind of "administrative fee"? Assuming you have no pre-existing bug bounty, a legitimate researcher is not likely to ask for money - they want the bug fixed and the ability to get credit for finding it. Asking for money could be seen as an extortion attempt or at best unethical.


                          • Are the steps to reproduce vague enough that they could not help you reproduce them? Have your engineers investigate them early to know exactly what you have and verify that there is a vulnerability, even if minor. Are they being a little reluctant to give details even though you are following the normal practices? If no matter what you do, the vulnerability remains vague and unconfirmed, you may not be dealing with a legitimate report.


                          • Do they seem overly eager to know information about how your software works or even information about your company or business?


                          • If the person claims to represent some group, can you verify they actually do?


                          The normal way to proceed would be to assure the reporter that you are committed to fix the bug, give a time frame for shipping the fix (they may have already specified a time frame they want, but if that seems unreasonable, negotiate) after which they can publish. Or, see if you can ask for a grace period afterwards in case they re-test and find the vulnerability still exists in some form.



                          Giving money in reward is a bit of an ethical dilemma, on the one hand it is good to reward but on the other hand if you don't have a bug bounty it risks encouraging the practice of finding vulnerabilities and expecting payouts, which comes close to black hat behavior. Again, be wary if they brought up the issue of money first, even if you do intend to give some. But if you do, it would be better for all if you set up some sort of formal bug bounty program.






                          share|improve this answer

























                            0












                            0








                            0







                            To echo what someone said in a comment, it would be a fair thing to do to try and rule out a scam or extortion. Here's a few things to consider.



                            • Is there any mention of payment at all in response for information - even some kind of "administrative fee"? Assuming you have no pre-existing bug bounty, a legitimate researcher is not likely to ask for money - they want the bug fixed and the ability to get credit for finding it. Asking for money could be seen as an extortion attempt or at best unethical.


                            • Are the steps to reproduce vague enough that they could not help you reproduce them? Have your engineers investigate them early to know exactly what you have and verify that there is a vulnerability, even if minor. Are they being a little reluctant to give details even though you are following the normal practices? If no matter what you do, the vulnerability remains vague and unconfirmed, you may not be dealing with a legitimate report.


                            • Do they seem overly eager to know information about how your software works or even information about your company or business?


                            • If the person claims to represent some group, can you verify they actually do?


                            The normal way to proceed would be to assure the reporter that you are committed to fix the bug, give a time frame for shipping the fix (they may have already specified a time frame they want, but if that seems unreasonable, negotiate) after which they can publish. Or, see if you can ask for a grace period afterwards in case they re-test and find the vulnerability still exists in some form.



                            Giving money in reward is a bit of an ethical dilemma, on the one hand it is good to reward but on the other hand if you don't have a bug bounty it risks encouraging the practice of finding vulnerabilities and expecting payouts, which comes close to black hat behavior. Again, be wary if they brought up the issue of money first, even if you do intend to give some. But if you do, it would be better for all if you set up some sort of formal bug bounty program.






                            share|improve this answer













                            To echo what someone said in a comment, it would be a fair thing to do to try and rule out a scam or extortion. Here's a few things to consider.



                            • Is there any mention of payment at all in response for information - even some kind of "administrative fee"? Assuming you have no pre-existing bug bounty, a legitimate researcher is not likely to ask for money - they want the bug fixed and the ability to get credit for finding it. Asking for money could be seen as an extortion attempt or at best unethical.


                            • Are the steps to reproduce vague enough that they could not help you reproduce them? Have your engineers investigate them early to know exactly what you have and verify that there is a vulnerability, even if minor. Are they being a little reluctant to give details even though you are following the normal practices? If no matter what you do, the vulnerability remains vague and unconfirmed, you may not be dealing with a legitimate report.


                            • Do they seem overly eager to know information about how your software works or even information about your company or business?


                            • If the person claims to represent some group, can you verify they actually do?


                            The normal way to proceed would be to assure the reporter that you are committed to fix the bug, give a time frame for shipping the fix (they may have already specified a time frame they want, but if that seems unreasonable, negotiate) after which they can publish. Or, see if you can ask for a grace period afterwards in case they re-test and find the vulnerability still exists in some form.



                            Giving money in reward is a bit of an ethical dilemma, on the one hand it is good to reward but on the other hand if you don't have a bug bounty it risks encouraging the practice of finding vulnerabilities and expecting payouts, which comes close to black hat behavior. Again, be wary if they brought up the issue of money first, even if you do intend to give some. But if you do, it would be better for all if you set up some sort of formal bug bounty program.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered Feb 18 at 1:12









                            thomasrutterthomasrutter

                            1,186913




                            1,186913



























                                draft saved

                                draft discarded
















































                                Thanks for contributing an answer to Information Security Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid


                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.

                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function ()
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f203521%2fhow-to-proceed-with-a-white-hat-hacker-claiming-a-vulnerability%23new-answer', 'question_page');

                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown






                                Popular posts from this blog

                                How to check contact read email or not when send email to Individual?

                                Displaying single band from multi-band raster using QGIS

                                How many registers does an x86_64 CPU actually have?