Rules of Disclosure - a must read.

Discussion in 'Programming' started by vishal sharma, Jan 17, 2007.

  1. vishal sharma

    vishal sharma New Member

    Joined:
    Jul 23, 2004
    Messages:
    106
    Likes Received:
    6
    Trophy Points:
    0
    As I was going Through some of the codes in this section, I saw some faulty codes and some suggestions regarding them. Here is a guide to point out the mistakes by the coder in a proper way. If you ever find a bug/vulnerability/hole/flaw in someone's code, here's how you should go about reporting it:

    1. First and foremost, before posting the problem or an exploit for the problem to a public place, contact the developer. Give them a chance to fix it before you give the world a chance to exploit it.

    2. Give the author as much information as possible, including where it is in the code (ex. line number), how you found it (Did you use any tools or receive an error when executing it?), how someone might exploit it(in code or in theory), and how to fix it (new techniques, disabling useless features, alternate syntax, etc.).

    3. Let's face it: it's not with open arms that we greet the news that our code isn't perfect. Therefore, try to be as kind as you can when telling the producer of the faulty code that there is a problem with it and, hopefully they will respect your and your concerns.

    4. Explain to the developer the importance of fixing bugs. Let him know about some possible security breaches that might result in lost data or a decrease in the privacy of users.

    5. Help the author fix the code if asked to do so. This will result in cleaner code at a quicker pace and it will cause the developer to welcome and thank people reporting errors in the future.

    6. If the producer of the code refuses to fix it, advise him to alert his users that the software they're using is insecure/partially inoperable.

    7. If developer refuses to inform his constituents of the problem, inform them yourself, tell them why it is important, and recommend alternative methods of accomplishing whatever the code is supposed to do (ex. other software they can use). Although it may be frustrating, try not to be malicious when doing so.

    8. Be wary when making an exploit for the faulty code. Only do so when the author must see that it is really a problem before he agrees to fix it; never use/release an exploit as a first step, if he is working on a fix, or has promised to begin fixing the problem.

    9. Test the code once it's been "fixed" to make sure it's not still vulnerable. Let the producer know if it's okay or if it's still problematic.

    10. Once the new code works and you have permission from the author, let the world know about the problem. Who knows how many other blocks of code out there may be susceptible to the same thing?

    "Ethics" is the word only White-Hats respect, so be one of them.....
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice