1

What are the security concerns of the following scenario? (this is one of those crazy ideas that someone will try, and maybe a it's a good idea, and maybe it's a terrible idea...)

You have Rails app at example.com, and an action at https://example.com/admin/update_app

This action has the following requirements:

  1. It requires https (and redirects if not on https)
  2. It requires admin access
  3. The action displays a page with a form that says "Repository password: [ ]"
  4. This field is filtered out of the server logs, the same way that authentication to the site is filtered out, via the log filtering mechanism in Rails (i.e. this method)

This action does the following

  1. You put your code repository password in the field and hit "Submit"
  2. The action starts a shell script which pulls the latest updates from the stable branch of your code repository, and applies them to the site (unless repository authentication fails, in which case it stops all further steps)
  3. The web server is restarted
  4. An email is sent to the admin saying something simple like, "App update complete"
jefflunt
  • 33,527
  • 7
  • 88
  • 126
  • 1
    This reads like an inverted reinvention of Continuous Integration/Deployment, or, in certain circles, an "[XY Problem](http://www.perlmonks.org/index.pl?node_id=542341)." – Eric Feb 13 '11 at 17:21

2 Answers2

1

Well, this all remind me re-invented capistrano deploy on server through git repository.

Only problem that: 1) what if it will be conflicts during merge(point 2)? 2) what if webserver will not restart correctly(point 3)? 3) What if branch in your repository is not so stable(point 2)?

Sergey
  • 785
  • 1
  • 5
  • 14
  • So, you'd say (1) don't reinvent what Capistrano already doesn, and (2) what's the point of this method if, when something breaks, you're going to have to get more down and dirty into the problem anyway? Yeah, I know all that - I which is why I'm specifically asking about the security stuff. – jefflunt Feb 12 '11 at 23:12
  • Well, I am trying to be polite)) Personally, I am trying to use capistrano deploy from git through test server( kind of continious integration tool). I recomend you to do the same( git, capistrano, some continous integration solution). – Sergey Feb 12 '11 at 23:18
  • :) You were plenty polite. I'm absolutely aware of Capistrano as the preferred deployment option - this is only meant as a security question. – jefflunt Feb 12 '11 at 23:43
  • Can I ask why you aware of Capistrano as the preferred deployment option? – Sergey Feb 12 '11 at 23:45
  • Well, preferred, meaning that based on what else I've read, it seems popular, and it works well with Rails apps, though it's capable of plenty more than that. – jefflunt Feb 12 '11 at 23:52
  • Well, anyway any CI such as hudson(jenkins) is very similar to your "Update app" functionality. – Sergey Feb 13 '11 at 00:21
1

Don't send the password. The app could be compromised and trojaned or the filtering could fail. Instead, grant the web app read-only access to the repository via a separate account or public access.

Don't restart the server if there are no changes. Then the action is secure even without access control: unless the developer has authorized the update by updating the stable branch, nothing happens. If the stable branch is not so stable, create a separate production branch for this.

Stop the webserver before doing the update. The app might not be secure or safe to use as a mix of files from different versions.

Make sure the web server doesn't serve any metadata files left by the VCS.

aaz
  • 5,136
  • 22
  • 18
  • So, with the separate repository access account, w/read access only for this kind of a setup, and leaving out the password submission form (great point) you could, to take it one step further, actually have the server auto-update itself via the stable branch, without a security concern? As Sergey's answer notes, this could introduce several potential problems with an unattended deployment, but from a security standpoint it should work. – jefflunt Feb 12 '11 at 23:48
  • Or to say it another way - just eliminate the idea of a "update_app" action altogether. You could simply have the server auto-update itself via the stable branch, for example once per week, on an automated maintenance schedule. Of course that might eliminate the point of having the dev involved in the deployment - oversight to make sure nothing breaks and takes the app down. – jefflunt Feb 12 '11 at 23:57
  • Yep, that's what I was getting at. A button is useful, as you say, to make sure that someone's watching if (when) it breaks, and maybe to synchronise it with other sysadmin actions (not restarting the server if it's switched off for another reason). – aaz Feb 13 '11 at 00:04