views:

248

answers:

1

We have a tech support website/database at work that we use to record our interactions with customers. Our tech support people are not capable of creating their own accounts. We also use Mantis on the same server as a way to keep track of bugs.

Inside the tech support site we would like to have a link to Mantis so that our tech support people can quickly enter a bug report. Quickly, meaning that the tech support person shouldn't have to login to Mantis after they click the link.

So we are calling a modified authentication function within Mantis from our tech support site that checks for the user name, and if it exists automatically logs the user into Mantis. No password check, because we were in a big rush with a lot of more important things going on.

Is this a security risk?

+3  A: 

Is this a risk? Yes, but there may be mitigating factors.

  1. Is the check performed from server to server interaction or is client side javascript making the call? If server to server, that lowers the risk a little.

  2. Is mantis publicly facing or completely internal? If internal, then this limits scope to internal users only.

  3. If all of the bug information was "leaked" to the internet, does that have potential consequences to your employer? This is the harder one. Also, this one has to be weighed against the access already provided to the techs.

  4. What is the maximum potential for damage? In other words, let's assume that one of your support techs is pissed off and decides to take a shot at the company systems.

What could they do?

Mantis simply stores bug tracking information. Further, if your server is backed up nightly then you are limited to the potential defacing of one days worth of bugs. Hardly worthwhile from a hacker perspective, and of no real consequence to the company.

The amount of security used should be commensurate with what it is defending.

Chris Lively
<nitpick>I think you meant *commensurate* (proportional), not *commiserate* (a feeling of sympathy and sorrow for the misfortunes of others).<nitpick>On the other hand, you may have a point there ;)</nitpick></nitpick>
Piskvor
Thanks for the response.1) No javascript in use. It's just one php script calling another on the same box (VM).2) Publicly facing.3) This is a commercial product, so bad publicity is bad.4) This is a good point. The max possible damage is actually pretty small.
daharon
@Piskvor: thanks.
Chris Lively