After reading this thread, I don't know who on this site to trust as an actual programmer. I know that anything that Kirby or Paul or Princeston (and a select few others) programs/writes/codes, I would trust, but beyond that, I don't know whether they are some noob/novice that learned how to hack a php script and accidently got it working without any real knowledge of how it works, but released it as a hack/product or whether the individual actually knows php, does it for a living (not a hobby) and cares about the script itself and not the acolades that may or may not come with it....
As a professional programmer and database admin, it disgusts me to see people that call themselves programmers want to keep a known vulnerability from an end user/client. There is NOTHING, not a darn thing positive about this at all and is totally unprofessional. Its your responsibility when you release code to an end user/client to also protect that client from any harm by insuring that your code is to standard and does not have any potentially harmful vulnerabilities. If you don't know what you are doing and don't care, then don't pretend you do by releasing code to the public. Another part of being a programmer is to notify them ASAP of any known or posible vulnerabilities, ensure them that you are currently working on the issue(s), give them recommendations, ie, remove the hack until its fixed, continue to use the hack/code/product but inform them of what may or may not happen,(leave the option to the end user to make the decision to remove it or disable it) and get them the fix ASAP.
Most programmers and end users/clients understand that you don't want to publish what the vulnerability actually is, cause hackers search for that stuff and then can easily do more damage.... But to sit here and argu that withholding information from an end user/client about a vulnerability is good practice is beyond me. Im certainly adding this topic to my hiring check list that I use to interview potential programmers. I have and probably will in the future fire someone over this unprofessional practice. I can not believe what I've read in this thread.
Its too bad that there are not more members that REALLY care (not pretend they do) about their product. Seems like this place is getting over run by novice hackers (I can't and won't call them programmers).
I keep reading comments about the loss of data due to uninstalls, well, that goes back to the programmer getting off his back side and giving the recommendation to the client on how to prevent that from happening while a fix/solution is being worked on. This should be included in the first post when releasing a hack/script/module/product. Anyone that has been a professional programmer knows that IT departments (good ones) have what are called disaster and recovery plans. When you release a product, you also have steps on how to deal with vulnerabilities, data loss prevention, down time, recovery, disabling, removing, etc etc etc ... I can't believe I even have to bring that up.
Recommendations:
I recommend that the wording that is sent out to members that have installed a hack that is found to contain a vunerability be changed slightly (which I think Paul has already mentioned that it would be)....
1) I would not use the word "Uninstall" as the first course of action.
2) I would inform the end user of several courses of action that they can take, not just to uninstall.
3) I would recommend that the end user contact the author of the thread for further guidance by first reading the thread to see if the author has posted how to deal with vulnerabilties or if the author has posted about the reported vulnerability.
4) I would assign one of the staff members to monitor the situation of the vulnerability. This would entale the staff member working with the author to ensure that a solution is being worked on or if the author has no desire come up with a solution. This way the staff member could then tag the thread as being abandon and vBorg could inform members that no solution to the vulnerability is being worked on by the author. They could then choose to fix it themselves giving the members a solution or they could inform the members that nothing will be done and the thread locked. On the other side, they could assist the author if the author requests it.
5) I would recommend that authors include procedures on how to deal with potential vulnerabilities within the release of the product.
6) I would recommend that an article be written by one of your better writers on how to deal with vulnerabilties (to prevent the loss of important data particularly). A link to this article would be included in the email sent to the end users.
5) PLEASE DO NOT stop informing members of vulnerabilties!
Anyway, I hope that the vBorg staff continues to notify members of vulnerabilities of hacks published on this site, cause god knows, some of the authors of these hacks certainly don't care and won't.
|