How does one securely and privately address security concerns inside code

Question

I recently finished a practicum for which I desperately need a recommendation from. However when I was working on the code for the public face web-portal I noticed many sql injection possibilities and as well as other things.

What bothers me is the complete ignorance of the indevidual managing the code. He wrote much of the code and is completely unaware of what SQL is supposed to be used for. In that manner he also doesn't know how to properly protect against SQL injection and the like. While I was working for the individual I tried to push him in the right direction of looking and seeing how broken the system was. But I really need a good recomendation for a job and didn't wish to upset him. The office is also a very close-knit office and there was no-one I felt would understand the severe need for code review.

Why I feel that this issue must be addressed is because they system was for a School district to manage student records very personal student records. We (the developers including another student) had access to a clone of the live database for testing purposes and there my little brother is set to enroll in that school district next year.

The lead developer is somewhat good at programming but with the lack of understanding regarding SQL and relation databases the system will be exploited and most likely within the next year as it's being rolled out district wide.

I really feel I should have said something to someone. :( Besides phoning up the supervisor and asking him to do something what can I legally do. Can I phone the RCMP (I'm Canadian) and ask them to investigate (I know that's dumb but this is verging on criminal negligence).

Answer 1

I feel that, as a software engineer, you have an ethical responsibility to report security problems to the appropriate people as soon as you know of the problem. The only decision that you have to make is when to report the potential problem, and that depends on how severe the potential problem is and the impact that a breach would have.

When reporting any type of problem, I'm a believer in the chain-of-command. If I were to find a problem, I would report it to my immediate superior and then work up the chain until either I reached a point where bothering the person with the information would not be a benefit (this would be for low severity and low impact problems) or the problem has been appropriately noted, and I would follow up as appropriate to conclusion.

You made a decision to go for a favorable recommendation, and that was your choice. However, in your particular case, I'm not sure it was the right one. Doing the right thing usually takes precedence in my book, even if that means stepping on some toes. When you have sensitive and personal data that can easily be compromised, that's a big deal and, although it might be problematic in the short-term, I think that in the long run, you would be more respected for standing up for the right thing. Even if you aren't, I would suspect that saying something would have let you sleep better at night.

Answer 2

Nothing scares more than a live demo of an exploit. Since you're able to clone the database and I presume the website, why not clone the site on your local machine and demonstrate how a sql inject can be detrimental.

Conduct a live demo for your peers in the office where you hack your site and show them just how dangerous and easy to pull off this form of attack is...

Answer 3

Sometimes companies can be really touchy about security holes. Whatever you do, don't make the information public. RCMP most likely won't do much as they generally don't find security vulnerabilities high on their list of priorities (more in the CSIS domain AFAIK).

Really, IMO you have two courses of action:

1. Keep your mouth shut. If your main objective is to get that letter of recommendation and you think that approaching people with this issue will ruffle feathers to the point that you won't get it, then don't. It's business. You don't owe them anything, just as much as they don't owe you anything. Get what you went there for and don't think twice about it.
2. Think of the most politically correct way to go about introducing the vulnerabilities to the lead. Maybe figure out a way to make it look like you stumbled on the problems accidentally and innocently. Send an e-mail to him, if there's a mailing list on which managers are on, then use that rather than direct e-mail.

Still, no matter how politically correct you go about #2, you may still piss people off ("I can't believe this practicum kid is trying to find holes in my system"), of course, that's all dependent on the type of person the lead is. He very well may appreciate you pointing out the issues and teaching him something (I know I would ;)).

Answer 4

Let's face it, it's a vulnerability. You're done your practicum already. As mentioned earlier, this is not in the juristiction of the RCMP. As only a vulnerability and it is doubtful that there is any direct risk of financials, it rules out only more places to go. The only real authority would be the board of education or school district acting as the customer.

Personally, I'd have a chat with the superintendant of the school district. Let him know about everything that happened and what you've seen. Explain the risks of the software. Also explain the risk to yourself in lettem them know about it.

It sounds as though the customer in this case, should be more than be able to request an external code review (you make it sound as though the development shop was tied to the school in some way). They should also certainly be able to request that those vulnerabilities are removed or mitigated.

Answer 5

This is nuts. You don't go all covert-whistleblower at the first sign of a bug.

You will find thousands of bugs in your career. This is no different. You do what you're supposed to do:

1. Raise a severity 1 ticket in your bug tracker: this could be the equivalent of an e-mail to the lead dev.
2. Provide written repro steps
3. Provide a written unit or integration test to prove and fail on the security flaw
4. If you're feeling up to it, offer to take the bug on yourself.
5. If it's assigned to you: fix it
6. If it's assigned to someone else: drive them to fix it (offer to help, offer a sample, provide the path to your checked in automation)

The point is, be a professional.

Answer 6

Yeah I know you need a good recommendation and all, have you tried talking to the one in charge? It sounds like you haven't even mentioned it for fear of upsetting him/her. Don't demonstrate it as "look I can haxxorz ur code!" as that will probably get you in trouble. If you're afraid of direct confrontation ("there are SQL injection problems in your code, watch this (give demonstration)!"), could you arrange for it to appear as a "bug" during testing?

Here's a question: You are aware of the problem and not doing anything. Would you be liable if this was exploited in the future, and they bring back the former devs to testify and discover that you knew all along about this problem but failed to say anything for fear of upseting management?

Oh yeah, and make sure you document every thing. You want emails showing how you've mentioned this to your manager repeatedly and been shot down. CYA when dealing with this sort of thing.

Answer 7

Security is very important these-days Sony, Citybank and etc. found that out the hard-way.

The best place to start is www.owasp.org (Open Web Application Security Project)

Also I've found some great examples from Troy Hunt, (His a bit of security guru and Microsoft MVP) http://www.troyhunt.com/search/label/OWASP

His examples as a live demo would be perfect, as your not directly pointing out the flaws at work just serious security issues not done well in the industry. Many of these things are very easy to implement, its not rocket science. Its just a few simple things to consider during the design and implementation.