Jindolfのセキュリティ

※ 以下の情報は、2008-07当時の人狼BBS:F国とJindolf 2.6.2版とJRE1.6を取り巻く状況に付いて記述したものです。現在は状況が変わっている可能性があります。


ネットワーク一般

  • Jindolfは、人狼BBSサーバ各国(国情報画面にベースURLとして表示されるURL下)と、これらのサーバから送られる(X)HTML上に埋め込まれた顔アイコン画像URL以外にHTTPアクセスしません。
    ※ 人狼BBSサーバと、そこで用いられる顔アイコン画像のURLのホスト名は必ずしも一致しません。
  • Jindolfは、JRE中のランタイム「java.net.HttpURLConnection」クラスを使ってCGIにアクセスします。プロクシの設定によっては、プロキシサーバとの通信が発生するかもしれません。
  • もしJindolfが人狼BBSサーバCGIからHTTPリダイレクト応答を受信しても、Jindolfがリダイレクト先にアクセスしにいく事はありません。 ※画像に関してはリダイレクト先に読みに行く可能性もあります。
  • F国人狼BBSサーバCGIは、Rubyのソースコード断片らしきものを送受信することをクライアントに要求してきますが、JindolfがこのソースコードをJRubyなどで評価実行することは決してありません。

パスワードデータに関して

  • F国の人狼BBSサーバでは、WebブラウザやJindolfとの通信に際して、IDとパスワードのペアを平文(鍵無しで復号化できる簡易な符号化)でやりとりします。送信データだけでなく人狼BBSサーバからの受信データ(ログイン応答)にも含まれます。
    一度ログインに成功すると、ログアウトするかCookieが無効になるまでの間、IDとパスワードのセットが平文で埋め込まれたCookieデータが「毎回」ネットワーク上を流れます。HTTP基本認証を少し緩くした程度のセキュリティ強度とご理解ください。
    信頼できない通信経路やプロキシサーバを用いると、簡単にIDとパスワードのセットが漏洩します。これからID登録を行う方は、よそで使う重要なパスワードを人狼BBSに流用しない方がよいでしょう。
  • Jindolfはなるべくヒープ上のパスワードデータの扱いには気を配るつもりですが、Jindolfと同じVMインスタンス上に信頼できないクラスが同居したときにパスワードを守りきれる自信がありません。(CookieHandlerによるCookie横取りとか)
    Jindolfを実行するVMインスタンスをほかの用途に兼用しないことを強くお勧めします。あと不用意にデバッグポートなどを開けっぱなしにしとかないようにね。
  • Jindolfは、一般的なWebブラウザと異なり、ファイルシステムを始めとするストレージにCookieデータを一切保管しません。アプリケーション終了とともにVMが終了すれば、Cookieと一緒にパスワードデータも消えます。
  • Jindolfは決して各種WebブラウザのCookieデータを読み書きしません。また、WebブラウザがJindolfのCookie情報にアクセスすることもありません。そのためJindolfとWebブラウザはそれぞれ個別にログイン操作を行う必要があります。
    (※ 2008-07現時点の人狼BBSでは、異なるクライアントからの同じIDによる同時ログインは禁止されていません。)

UserAgent名に関して

  • Jindolfでは、人狼BBSサーバのCGI(index.rb)に対する全てのHTTP送信データのUserAgent名に「Jindolf/版数 (コメント)」を送っています。この情報には、あなたがJindolfを使って人狼BBSサーバにアクセスしている事、Jindolfのバージョン、ハードウェア種別、OSの識別情報、JREの識別情報が含まれます。
    例: 「Jindolf/2.6.2 (Windows XP; 5.1; x86; Sun Microsystems Inc.; 1.6.0_07)」
  • あなたがメジャーなWebブラウザを用いて人狼BBSに接続している場合も、おそらく何らかのUserAgent名は送出されています。
    Firefox3の例: 「Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1」
  • 人狼BBSはさくらインターネットの共有サーバを用いて運営されているらしいので、おそらくninjin氏はアクセスログを通じてこれらの情報を閲覧できる立場にあります。

ウィルス対策に関して

Jindolfのリリース作業は、「Microsoft Security Essentials」の監視下にあるWindows7機で行われています。

リリース直前の時点において、MSEが検出しうるウィルスがリリースに含まれる可能性は、非常に小さなものであると思ってよいでしょう。

必須Permissionについて

JindolfをSecurityManagerの管理下にあるセキュアなVM上で実行してF国をプレイする場合、 少なくとも以下のPermission許可をJindolfに割り当てる必要があります。

Permissionクラス名 アクセス権名 アクション
java.lang.RuntimePermission "shutdownHooks"
java.net.SocketPermission "ninjin002.x0.com:80" "connect"

他の国へのアクセスが必要な場合は、各国の人狼BBSサーバと画像サーバへのSocketPermissonを追加してください。(※ ホスト名最後にHTTPのポート番号「:80」を付けるのを忘れないでね!)

※ これだけの許可だと、デフォルト以外のLook&Feelへ変更できないとか、クリップボードへのコピーができないとか、ウィンドウにアプレットマークが現れるとか、色々制約が出てきます。

※ 2.13.2版より、java.util.logging.LoggingPermissionが無くてもとりあえずアプリ起動を続行するようになりました。

※ JRE内のライブラリによっては、Permissionの有無によって警告を発することなく微妙に動作が変わったりします。(ログのLevel表示が変わるとか)

Sun社が提供するWindows用のJRE1.6上で動かすには、さらに

Permissionクラス名 アクセス権名 アクション
java.util.PropertyPermission "os.version" "read"

が必要になるみたいです。

MacOSXについてくるJRE1.5上で動かす場合は、

Permissionクラス名 アクセス権名 アクション
java.util.PropertyPermission "java.version" "read"
java.util.PropertyPermission "apple.awt.*" "read, write"

が必要のようです。