1

次のシナリオのセキュリティ上の懸念は何ですか？（これは誰かが試みるクレイジーなアイデアの1つであり、おそらくそれは良いアイデアであり、おそらくそれはひどいアイデアです...）

example.comにRailsアプリがあり、https：//example.com/admin/update_appにアクションがあります

このアクションには、次の要件があります。

  1. httpsが必要です（https上にない場合はリダイレクトします）
  2. 管理者アクセスが必要です
  3. このアクションにより、「リポジトリパスワード：[]」というフォームのページが表示されます。
  4. このフィールドは、Railsのログフィルタリングメカニズム（つまり、このメソッド）を介して、サイトへの認証が除外されるのと同じ方法で、サーバーログから除外されます。

このアクションは次のことを行います

  1. コードリポジトリのパスワードをフィールドに入力し、[送信]をクリックします
  2. このアクションは、コードリポジトリの安定したブランチから最新の更新をプルし、それらをサイトに適用するシェルスクリプトを開始します（リポジトリ認証が失敗した場合を除き、それ以降のすべてのステップが停止します）。
  3. Webサーバーが再起動されます
  4. 「アプリの更新が完了しました」などの簡単なメールが管理者に送信されます
4

2 に答える 2

1

さて、これはすべて、gitリポジトリを介してサーバーにデプロイするcapistranoを再発明したことを思い出させます。

唯一の問題：1）マージ（ポイント2）中に競合が発生した場合はどうなりますか？2）Webサーバーが正しく再起動しない場合はどうなりますか（ポイント3）？3）リポジトリ内のブランチがそれほど安定していない場合はどうなりますか（ポイント2）？

于 2011-02-12T23:09:19.043 に答える
1

パスワードを送信しないでください。アプリが危険にさらされてトロイの木馬にされたり、フィルタリングが失敗したりする可能性があります。代わりに、別のアカウントまたはパブリックアクセスを介して、Webアプリにリポジトリへの読み取り専用アクセスを許可します。

変更がない場合は、サーバーを再起動しないでください。そうすれば、アクセス制御がなくてもアクションは安全です。開発者が安定したブランチを更新して更新を承認しない限り、何も起こりません。安定したブランチがそれほど安定していない場合は、このために別の本番ブランチを作成します。

更新を行う前に、Webサーバーを停止してください。このアプリは、異なるバージョンのファイルを組み合わせて使用​​する場合、安全または安全ではない可能性があります。

WebサーバーがVCSによって残されたメタデータファイルを提供しないことを確認してください。

于 2011-02-12T23:32:46.827 に答える