How best to present a security vulnerability to a web development team in your own company?

Question

Imagine the following scenario:

You work at Big Co. and your coworkers down the hall are on the web development team for Big Co's public blog system, which a lot of Big Co employees and some public people use. The blog system allows any HTML and JavaScript, and you've been told that it was a choice (not by accident) but you aren't sure if they realize the implications of this.

So you want to convince them that this is a bad idea. You write some demonstration code and plant a XSS script in your own blog, and then write some blog posts. Soon after, the head blog admin (down the hall) visits your blog post and the XSS sends his cookies to you. You copy them into your browser and you are now logged in as him.

Okay, now you're logged in as him... And you start realizing that it maybe wasn't such a good idea to go ahead and 'hack' the blog system. But you are a good guy! You don't touch his account after logging into it, and you definitely don't plan on publicizing this weakness; you just maybe want to show them that the public is able to do this, so that they can fix it before someone malicious realizes the same thing!

What is the best course of action from here?

Answer 1

Whenever I've seen a security issue that needed to be addressed by our internal IT team in the past, I simply tell them what the issue is and what can be done to potentially exploit it.

Depending on how sensitive they are and what standing you hold with them/your company, proof-of-concept code may or may not be a good idea. If they have reason to suspect you of using it maliciously, I'd keep it to myself. Otherwise, if they'd appreciate it, share it.

That's about the only sensitive area. Just communicate the issue responsibly in such a way that it's clear that you were simply concerned about security issues and were not looking to exploit them.

Answer 2

Really depends on your position in the company, the nature of the people down the hall, etc. etc....

To present one option:

Walk over to them, describe the threat in abstract terms ("somebody could hijack your cookies, which in turn..."), and ask them if they would like to see a demonstration? If there are big egos in play, and you really want them to fix it, don't talk to the whole team, but just the team head.

If they agree, wait a few hours, and come back logged in as "him", and do something non-destructive but noticeable in the system - you did so with their permission. They will probably be impressed, and see to it that the hole gets fixed.

If they disagree and tell you go away, well, you'll have to weigh your options: Either you take it someplace higher, or you bury it. By mentioning the issue you will have given up all options of sending it in anonymously.

If you can't be 100% sure that everybody in the decision chain is reasonable and totally understands what you're doing, and that it is for the good of the company, I wouldn't do any rogue "hacking" - always talk about it first, especially in a big company environment. This stuff is too easy to misunderstand as malicious on your end - especially if there's someone who will be embarrassed by building this security hole, and would like to put the blame on somebody else.

Answer 3

Everyone's focusing on fixing the web site's problem, and maybe I'm just a little Machiavellian, but I'd also think about making sure my objections were on record in writing; I'd write an email to a few of my superiors.

The last thing you need is the site to be exploited, and the decision maker coming around insisting it was your job (or your buddy's job) to consider that technical aspect, and you finding no one remembers that you spoke up.

Answer 4

I think you've overstepped your role. While XSS vulnerabilities are a serious concern, if you are not in the Information Security role at your organization you really have no business intruding on how the development organization down the hall operates.

There is no such thing as absolute security, but I imagine that the people overseeing the blog project rest easy at night knowing that if any employees misuse the technology they can be tracked through logs and be dealt with accordingly.

If you've writen malicious code "to demostrate this" without their consent, it's a pretty serious action to undertake without approval and I would imagine your superiors would feel the same way.

Answer 5

You have three viable choices:

1. Talk to the web team.

2. Talk to your own boss.

3. Ignore it.

I think I'd go for both 1 and 2.

Answer 6

This is alarming behavior. If they don't understand the most simple of security flaws like XSS then they must be fired. This is not because of a single vulnerability, thats just silly. They should be fired because they don't understand security and I have no doubt that they have introduced for more serous vulnerabilities into the system. If they don't get this text book XSS issue what about CSRF? They are going to think your crazy!

Understanding the security impact of your code is an absolute requirement. Without this then the programmer is only a liability.