開発者/管理者/ユーザーが安全にWebシステムを利用する方法

(更新日: 2015/08/13)

Webシステムには様々なリスクがあります。より安全に利用するためのTipsを紹介します。

他の方も普通にこれから紹介する方法を使ってWebシステムにアクセスしている、と思っていたのですがそうでもないようです。これから紹介する方法でリクエストフォージェリやクロスサイトスクリプティングなどのリスクを排除/軽減できます。

リクエストフォージェリ/クロスサイトスクリプティングとは?

ちょうど先日、リクエストフォージェリを再考というエントリを書きました。詳しくはこちらを参照してください。

スライド3

罠Webページを経由するクロスサイトスクリプティングは、罠Webページを経由するクロスサイトリクエストフォージェリの仕組みは同じです。インジェクションされるモノがJavaScriptなのか、コマンド(Webアプリが持つ機能など)なのか、が異るだけです。

 

内部で利用するWebシステム

私の開発環境/管理環境もですが、開発環境/管理環境は”インターネットに公開”しているシステムに比べセキュリティ的に甘いモノがあります。内部ネットワークはファイアウォールによって守られているので内部ネットワークのシステムは外部から直接攻撃できません。しかし、クロスサイトリクエストフォージェリやクロスサイトスクリプティングによる中継(間接)攻撃は簡単に行えます。

開発中のプロトタイプ、テストプログラム、サンプルプログラムや内部ユーザーからしかアクセスを想定せずHTTP認証を使っているモノなどは、インターネットに公開しているシステムに比べると攻撃されるリスクが高いものが多くあります。

内部ネットワークなのでリスクを許容する場合も多くあります。この場合、攻撃者が内部ネットワークとシステム構成を知っていれば、外部の罠Webページを経由して攻撃される可能性があります。内部ネットワークのWebサーバーのスキャンはJavaScriptを利用して簡単に外部から行えます。

https://github.com/yohgaki/jslanscanner

つまり内部ネットワークとはいえ、クロスサイトリクエストフォージェリやクロスサイトスクリプティングのリスクは無視できません。

開発環境や管理環境ではリスクがあるプログラムを使用することが多いです。そもそもプロトタイプやテスト/開発用ブログラムなど、公開サイトでは必要なセキュリティも一切考えていないものもあります。

 

リスクの排除/軽減

しかし、簡単な方法でリスクを排除/軽減できます。セキュリティやプログラミングの基本である分割&統治(Divide and Conquor)を行うだけです。

今のブラウザにはユーザープロファイルを切り換え可能なものが一般的に利用されています。ユーザープロファイルを

  • 外部Webサイトを閲覧する物(仕事とは関係無い物)
  • 外部Webサイトを閲覧する物(主に仕事用)
  • 開発用Webサイトを閲覧する物
  • 管理用Webサイトを閲覧する物

などに分離して、それぞれのプロファイルからは用途に限定したサイトのみにアクセスするようにします。

ユーザープロファイルを簡単に切り替えれないブラウザの場合はVMを利用すると良いです。VMを利用できない場合、別のユーザーに切り換える機能を利用して使い分けます。私はInternet ExplorerやSafariは常用せず、テストにしか使わないテスト専用として使っています。

プライベートブラウズ機能(Chromeのゲストモード/シークレットモード(シークレットウィンドウ)、IE/EdgeのInPrivateブラウズなど)を利用するのも有用です。SNSやブログ、広告などのリンクをクリックする場合に利用します。近年ではSNSや広告によるマルウェアなどの配布も大幅に増えています。怪しいリンクはクリックしないに越したことはありませんが、プライベートブラウズ機能を活用することである程度リスクを緩和できます。

このブログのGoogle Analyticsを見るとプライベートブラウズ機能を活用されている方は少なくないようです。プライバシー/セキュリティに有用なので使っていない方は是非!

 

まとめ

開発/管理用のWebシステムにはリスクが高い物も多くありますが、ここで紹介した方法で使い分ければ問題なく利用できます。

注意点はIPアドレスによる制限だとブラウザを使い分けても意味がない※点です。折角ブラウザを使い分けてもIPアドレスで権限を与えてしまっては、使い分けが機能しません。使い分けているブラウザごとに権限を分割しなければなりません。

※ 専用仮想マシンで別IPアドレスを使っている場合はIPアドレスでもOKです。

HTTPのBasic認証でも構わないので、ユーザー認証を付けるようにすると安全になります。いちいち認証するのが面倒臭い、という場合はアクセストークンとなるクッキーを保存しそのトークンが含まれないリクエストをWebサーバーレベル(Apacheならmod_rewrite)で全て拒否する、といった方法で防御しても良いでしょう。

 

Comments

comments

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です