WordPress.org

日本語

セキュリティ

以下は、WordPress.org 公式サイトのページ「WordPress › About » Security」を訳したものです。

誤字脱字誤訳等ありましたら GitHub のリポジトリへプルリクエストを頂けますと助かります。

WordPress セキュリティ白書

 

概要

このドキュメントは、WordPress コアソフトウェアの開発とそれに関連するセキュリティプロセスの分析と説明だけでなく、ソフトウェアに直接組み込まれる固有のセキュリティの調査でもあります。コンテンツ管理システムや Web アプリケーションフレームワークとして WordPress を評価する立場にある意思決定者は、自分の分析と意思決定にこの文書を利用するべきであり、開発者は、この白書を参照してこのセキュリティコンポーネントとこのソフトウェアのベストプラクティスに習熟するべきです。

この文書に記載されている情報は、この白書公開時の最新安定版ソフトウェア、WordPress 4.1 の最新版のものですが、WordPress 開発チームは後方互換性に最大限の注意を払っているので、直近のこのソフトウェアのいくつかのバージョンでも関連するものと考えてください。特定のセキュリティ対策と変更は、コアソフトウェアの特定のリリースで追加されたものとして言及されます。可能な限りの安全性を確保するため、常に WordPress の最新安定版を利用するよう強くおすすめします。

要旨

WordPress は、非常に多数のウェブサイト、ウェブアプリケーション、ブログを動かすために使われている動的なオープンソースのコンテンツ管理システムです。現時点では、インターネット上のトップ1千万ウェブサイトのうち23％以上で利用されています。WordPress の使いやすさ、拡張性、および成熟した開発コミュニティによって WordPress は普及し、あらゆる規模のウェブサイトのための安全な選択肢となっています。

WordPress は2003年のその始まりから継続して堅牢化され続けているので、このコアのソフトウェアは一般的なセキュリティーの脅威に対処したりそれを軽減したりできます。 このセキュリティの脅威には Open Web Application Security Project によって一般的なセキュリティの脆弱性として識別されているトップ10のものも含まれ、この文書でまた考察いたします。

WordPress のセキュリティチームは、WordPress のコアリーダーシップチームと共同で、また WordPress のグローバルコミュニティに支えられ、WordPress.org で配布され、インストールされるコアソフトウェアのセキュリティ問題を特定、解決すべく尽力しています。同様にまた、第三者のプラグインとテーマ作成者のためにセキュリティのベストプラクティスを推奨したり文書化したりしています。

サイトの開発者および管理者のみなさんは、コア API の正しい利用と一般的な脆弱性の源となってきているサーバーの設定には特別な注意を払うようにし、また同様に、WordPress にアクセスするためのパスワードに強力なものを利用するようにすべてのユーザーに対して確実を期すべきです。

WordPress の概要

WordPress は、フリー (訳注: ここでは無料かつ自由の意味) なオープンソースのコンテンツ管理システム (CMS) です。これは世界で最も広く使用されている CMS ソフトウェアであり、トップ1千万のうちの23％以上1のウェブサイトを動かしていて、CMS を使用しているすべてのサイトの60％の市場シェアを占めると推定されます。

WordPress はコアとなる4つの自由を提供する一般公衆利用許諾契約書 (GPLv2 もしくはそれ以降）の下でライセンスされており、それはまた WordPress の「権利章典」と考えることができます:

  1. いかなる目的であれ、そのプログラムを実行する自由。
  2. そのプログラムがどのように機能するかを研究し、それを自分が望むように変更する自由。
  3. 再配布する自由。
  4. あなたの修正版のコピーを他の人に頒布する自由。

WordPress のコアリーダーシップチーム

WordPress のプロジェクトは実力主義で、コアリーダーシップチームによって運営され、その共同創始者でありリード開発者のマット·マレンウェッグに率いられています。このチームは、コア開発、WordPress.org、およびコミュニティへの主導権など、このプロジェクトのすべての側面を統制しています。

このコアリーダーシップチームは、マット·マレンウェッグ、5人のリード開発者、および1ダース以上の恒久的なコミットアクセスを持つコア開発者によって構成されています。これらの開発者は、技術的判断に関する最終的な権限を持っていて、アーキテクチャに関する議論と実装の取り組みをリードしています。

WordPress には寄与してくれるたくさんの開発者がいます。こうした開発者の中には以前の、もしくは現行のコミッターがいたり、あるいは将来的にコミッターとなる可能性の高い方もいたりします。こうした貢献開発者は信頼され、WordPress へのベテランの貢献者は仲間の間で大いに尊敬を得ています。WordPress にはまた、必要に応じたゲストコミッターがいます。コミットアクセスを許可された個人で、時には特定のコンポーネントのために一時的もしくは実験的な場合もあります。

こうしたコア開発者と寄与開発者が WordPress の開発を主にリードしています。各バージョンで数百人もの開発者が WordPress にコードを寄与してくれています。これらのコアコントリビューターは何らかの方法でコアのコードベースに寄与するボランティアです。

WordPress のリリースサイクル

WordPress のそれぞれのリリースサイクルは、一人もしくは複数の WordPress のコア開発者がリードします。一つのリリースサイクルは通常、最初の開発範囲選考ミーティングからそのバージョンのリリースまで、約4ヶ月です。

リリースサイクルは、以下のパターン2にしたがいます:

  • フェーズ1: 計画とチームのリード役の確保。これは、Slack の #core チャットルームで行われます。リリースリード役は、WordPress の次のリリースのための機能について議論します。WordPress のコントリビューターもその議論に参加します。リリースリード役が各機能ごとにそのチームのリード役を特定します。
  • フェーズ2: 開発作業が開始されます。チームのリード役は、チームを組み立て、割り当てられた機能に取り組みます。開発を確実に前進させるため、チャットが定期的に開催されます。
  • フェーズ3: ベータ版。ベータ版がリリースされ、ベータテスターはバグ報告の開始を依頼されます。このフェーズ以降、新しい拡張や機能のリクエストのためのコミットは実施されません。サードパーティのプラグインとテーマの作者は、そのリリースでこれから変更される点に対して自分たちのコードをテストすることを促されます。
  • フェーズ4: リリース候補。この時点から、翻訳可能な文字列の変更は停止されます。作業の対象はリグレッション(訳注:修正済みのバグや不具合の再発箇所)とブロッカー(訳注:正式版としてのリリースを阻む重大な不具合)のみになります。
  • フェーズ5: 正式版のリリース。WordPress の正式版がリリースされ、更新のために WordPress の管理画面からそのアップデートが利用可能になります。

バージョン番号とセキュリティリリース

WordPress のメジャーバージョンは最初の二つの数字によって決定されます。たとえば、3.5はメジャーリリースで、3.6、3.7、4.0もまた、メジャーリリースです。「WordPress 3」または「WordPress 4」は存在しません。各メジャーリリースはその番号付け、例えば「WordPress 3.9」と言及されます。

メジャーリリースでは、新しいユーザー向けの機能と開発者開発者向けの API を追加することがあります。ソフトウェアの世界では通常、「メジャー」バージョンというのは後方互換性なくすこともできることを意味しますが、WordPress は後方互換性を保つよう努めています。開発者にとっても同様ですが、ユーザーにとってもアップデートをより簡単な事にするため、後方互換性というのはこのプロジェクトにとってもっとも重要な理念の一つです。

WordPress のマイナーバージョンは3番目の数字によって決まります。バージョン3.5.1はマイナーリリースで、3.4.2もまた同様にマイナーリリースです3 。マイナーリリースは、セキュリティ脆弱性の修正と重大なバグの対処のみに限定されます。WordPress の新しいバージョンがこのように頻繁にリリースされているので – 目標としてはメジャーリリースが4〜5ヶ月ごと、マイナーリリースは必要に応じて – 必要となるのはメジャーとマイナーリリースのみです。

バージョンの後方互換性

WordPress のプロジェクトは、後方互換性への強い信念を持っています。この信念はつまり、WordPress のコアソフトウェアがアップデートされてもテーマ、プラグイン、およびカスタムなコードが機能し続けるという意味であり、それによりまた、サイトのオーナーに自分たちの WordPress バージョンを最新の安全なリリースのバージョンに保つように促すことにもなります。

WordPress とセキュリティ

WordPress セキュリティチーム

WordPress のセキュリティチームは、リード開発者やセキュリティ研究者など約25名の専門家で構成されています。そのうち約半分は Automattic (ウェブ上ではもっとも古くからあり、かつ最大の
WordPress ホスティングプラットフォーム) の従業員であり、多くがウェブセキュリティの分野で働いています。このチームはよく知られていて信頼できるセキュリティ研究者やホスティング会社3 と情報交換しています。

WordPress のセキュリティチームは、しばしば他のセキュリティチームと協力して、共通に依存するプログラムの問題に対処します。例えば、WordPress 3.9.2 4での、WordPress に同梱の XML-RPC API によって使用されていた PHP XML パーサの脆弱性問題などです。この脆弱性の解決は、WordPress と Drupal のセキュリティチームの共同の努力の結果でした。

WordPress のセキュリティリスク、プロセス、およびその歴史

WordPress のセキュリティチームは、あらゆる潜在的な脆弱性をただちにセキュリティチームに警告することによる責任ある開示を信じています。潜在的なセキュリティの脆弱性は、メールアドレス: security@wordpress.org5 経由でセキュリティチームに直接通知することができます。セキュリティチームは、プライベートなメールリストを経由してチーム内で相談し、隔離されたプライベートな Trac 上でバグやセキュリティ問題を追跡、テスト、解決の作業を行っています。

各セキュリティレポートは受信次第確認され、チームはその脆弱性の検証およびその重大度を決定するための作業をします。問題が確認された場合、重大度に応じて、WordPress ソフトウェアの今後のリリースに取り入れることができる、もしくはセキュリティリリースとして即時に公開できるその問題を解消するためのパッチをセキュリティチームは計画します。

即時のセキュリティリリースでは、セキュリティチームによってそのリリースと変更の詳細について告知する注意勧告が WordPress.org ニュースサイト6に公開されます。その注意勧告の中では、将来的にも引き続き責任ある報告を奨励し促進するため、脆弱性の責任ある開示のためのクレジットが与えられます。

WordPress ソフトウェアの管理者には、新しいリリースが公開されるとアップグレードするため通知が自分のサイトのダッシュボードに表示され、手動でアップグレードすると、そのリリースでの変更の詳細が記載された「WordPress について」の画面にリダイレクトされます。管理者が自動バックグラウンド更新を有効にしている場合は、アップグレード完了後にメールを受け取ります。

セキュリティリリースのためのバックグラウンド自動更新

バージョン3.7以降、3.7.1や3.7.2のようなすべてのマイナーリリース7のための自動化されたバックグラウンド更新機能を WordPress は導入しました。WordPress のセキュリティチームは問題を特定、修正し、WordPress のための自動化されたセキュリティ強化を送り出すことができ、サイトの所有者は自分たちの側では何もする必要はなく、セキュリティ更新は自動的にインストールされます。

セキュリティ更新プログラムがその時点の WordPress 安定版リリースのためにプッシュされると、バックグラウンド更新が可能なすべてのバージョン (WordPress 3.7以上) に対してもセキュリティ更新をプッシュします。そのため、こうした WordPress の古くても最近のバージョンであれば、セキュリティ更新を受けることができます。

個々のサイト所有者は、設定ファイル内の単純な変更によって自動バックグラウンド更新プログラムの無効化を選択できますが、この機能の有効化の維持および WordPress 最新安定版の使用をコアチームは強く推奨しています。

2013年の OWASP トップ10

オープンウェブアプリケーションセキュリティプロジェクト (OWASP) は、ウェブアプリケーションのセキュリティに特化したオンラインコミュニティです。OWASP トップ10リスト8は、幅広い組織にとって最も深刻なアプリケーションセキュリティ上のリスクを特定することに焦点を当てています。トップ10の項目は、悪用のされやすさ、検出可能性、そして推定されるインパクトのコンセンサス予想の組み合わせにより選択、優先順位付けされます。

次のセクションでは、これらの潜在的なリスクに対してコアソフトウェアおよびサードパーティのプラグインとテーマを強化するために WordPress が使用している API、リソース、およびポリシーについて考察します。

A1 – インジェクション

WordPress には、許可されていないコードが確実に挿入されないようにするために開発者を支援したり、開発者がデータをバリデートおよびサニタイズする手助けをしたりする関数や API のセットがあります。HTML、URL、そして HTTP ヘッダー内の入出力データを守り、バリデートし、サニタイズするためにこれらの API をどのように使うか、データベースおよびファイルシステムとのやりとりをする時のベストプラクティスおよびドキュメントが利用可能です9。また管理者は、フィルタを介してアップロードできるファイルの種類をさらに制限することができます。

A2 – 不完全な認証とセッション管理

WordPress のコアソフトウェアは、ユーザー ID、名前、パスワードなどのユーザーアカウントおよび認証を、認証クッキーと同様にサーバー側で管理しています。パスワードは、標準的なソルティングおよび延伸技術を使用してデータベースに保護されます。WordPress のバージョン4.0以降では、 既存のセッションはログアウト時に破棄されます。

A3 – クロスサイトスクリプティング (XSS)

WordPress は、ユーザーの入力したデータが安全であることを保証するのを助けることのできる様々な機能を提供しています10 。信頼の置けるユーザー、シングル WordPress の場合では管理者権限と編集者権限、マルチサイト WordPress の場合は加えてサイト管理者権限のユーザーは、投稿や固定ページ内などでフィルタリングされていない HTML や JavaScript を必要なときに投稿することができます。信頼されていないユーザーによって送信されたコンテンツは、デフォルトでフィルタリングされ、wp_kses関数を通じた KSES ライブラリを利用して危険なエンティティを削除されます。

例として、関数 the_search_query() が多くのテーマ作者によって誤って利用されていて、彼らがこの関数の出力をエスケープせずに HTML 内で利用していることに WordPress のコアチームは WordPress 2.3のリリース前に気づきました。極めてまれに後方互換性を損なうかもしれませんでしたが、WordPress 2.3ではこの関数の出力が予めエスケープされたものへと変更されました。

A4 – 安全ではないオブジェクトの直接参照

WordPress は、URL やフォームのフィールド内で利用可能なユーザーアカウントやコンテツの一意の数値識別子など、直接的なオブジェクト参照をしばしば提供しています。これらの識別子は直接的なシステム情報を開示していますが、WordPress の豊富なアクセス権とアクセス制御システムにより、許可されていないリクエストは阻まれています。

A5 – セキュリティの設定ミス

WordPress のセキュリティ設定操作の大部分は、管理者権限のみに制限されています。WordPress のデフォルト設定はコアチームのレベルで継続的に評価されています。また、WordPress のコアチームは、WordPress サイトを稼働させるサーバー構成のセキュリティを強化するためのドキュメントやベストプラクティスを提供しています11。

A6 – 機密データの露見

WordPress のユーザーアカウントのパスワードはソルト化され、ポータブル PHP パスワードハッシュングフレームワークに基づいてハッシュ化されています12。WordPress のパーミッションシステムは、登録者ユーザーの個人情報、コメント送信者のメールアドレス、非公開コンテンツなどのプライベートな情報へのアクセスコントロールに利用されています。WordPress 3.7 では、コアのソフトウェアにパスワード強度メーターが導入され、ユーザーがパスワードを設定するための付加的な情報と強度を増すためのヒントを提供しています。WordPress はまた、HTTPS を要求するための設定オプションも持っています。

A7 – ミッシング機能レベルアクセス制御

WordPress は、関数レベルのすべてのアクセス要求に対して、そのアクションが実際に実行される前に、認証と権限が適切かどうかをチェックします。管理用のURLやメニュー、そしてページへの適切な認証なしでのアクセスまたは可視化は、権限のないユーザーからのアクセスを防止するために認証システムとしっかりと統合されています。

A8 – クロスサイトリクエストフォージェリ (CSRF)

WordPress はナンス13と呼ばれる暗号化トークンを使用して、潜在的な CSRF の脅威から保護するために許可されたユーザーからのアクション要求の意図をバリデートします。WordPress は一意で一時的なトークンの生成および検証のための API を提供しています。このトークンは特定のユーザー、特定のアクション、特定のオブジェクト、特定の期間に制限され、必要に応じてフォームや URL 付加することができます。さらに、すべてのナンスはログアウト時に無効化されます。

A9 – 既知の脆弱性を持つコンポーネントの使用

WordPress のコアチームは、コア機能のために WordPress に含まれているライブラリや統合されているフレームワークのいくつかを密接にモニターしています。コアチームはこれまでも、
WordPress 3.5.214における TinyMCE でのクロスサイトの脆弱性を修正するためのアップデートなど、こうしたサードパーティ製コンポーネントをより安全にするための貢献をいくつか行っています。

コアチームは必要に応じて重要な外部コンポーネントをフォークしたり入れ替えたりします。例えば、3.5.2では、SWFUpload ライブラリが Plupload と公式に入れ替えられ、短期的に SWFUpload を使い続けるプラグイン用に SWFUpload の安全なフォークバージョンがセキュリティチームによって提供されました15。

A10 – 未検証のリダイレクトと転送

WordPress の内部のアクセス制御や認証システムは、ユーザーを望まないサイトへ導いたり、自動リダイレクトしたりする試みから保護します。この機能は、API の wp_safe_redirect() 16 を介してプラグイン開発者でも利用可能です。

さらなるセキュリティリスクや懸念

XXE (XML外部エンティティ) 処理の攻撃

XML を処理する場合、WordPress は外部エンティティとエンティティ拡張攻撃の両方を防ぐためにカスタムな XML エンティティの読み込みを無効にします。WordPress は、プラグインの作成者向けには PHP のコア機能以上のさらなる安全な XML 処理用 API は提供していません。

SSRF (サーバー側リクエストフォージェリ) 攻撃

WordPress によって発行された HTTP リクエストは、ループバックおよびプライベート IP アドレスへのアクセスを防止するためにフィルタリングされています。さらに、アクセスは特定の標準な HTTP ポートにのみに限定されています。

WordPress のプラグインとテーマのセキュリティ

デフォルトテーマ

WordPress は、フロントエンド上でコンテンツをレンダリングして表示させるためのテーマを必要とします。デフォルトのテーマ (現在は「Twenty Fifteen」) は WordPress コアに付属していて、セキュリティ上の理由からテーマ開発者チームに加えてコア開発チームと両方によって積極的にレビューされ、テストされています。

デフォルトのテーマは、カスタムテーマ開発のための出発点として役立てるこことができます。サイト開発者は、いくつかのカスマイズを含めつつも、機能と安全性のほとんどをこのデフォルトテーマに頼る子テーマを作成することができます。必要でない場合は、管理者はデフォルトテーマを簡単に削除することができます。

WordPress.org テーマ・プラグインレポジトリ

WordPress.org サイトには約30,000以上のプラグインと約2,000以上のテーマが掲載されています。これらのテーマやプラグインは掲載のため提出され、リポジトリでそれらが利用可能になる前にボランティアによって手動でレビューされます。

このリポジトリにプラグインやテーマが入るということは、これらのプラグインやテーマがセキュリティの脆弱性から免れていることを保証するわけではありません。このリポジトリに入れてもらうための申し込み前にプラグイン作成​​者が参考にするガイドライン17と、どのように WordPress のテーマ開発を行うかに関する広範囲なドキュメント18が WordPress.org サイトで提供されています。

各プラグインとテーマは、そのプラグインやテーマの所有者によって継続的に開発され、その後の修正や機能開発がリポジトリにアップロードされ、その変更の説明と一緒にそのプラグインやテーマをユーザーが利用可能になれるようになっています。サイト管理者には、その管理用のダッシュボードを介して更新する必要があるプラグインが通知されます。

プラグインの脆弱性が WordPress セキュリティチームによって発見された場合、チームはそのプラグインの作成者に連絡し、そのプラグインの安全なバージョンのための修正とリリースに協力します。そのプラグインの作成者からの応答がない場合、またはその脆弱性が重大な場合には、そのプラグイン/テーマは公開ディレクトリから取り除かれ、場合によってはセキュリティチームによって直接修正、更新されます。

テーマレビューチーム

テーマレビューチームはボランティアのグループで、WordPress コミュニティから認められ、キーとなるメンバーによってリードされて、彼らにより公式の WordPress テーマディレクトリ掲載のために申請されたテーマをレビューされ、承認されます。テーマレビューチームは、公式テーマレビューガイドライン19、テーマユニットテストデータ20、テーマチェックプラグイン21のメンテナンスを行っています。また、テーマ開発のベストプラクティスに関する WordPress のテーマ開発者コミュニティの参加、教育に取り組もうとしています。このグループへの参加は WordPress 開発チームのコアコミッターたちによってモデレートされています。

WordPress のセキュリティにおけるホスティングプロバイダの役割

WordPress は多数のプラットフォームにインストールすることができます。WordPress のコアソフトウェアでは、このドキュメントでカバーされている安全なウェブアプリケーションの運営のため多くの対策を提供していますが、このソフトウェアをホストするオペレーティングシステムや基盤となるウェブサーバーの設定もまた WordPress を安全に保つために同じように重要です。

WordPress.com と WordPress のセキュリティに関するメモ

WordPress.com は WordPress の設置数として世界最大で、WordPress プロジェクトの共同創始者でもあるマット·マレンウェッグによって設立され Automattic によって所有および管理されています。WordPress.com は、WordPress コアソフトウェア上で動作し、独自のセキュリティプロセス、リスク、およびソリューションを持っています22 。この文書は、自分で運営するタイプ、WordPress.org からダウンロード可能で世界中のどのサーバーにもインストール可能なオープンソースの WordPress に関するセキュリティについてのものです。

付録

WordPress コア API

WordPress コアのアプリケーションプログラミングインターフェイス (API) は、いくつかの個別の API 23で構成され、それぞれ関係する関数、利用、与えられている一連の機能をカバーしています。それとともに、プラグインやテーマが安全確実に WordPress コア機能とのやり取りやその変更、そして拡張をできるようにしているこのプロジェクトのインターフェイスを形作っています。

それぞれの WordPress API はベストプラクティスと WordPress コアソフトウェアを拡張するための標準化された方法を提供していますが、WordPress のセキュリティを強化し堅牢化するためにもっとも関連するのが次の WordPress API です:

データベース API

WordPress 0.71 で実装されたデータベース API24 は、データベースに格納されているデータに、名前付きの値としてアクセスするための正しい方法を提供します。

ファイルシステム API

WordPress 2.626 で追加されたファイルシステム API25 は、もともと WordPress 独自の自動更新機能のために作られました。ファイルシステム API は、さまざまな種類のホスト上でファイルシステムにローカルファイルを安全に読み取り・書き込みするために必要な機能を抽象化しています。

これは WP_Filesystem_Base クラスおよびいくつかのサブクラスを通じて行われ、個々のホストサポートに応じてローカルファイルシステムに接続するためのさまざまな方法を実装しています。ローカルのファイルに書き込む必要があるテーマやプラグインは、WP_Filesystemファミリのクラスを使用してそれを行うようにします。

HTTP API

WordPress 2.7 28で追加され、WordPress 2.8でさらに拡張された HTTP API 27は、WordPress の HTTP リクエストを標準化しています。この API は、クッキー、gzip 圧縮符号化及び復号化、チャンクデコード (HTTP 1.1の場合)、およびその他の種々の HTTP プロトコル実装を処理します。この API は、リクエストを標準化し、送信する前に各メソッドをテストし、サーバー設定に基づいてリクエストを生成するために適切な方法を使用します。

権限と現在のユーザー API

権限と現在のユーザー API 29 は、要求されている任意のタスクまたは操作を実行するために現在のユーザーのアクセス権や権限を確認するのに役立つ関数の集合であり、ユーザーが許可されていない機能にアクセスしたり、実行したりすることに対する保護をさらに強化できます。

この白書コンテンツのライセンス

この文書内のテキスト (WordPress のロゴおよび商標を除く) は、CC0 1.0 Universal (CC0 1.0) Public Domain Dedication のもとにライセンスされています。利用者は許可を求める必要なく、商業目的であっても作品の複製・変更・配布・実行を行うことができます。

この資料を作成するにあたってインスピレーションを与えてくれた Drupal セキュリティ白書に感謝します。

追加資料

執筆: サラ・ロッソ

バリー・エイブラハムソン、マイケル・アダムス、ジョン・ケイヴ、ヘレン・ホウ-サンディ、ディオン・ハルス、モー・ジェンガ、ポール・マイオラナによる貢献

バージョン1.0 2015年3月

日本語版翻訳者(敬称略)

  • 立花明 (Twitter: @atachibana)
  • haya2_ (Twitter: @haya2_)
  • 高野直子 (Twitter: @naokomc / URL: http://ja.naoko.cc/ )
  • 額賀順子 (Twitter: @nukaga / URL: http://nuuno.net/ )
  • 上滝太祐 (Twitter: @tekapo /URL: http://wp.tekapo.com/)

脚注

WordPress 4.3.1 をダウンロード .zip — 7.2 MB

.tar.gz 形式をダウンロード — 6.7 MB

他のダウンロードオプション

コンテンツとリンク

サイト内の他のページと関連情報はこちらから