Ask HN: Can Jasmine Unit Tests Expose Security Vulnerabilities on Server?

[jbrowne]

Scenario: I'd like to set up Jasmine-standalone-2.0.0 front-end unit testing on the development server where I work. I'm a full stack dev but mostly front-end. I'll admit I'm not super security savvy. A system admin is concerned that there will be security implications from 1. the Jasmine framework library being housed within the directory structure of a site build and 2. that having Some-SpecRunner.html files accessible by a browser could have security implications.Is anyone aware of security issues/vulnerabilities associated with the Jasmine Unit Testing Framework on dev servers or production servers? And if so any suggestions on how to best set Jasmine up to allay these concerns? Thanks HN!

[adambd]

If I understand correctly what your question is, it shouldn't be a problem. Since your JavaScript - which you are testing - is publicly accessible, the tests shouldn't do any harm. They cannot do anythin, what the users couldn't do anyways.

What can be a problem: if you produce sample data during running the tests, you are going to produce a lot of trash data in your production environment. But you shouldn't do it anyway - just mock AJAX calls and so on.

[jbrowne]

Thanks for responding - that's my understanding too. Though if there's something I'm not aware of, I'd love to know!

Thanks for raising the trash data issue. The framework does a pretty good job of set up and tear down before and after each test is run, so I'm not too concerned about the trash data as it's destroyed once the test has completed. (If I'm understanding your point correctly?)

[adambd]

I mean something like you call a REST API where you create fake data which is then visible on the production site. To avoid this, you should mock AJAX calls.

[jbrowne]

Got it - thanks!

[wpietri]

I'm not quite understanding the problem.

Normally, I run unit tests on my dev box; presumably your sysadmins don't care about that. I also run them on a special-purpose CI server. None of these machines are accessible to the outside world. I would never put the the unit test code in a place where it could be triggered by regular users or the general public.

Is that how you're setting it up? If so, what is the sysadmin worried about?

[jbrowne]

Thanks for responding! Currently running Jasmine on local dev box, yes that's cool, sysadmin not concerned about that.

We don't have CI server. We have a dev server that is currently exposed to the world, our production server is separate. If Jasmine installed on the dev server a SpecRunner.html that triggers the unit tests on that dev server could be accessed by anyone if they knew the url.

This is what the sysadmin is concerned about. Would you say it's best to either 1. just run the unit tests locally as we don't have CI server set up or 2. Hide our dev server from the outside world and then it would be ok to run the unit tests on it?

Hope that helps to clarify?

[barylen]

Your dev server shouldn't be accessible to the public. If you want a server to be accessible to the public that isn't your production server (which is valid), you should be doing things as similar to production as possible (not running tests on it).

[jbrowne]

Thanks barylen for the response! Totally get what you're saying, could you expand a bit on why?

[wpietri]

I agree with barylen. Dev should never be visible. For the general reason that the default is "hidden". You make specific exceptions for the small number of things you want people to see.

There are a lot of reasons for that, but for me the two big reasons are good user experience and good security. You get a good user experience by carefully controlling what people see and making sure that's polished. You don't want to have to think about them stumbling across things that aren't for them. And good security requires minimal attack surface. You don't give naughty people anything to abuse that you don't have to.

[jbrowne]

That all stands to reason, thanks for the input wpietri.

[staunch]

You shouldn't be unit testing on production. You should run as little as possible in prod.

[jbrowne]

Thanks for responding staunch! Is that mainly to avoid performance costs/clutter, or for security reasons or both?

[staunch]

You're increasing risk for little benefit. A Javascript unit testing framework could likely be used for crafting XSS exploits. Or it could end up slowing down real users when you forget to turn it off (or whatever). Probably nothing bad will happen but it's a needless risk and a bad practice.

[jbrowne]

Ok, got it - makes sense. Thanks for the input staunch, much appreciated.