世の中には仕様としてセキュリティを考慮していないWebアプリも多くあります。特に開発環境では多いのではないでしょうか？こういったアプリも安全に使う為には少しだけ工夫が必要です。本来、セキュリティを考慮しておいた方が良いWebアプリであっても、セキュリティが考慮されていない場合でもこの方法は利用できます。
安全性が考慮されていない例
例えば、Jenkinsはデフォルト設定ではセキュリティが考慮されていません。Jenkinsはデフォルトでログインしなくても利用できます。そして、ログイン（認証）を利用するだけでは普通のWebアプリの様に安全には使えません。常識ですよね？！
CSRF
Independently of authentication and authorization, you generally should enable to option to use “crumbs” to defend Jenkins against CSRF attacks.
Jenkinsのサイトにこう書かれているように、認証／認可とは独立して”crumbs”オプションを有効にしないとCSRF攻撃に対して防御を行いません。Jenkinsを普通のWebアプリの開発環境での使用が前提であり、一般に公開するWebアプリではないことが理由です。
え？！と思った方はぜひ「セキュアプログラミングの７つ習慣」の1番目を参照してください。
私は他人が作ったプログラムいちいち調べて確認するのが面倒＆作りかけもあったり自作ツールでもセキュリティを考慮していない物も多いので、以下に紹介するような方法で安全性を確保しています。
セキュリティを考慮しないWebアプリを安全に利用する方法
注意すればセキュリティを考慮しないWebアプリであっても安全に利用できます。
必要条件
- 認証があり、CSRF/XSS対策が無い場合、認証情報を持つクライアントを用途別に使い分ける
- 認証とCSRF/XSS対策（クロスサイト攻撃対策）が無い場合、攻撃者が攻撃対象URLを知り得ない物にする※
※ この場合、クライアントの使い分けは必須ではありませんが分ける方が良いでしょう。
CSRF攻撃は名前の通り攻撃用の別サイトを経由して（クロスサイトで）攻撃を行います。信頼できないサイトにもアクセスするモノと信頼できるサイトにアクセスするモノを適切に分離するか、攻撃者が予測できないURLを利用することで安全性を確保できます。
こんな面倒なことをしなくても全てのモノに脆弱性がなければ問題がなくなる、と思うかも知れません。一般に広く利用することを想定したソフトウェアなら脆弱性を作らないようにすべきです。
ここに書いている対策は一見面倒そうに見えますが、全てのモノの安全性を保証する方がかなりのコストが必要です。開発者／管理者用のツール／ソフトウェアはプロトタイプや作りかけ、一時的なモノなどが普通に存在します。これら全てに十分なセキュリティ対策が実装されているか保証するより、開発者／管理者用のツール／ソフトウェアが安全に利用できるようにした方が面倒が少なくなります。
対策にならない対策
プライベートアドレス／ループバックアドレスのみならそのコンピュータやプライベートネットワークからのアクセスしか受け付けません。一見分離できているように見えますが、クエストフォージェリを考えると不十分です。プライベート／ループバックアドレスのみを受け付けても攻撃する場合に
http://プライベートIPアドレス/攻撃用のパス
で攻撃できます。
開発用のブラウザと外部用のブラウザを使い分ける
HTTP認証、アプリ実装の認証、どれであっても認証機能があればブラウザの使い分けでリスクを廃除できます。
「開発作業用のブラウザ」「その他サイトブラウズ用のブラウザ」を使い分けると、クロスサイト攻撃が可能なアプリケーションであっても認証機能が邪魔をして使い分けたブラウザを跨いで攻撃することはできません。
開発者であれば
- 通常業務用（開発以外の会社業務）のブラウザ
- 開発用のブラウザ
- それ以外
の少なくとも3つのブラウザを使い分けると良いです。使い分けるブラウザはそれぞれの用途以外のサイトにはアクセスしないようにしなければなりません。
Google Chromeならユーザーの切り替えがGUIでできます。Firefoxなら-Pオプションを付けて起動すれば利用するプロファイルを選択できます。
プライベートブラウズを活用する
プロファイルの切り替えが面倒なとき、信頼性の低いWebサイトにアクセスする場合はプライベートブラウズを使うと便利です。
例えば、SNSサービスのリンク（攻撃者が利用することも多い）を開く場合は常にプライベートブラウズにします。こうするとブラウザに同一成元ポリシーのバグ（最近もありました！）があっても、自分が利用するサービスに影響するリスクを低減できます。
プロキシを利用する
ブラウザの使い分けを行っても予測しやすいURLは攻撃される可能性があります。防御したいサービスを実行するコンピュータ／ネットワークはFirewallやルーターなど、何らかの方法でネットワーク的に分離しておきます。使い分けをするブラウザがそれぞれの使い分け用のプロキシを利用するように構成します。その上で
- 認証付きプロキシを利用する
と予測しやすいURLにも攻撃も行なえません。
認証付きプロキシを利用したくない場合、
- 第三者が予測できないURLからアクセス
します。例えば、Jenkinsなら
https://192.168.123.123/01b85e79a1ff0eff5be5550a7a3ec1c9/Jenkins
というURLからアクセスできるように設定します。”https”にするのがポイントでhttpsの場合、万が一外部サイトにアクセスした場合でもリファラーでURLが漏れません。こうするとJenknsの認証やCSRF対策を有効にしていなくても安全に利用できます。
プロキシを利用しない場合
ネットワークを分離した上で認証付きプロキシを利用すると一括管理できて便利ですが、ネットワークを分離せずに個別にHTTP認証などの認証を付け加える、個別に予測不可能なURL+HTTPSを設定しても同じです。
開発用ネットワーク／システムを他の用途と完全に分離する
この対策は少しだけ敷居が高いですが最もお勧めです。敷居が高い分安全性も高いです。ネットワーク／システムを用途に合わせて丸ごと物理的／仮想的に分離して使います。
一般的な開発組織では本来
- 通常業務環境
- 運用環境
- 開発環境
- その他
の4つくらいに環境を分離し、相互に干渉しないような構成／運用にすることが望ましいです。
分離したネットワークからは業務に関係ないサイト（特に外部サイト）へのアクセスを行わないようにします。努力目標では心配な場合、プロキシを利用してホワイトリスト型でアクセス可能なサイトを指定するようにします。
開発環境と通常業務の環境（OS／ネットワーク）を物理的／仮想的に分離することも、かなり手軽になってきました。VLAN対応のHUBにも格安の物もあります。
ネットワーク／システムごと分離すれば、干渉するには仮想マシンやネットワーク設定に問題がない限り安全に分離されます。仮想マシンを使わず、物理的に別のコンピュータ／ネットワークを使えば干渉される可能性は限り無く少くなります。（ただし、開発環境のコンピュータからは外部のネットワークにアクセスできない／しない前提です。githubなどにアクセスできないのは困るので許可しますが、最小限に留める必要があります。プロキシにホワイトリストを設定して制限すると良いです）
NetGearのアンマネージプラス・スイッチ（VLAN, QoS対応）はVLAN非対応のスイッチと同価格で販売されています。ネットワーク設計／設定などのコスト増は避けられませんが、機材コストは変わりません。
NETGEAR アンマネージプラススイッチ ギガ8ポート 管理機能付 無償永久保証 GS108E-300JPS
まとめ
最後の対策は敷居が高いですが、他の対策は問題なく利用できると思います。開発環境のセキュリティを考えると、色々やっていないなあ、と思えることが見えてきませんか？
他に良い方法があったら教えてください。
参考： ソフトウェア開発環境のセキュリティ対策 （ネットワーク構成図と機器リスト付き）
Leave a Comment