4

Currently we use at my workplace svn export <svn_repo>. This takes a long time and I have been playing with the idea to keep the revision history on the production server so we can simply fetch the updates.

In practice I was thinking to have a checkout folder with the code. Once I want to deploy I simply svn up and then copy the contents (without .svn) to a release folder on the same server. Is this safe? The organization I work with works with the government so security is a very big issue.

Johan Hanssen Seferidis
  • 247
  • 1
  • 5
  • Not sure, but as a slight aside: _do not_ put the checkout folder or any .svn folders in the webroot! That is very insecure... – Matthew Feb 05 '16 at 13:51
  • 1
    @drewbenn svn as a tag does not exist and I don't have privileges to add new tags so.. – Johan Hanssen Seferidis Feb 05 '16 at 22:28
  • @JohanHanssenSeferidis I think clarification might be needed here. You tagged with git, but you're using svn, so my post was made based on storing git data. I thought you were mixing up git/svn. Furthermore, it sounds like you're trying to store your files in an svn archive on the production server. Is this correct? It's also possible I missed your point. Please let me know so I can update my post to remove anything irrelevant. – Mark Buffalo Feb 05 '16 at 23:10
  • @drewbenn: also, you can set git to just do a shallow clone, so no full history. – Lie Ryan Feb 06 '16 at 08:23
  • @MarkBuffalo Although my current environment uses SVN I think the general idea regardless using SVN or Git would be far more interesting. Ofcourse if using one or the other has an effect on security then mentioning it would be even more interesting. – Johan Hanssen Seferidis Feb 06 '16 at 10:34

3 Answers3

7

As I read this post, I'm shaking. Probably because I ate way too many carbs after avoiding them for a while, and I'm experiencing a bout of hypoglycemia... but probably because the idea of this genuinely terrifies me.

Remember, this is an Information Security site. Sometimes the answer you get isn't the answer you want.

  1. You claim to be working for the government.
  2. You're using your real name on this website. A little digging shows exactly who your employer is, among other things. Further digging, I'm able to find extra information on other things.
  3. You're thinking of a potentially insecure setup, and this leads me to worry about the fact that you might be able to touch production servers in such a way, and checkout/import from PRODUCTION servers which may have been hit by malware previously.

You might be well-served by visiting a wikipedia article on Operational Security.

Why can this be a problem?

A production environment is usually front-facing, meaning that's what your customers/clients/users will see. Let's assume you have the following environments:

  1. Development
  2. Testing
  3. Production

Checking out the code from production, which could've been modified in the event of a successfully exploited vulnerability - either in your web application(s), or your web server itself - and then debugging it locally, means that you may end up infecting your entire enterprise.

Your development team usually has access to a lot of critical things. Now that you're debugging it locally, you may be able to spread hidden malware across your entire infrastructure! Development, test, production, etc. From there, your attacker can do pretty much anything they want.

You need clear separation of concerns. Putting your repository onto your production server is just asking for trouble. If your production server gets hacked, you may be able to mitigate the damage if it's limited to just itself.

However, as soon as you let it break out of it's little closed environment, you could be in for a world of trouble. Keep in mind, attackers are looking for any tiny thing they can exploit. This is why I genuinely believe you should not put your SVN on your production server.

Example Pwnage Diagram

I made a crappy diagram in MS Paint to explain this better. Assume that once you debug, an infection occurs and starts propagating.

Crappy M. S. Paint diagram of my idea.

Mark Buffalo
  • 22,498
  • 8
  • 74
  • 91
  • 1
    Yup. This. Back-propagation/pivoting from compromised production is a very tangible threat. – Deer Hunter Feb 05 '16 at 21:40
  • 1
    @Mark I agree to your points. However simply because I investigate the potential to refactor the setup doesn't mean that it will be allowed by the higher ranked employees. I am just looking into potential solutions for making development/deployment faster without adding any risks. – Johan Hanssen Seferidis Feb 05 '16 at 21:48
  • 1
    @JohanHanssenSeferidis I'm just pointing out a frightening possibility, not attacking you personally mate! Most attackers *will* assume this. – Mark Buffalo Feb 05 '16 at 21:50
  • @drewbenn I think a clarification from OP is needed here. – Mark Buffalo Feb 05 '16 at 23:02
6

This depends on what you keep in the repository. If this repository only contains the same information which are already at the server then an attacker compromising the server will not gain new information when looking at the repository.

But just imagine that somebody checked in some authorization credentials (i.e password, private key...) or other sensitive non-public information. Even if this was detected and the change reverted and it was never published to the public facing site of the server, it is still inside the repository. And in this case the attacker might gain valuable information which would not be available on the server otherwise.

In summary I would recommend to only store the information on a server that really needs to be there. This means no code repositories and also no tools like compilers or similar. Each of this might help an attacker to compromise the server or to gain additional information.

Once I want to deploy I simply svn up and then copy the contents (without .svn) to a release folder on the same server.

Why not simply sync the data from a local checkout of the repository to the public server? rsync is your friend.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • For me it's a general rule to not put any authentication information under version control. – Koen. Feb 05 '16 at 21:09
0

Capistrano is using a setup like what you describe. But it all comes down to "your security is only as strong as your weakest link".

So if you secure your svn and webserver properly, eg. using ssh key authentication, such a setup should be solid.

And because Capistrano makes use of agent forwarding, there is no authentication information to the SCM server on the webserver.

Koen.
  • 101
  • 3