« 終焉ノ参~救イの無い世界~ | トップページ | 終焉ノ悟~全テ偽リと悟るトキ~ »

終焉ノ屍~超立派な張リボテ~

自分にすら期待できないのに、他人に期待しちゃいけないってことは分かってたはずなんだ。
何度も何度も失望してきたじゃないか、ちくしょう、ちくしょう、ちくしょう。
たとえ、それが、いくら立派な外観であったとしても、絶対期待しちゃいけない。

立派な張りぼては時に明らかに間違いのないはずの信念をも打ち砕く力を持つ。

打ち砕かれた信念は己の心に突き刺さる。
失望した心に突き刺さる。
深く、深く、突き刺さる。

ここから先、あまり俺の意見を挟まずにコピペ主体で。

 

10/7 IPAから



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----------------------------------------------------------------
このメールは、取扱い番号 IPA#60026469 に関する連絡です。
- ----------------------------------------------------------------

IPAセキュリティセンターです。

ご質問にご回答いただき、ありがとうございました。

届出いただいた情報につきまして、内容を確認した結果、下記の判断理由
の通り、本制度で定義する脆弱性に該当しないと判断し、取扱いを終了さ
せていただきたいと考えておりますが、如何でしょうか。
取扱いを終了した場合でも、届出情報を参考情報としてウェブサイト運営者
へ送付したいと考えております。

内容をご一読いただき、取扱いに問題があるようでしたら、10 営業日を
目途にご連絡をお願いします。

【判断理由】
=================================================================
セッション管理に関する情報や個人情報は、サービス利用者とサービス
提供者が共に第三者に漏れないように適切に管理する必要があります。

本件は、HTTP 通信でセッション管理情報や個人情報をやり取りしてい
るためにその情報を第三者が取得できてしまう点が問題とされています。
しかし、そのためには第三者が通信を「盗聴」できる環境である必要が
あります。

上記を鑑みますと、根本的な原因は通信を盗聴できてしまうことであり、
対策すべき箇所は通信が盗聴できてしまうネットワークであると考えま
す。届出内容を見ますと、発見者様のネットワーク上で(故意に)盗聴し
たものとあるため、これはウェブサイト運営者が対策する問題ではない
と考えます。

ただ、サービス提供者との契約やプライバシーポリシー等で、通信を
暗号化する旨の記載がある場合は、その内容に従って適切に運用されて
いない為、脆弱性として取り扱っております。

下記のウェブサイトの情報を確認しましたが、会員規約(第9章)や個人
情報保護ポリシーからは情報を暗号化する旨が明記されていませんでした。

◇会員規約:@nifty◇
 http://www.nifty.com/policy/terms.htm
◇個人情報保護>個人情報保護ポリシー:@nifty◇
 http://www.nifty.com/policy/privacy.htm

その為、当該ウェブサイトは運営者が公表しているポリシーに沿って運用
されていると考え、本制度で定義している脆弱性ではないと判断しました。

しかし、発見者様が主張されております内容についても、十分に理解で
きますので、届出頂いた情報については参考情報として運営者へ送付し
たいと考えております。

=================================================================

【告示およびガイドラインの該当箇所】
=================================================================
●ソフトウエア等脆弱性関連情報取扱基準
http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
II.用語の定義
本基準で用いられる用語の定義は、以下のとおりとする。
1.脆弱性
ソフトウエア等において、コンピュータウイルス、コンピュータ不正アク
セス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の
問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者が
アクセス制御機能により保護すべき情報等に誰もがアクセスできるような、
安全性が欠如している状態を含む。

VI.対象がウェブアプリケーションである場合の脆弱性関連情報取扱基準
2.受付機関基準
(2)受付機関は、届出を受理したときは、速やかに、当該ウェブサイト
運営者に対し当該脆弱性関連情報を通知すること。ただし、当該脆弱
性関連情報が以下に該当する場合、当該届出に係る処理を取りやめる
ことができる。この場合においては、当該発見者にその旨及び
その理由を通知すること。
3)受付機関が脆弱性関連情報に該当しないと確認した場合

●情報セキュリティ早期警戒パートナーシップガイドライン
https://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
II. 用語の定義と前提

1.脆弱性の定義
脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、
コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、
その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。
なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適
切な運用によって、個人情報等が適切なアクセス制御の下に管理され
ておらずセキュリティが維持できなくなっている状態も含みます。
(ウェブサイトの不適切な運用に関しては付録4に示します。)

V.ウェブアプリケーションに係る脆弱性関連情報取扱
3.IPA の対応
4) 脆弱性関連情報への対応続行の判断
IPA は、以下の条件のいずれかと合致した場合、処理を取りやめるとともに発
見者に連絡します。
(ア) IPA が脆弱性関連情報でないと確認した場合
=================================================================

以上、よろしくお願いいたします。

------------------------------
脆弱性情報に関する連絡を行う際には、PGP公開鍵による
暗号化をお願いいたします。
https://www.ipa.go.jp/security/pgp/index.html
------------------------------
独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
Mail vuln-info@ipa.go.jp
Web https://www.ipa.go.jp/security/
PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iD8DBQFKzGVkXHq+Zql17D0RAtmLAKCAiPIMAIx8Q2vu7nQC4uOlxP6bzgCfSiyf
nKmZVQJJVAKjqWLU3Upug4w=
=+rR7
-----END PGP SIGNATURE-----


 

10/8 IPAへ



独立行政法人 情報処理推進機構 (IPA)  セキュリティセンター 御中

[ふぅみん]です。
ご丁寧に調査・ご説明ありがとうございます。

もし、最初から非SSLなサイトでしたら、納得していたかと思います。
しかし、今回の件に関しては、少々納得が出来かねますので、少し
書かせてください。

脆弱性というのは、企業のポリシーや法的な面を前提に考えな
ければならないものでしょうか?
「脅威」は企業のポリシーなどを考慮してくれるでしょうか?
「脆弱」かどうかという点は、「脅威」に対し考えるべきではな
いでしょうか?
また、「通信」自体の安全性は、レイヤーの異なる物理ネット
ワークの安全性を考慮しなければならないとも思えません。

そこで、まず、前提として、
・非SSL通信は盗聴に対して無防備であり、脆弱である。
ということを挙げておきます。

これにおいて、ネットワーク自体が「盗聴」に対し無防備であったり、
「盗聴」の設備があるかどうかという点は無視できます。
「通信」自体が「盗聴」という「脅威」に対して「脆弱」という事実
だけが存在するからです。

"最初から非SSLなサイトでしたら、納得していた"という件に関連
してもう一点の事実を挙げます。

・これまで(1ヵ月前まで)はSSL状態が保たれており、盗聴に対して
防御されており、脆弱ではなかった。

この事実は、単純に、「通信」が「盗聴」できる状態に移行した
とも言えます。

さらに、
・そこで通信される内容は、実際に「盗聴」された場合、
悪用される危険性のあるものです。
という点を加えます。

これまでSSLで暗号化されていた情報を無防備に「盗聴」の「危険」
に晒すことは、情報内容に変更が無い以上、「脆弱」化したと判断
できるのではないでしょうか?
これが、私が言いたいところの「盗聴」に対する「脆弱」化です。

そして、今回、「盗聴」に対する「脆弱」化を招いたのは、サー
ビス提供側による非SSL化に他ならないと思うのです。

職を離れて長く、あまりうまく書くことができず済みませんが、
一般に「脆弱」かどうかは「脅威」に対し防御力があるかどうか
で考えるべきだと思います。

この考えについて、ご意見をいただきたいと思います。
以上、よろしくお願いいたします。

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - -----------------------------------------------------------------
> このメールは、取扱い番号 IPA#60026469 に関する連絡です。
> - ----------------------------------------------------------------
>
> IPAセキュリティセンターです。
>
> ご質問にご回答いただき、ありがとうございました。
>
> 届出いただいた情報につきまして、内容を確認した結果、下記の判断理由
> の通り、本制度で定義する脆弱性に該当しないと判断し、取扱いを終了さ
> せていただきたいと考えておりますが、如何でしょうか。
> 取扱いを終了した場合でも、届出情報を参考情報としてウェブサイト運営者
> へ送付したいと考えております。
>
> 内容をご一読いただき、取扱いに問題があるようでしたら、10 営業日を
> 目途にご連絡をお願いします。
>
> 【判断理由】
> =================================================================
> セッション管理に関する情報や個人情報は、サービス利用者とサービス
> 提供者が共に第三者に漏れないように適切に管理する必要があります。
>
> 本件は、HTTP 通信でセッション管理情報や個人情報をやり取りしてい
> るためにその情報を第三者が取得できてしまう点が問題とされています。
> しかし、そのためには第三者が通信を「盗聴」できる環境である必要が
> あります。
>
> 上記を鑑みますと、根本的な原因は通信を盗聴できてしまうことであり、
> 対策すべき箇所は通信が盗聴できてしまうネットワークであると考えま
> す。届出内容を見ますと、発見者様のネットワーク上で(故意に)盗聴し
> たものとあるため、これはウェブサイト運営者が対策する問題ではない
> と考えます。
>
> ただ、サービス提供者との契約やプライバシーポリシー等で、通信を
> 暗号化する旨の記載がある場合は、その内容に従って適切に運用されて
> いない為、脆弱性として取り扱っております。
>
> 下記のウェブサイトの情報を確認しましたが、会員規約(第9章)や個人
> 情報保護ポリシーからは情報を暗号化する旨が明記されていませんでした。
>
> ◇会員規約:@nifty◇
>  http://www.nifty.com/policy/terms.htm
> ◇個人情報保護>個人情報保護ポリシー:@nifty◇
>  http://www.nifty.com/policy/privacy.htm
>
> その為、当該ウェブサイトは運営者が公表しているポリシーに沿って運用
> されていると考え、本制度で定義している脆弱性ではないと判断しました。
>
> しかし、発見者様が主張されております内容についても、十分に理解で
> きますので、届出頂いた情報については参考情報として運営者へ送付し
> たいと考えております。
>
> =================================================================
>
> 【告示およびガイドラインの該当箇所】
> =================================================================
> ●ソフトウエア等脆弱性関連情報取扱基準
> http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
> II.用語の定義
> 本基準で用いられる用語の定義は、以下のとおりとする。
> 1.脆弱性
> ソフトウエア等において、コンピュータウイルス、コンピュータ不正アク
> セス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の
> 問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者が
> アクセス制御機能により保護すべき情報等に誰もがアクセスできるような、
> 安全性が欠如している状態を含む。
>
> VI.対象がウェブアプリケーションである場合の脆弱性関連情報取扱基準
> 2.受付機関基準
> (2)受付機関は、届出を受理したときは、速やかに、当該ウェブサイト
> 運営者に対し当該脆弱性関連情報を通知すること。ただし、当該脆弱
> 性関連情報が以下に該当する場合、当該届出に係る処理を取りやめる
> ことができる。この場合においては、当該発見者にその旨及び
> その理由を通知すること。
> 3)受付機関が脆弱性関連情報に該当しないと確認した場合
>
> ●情報セキュリティ早期警戒パートナーシップガイドライン
> https://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
> II. 用語の定義と前提
>
> 1.脆弱性の定義
> 脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、
> コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、
> その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。
> なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適
> 切な運用によって、個人情報等が適切なアクセス制御の下に管理され
> ておらずセキュリティが維持できなくなっている状態も含みます。
> (ウェブサイトの不適切な運用に関しては付録4に示します。)
>
> V.ウェブアプリケーションに係る脆弱性関連情報取扱
> 3.IPA の対応
> 4) 脆弱性関連情報への対応続行の判断
> IPA は、以下の条件のいずれかと合致した場合、処理を取りやめるとともに発
> 見者に連絡します。
> (ア) IPA が脆弱性関連情報でないと確認した場合
> =================================================================
>
> 以上、よろしくお願いいたします。
>
> ------------------------------
> 脆弱性情報に関する連絡を行う際には、PGP公開鍵による
> 暗号化をお願いいたします。
> https://www.ipa.go.jp/security/pgp/index.html
> ------------------------------
> 独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
> Mail vuln-info@ipa.go.jp
> Web https://www.ipa.go.jp/security/
> PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
> ------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
>
> iD8DBQFKzGVkXHq+Zql17D0RAtmLAKCAiPIMAIx8Q2vu7nQC4uOlxP6bzgCfSiyf
> nKmZVQJJVAKjqWLU3Upug4w=
> =+rR7
> -----END PGP SIGNATURE-----
>


 

10/14 IPAから



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ------------------------------------------------------------------
このメールは、取扱い番号 IPA#60026469 に関する連絡です。
- -----------------------------------------------------------------

IPAセキュリティセンターです。

ご連絡いただきまして、ありがとうございます。ご意見いただいた内容を
踏まえて、再度検討しましたが、本枠組みで定義する脆弱性では無いとの
判断に至りました。

内容をご一読いただき、取扱いに問題がありましたら、10 営業日を目途
にご連絡をお願いします。

【判断理由】
============================================================
今回、頂いたご意見を要約すると、下記2点の論点があると考えております。
それぞれに分けて見解を述べさせていただきます。

■脆弱性の判断について
> 脆弱性というのは、企業のポリシーや法的な面を前提に考えな
> ければならないものでしょうか?
> 「脅威」は企業のポリシーなどを考慮してくれるでしょうか?
> 「脆弱」かどうかという点は、「脅威」に対し考えるべきではな
> いでしょうか?

IPA では、文末に転記しました「早期警戒パートナーシップ」の脆弱性
の定義に基づいて、届出情報の脆弱性判断をしております。

仰る通り、HTTP より HTTPS を実装した方が、盗聴のリスクが小さくなり、
より安全な通信が行えます。ただ、ご意見にある"脆弱"という表現は、ウ
ェブサイトの機能や性能を損なう要因ではなく、セキュリティの強度だと
考ます。

本枠組みでは、セキュリティの強度が低い、もしくは現在よりも高くでき
ることだけを根拠に脆弱性の判断はしておりません。

また、ウェブサイトの運営に関して、HTTPS を強制する規定・規則はなく、
HTTPS の実装の可否はウェブサイトの運用ポリシーによるものになります。

当該サイトに関しては、「会員規約」や「個人情報保護ポリシー」を利用
者に向けて公開しており、そのポリシーに反した運用は行っていない為、
不適切な運用にも該当しないと判断します。

上記の点より届出内容については、本枠組みで定義する脆弱性ではないと
判断しております。

■以前と仕様が変わった件について
> ・これまで(1ヵ月前まで)はSSL状態が保たれており、盗聴に対して
> 防御されており、脆弱ではなかった。

発見者様が仰る通りならば、運営者側の利用者への配慮が足りていなかった
ものと思われます。しかしながら、この点はサービスの内容に関する問題
であり、ウェブアプリケーションの脆弱性に係る情報では無いと考えます。

ただ、発見者様の言われていることも、十分に理解できますので、届出
情報については、参考情報として運営者へ送付したいと考えております。

============================================================

【告示およびガイドラインの該当箇所】
=================================================================
●ソフトウエア等脆弱性関連情報取扱基準
http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
II.用語の定義
本基準で用いられる用語の定義は、以下のとおりとする。
1.脆弱性
ソフトウエア等において、コンピュータウイルス、コンピュータ不正アク
セス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の
問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者が
アクセス制御機能により保護すべき情報等に誰もがアクセスできるような、
安全性が欠如している状態を含む。

●情報セキュリティ早期警戒パートナーシップガイドライン
https://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
II. 用語の定義と前提

1.脆弱性の定義
脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、
コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、
その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。
なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適
切な運用によって、個人情報等が適切なアクセス制御の下に管理され
ておらずセキュリティが維持できなくなっている状態も含みます。
(ウェブサイトの不適切な運用に関しては付録4に示します。)
=================================================================

以上、よろしくお願いします。

------------------------------
脆弱性情報に関する連絡を行う際には、PGP公開鍵による
暗号化をお願いいたします。
https://www.ipa.go.jp/security/pgp/index.html
------------------------------
独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
Mail vuln-info@ipa.go.jp
Web https://www.ipa.go.jp/security/
PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iD8DBQFK1ZdxXHq+Zql17D0RAosQAJ9Jr3LHvyFgV6f1OUmQaIcXy9zgqwCdEGgR
ZsOwFmkxPGqc+PrW3gEcw9Q=
=289t
-----END PGP SIGNATURE-----


 

10/14 IPAへ



独立行政法人 情報処理推進機構 (IPA)  セキュリティセンター 御中

[ふぅみん]です。
ご検討ありがとうございます。
ユーザよりも運営側が優遇されているように読めてしまい、少々諦め気味です。

お手数をおかけして申し訳ございませんが、何点か確認させてください。
・ポリシーで明記していれば、事前通告なく、認証画面や他の同社関連サイト
(WEBメール等)のSSL暗号化がなくなったとしてもサイト運営側に脆弱性
は無いのでしょうか?
・仮に、何らかの被害が発生した場合、盗聴が原因である、あるいは原因でない
という明確な判断は可能でしょうか?
・サイト運営側には脆弱性がないのであれば、盗聴が原因の被害を発生させない
ためには、ユーザとして、どのような対応が可能でしょうか?
たとえば、公衆無線回線などを利用した場合、どの経路で通信するか分から
ない以上、盗聴が無いと断言できません。
・届け出対象のサイトですが、通信経路上でリクエストパケットのみを盗聴し、
なり済ましによるレスポンス取得が可能であることは確認済みです。
以下未検証ですが、恐らく、認証後のセッションおよびアクセス制御は
Cookieのみで行われていると思われます。
各管理情報にアクセスするためのURLもユーザによらず固定のようですので、
Cookieさえ盗聴できれば、サイト内の全データを取得するのはそれほど
難しいことではないと思います。
また、同様に設定変更も不可能ではないと考えております。
→これにより、サイトの機能や性能に影響を与えることが可能だと考えます。
シングルサインオン用のセッションIDもCookieに含まれているようですので、
他の同社関連サイト(たとえば現状SSL暗号化されているWEBメール等)への
アクセスも可能となる恐れがあるとも考えております。
もし、そうだった場合のことを知るのが嫌なのと、SSL通信を解析・実装
するのが少々手間なので、検証せずにおります。
IPA様側ではどのあたりまでの可能性や検証を踏まえてご検討くださった
のでしょうか?
以上、お答えいただければ幸いです。

1点。
> 仰る通り、HTTP より HTTPS を実装した方が、盗聴のリスクが小さくなり、
これは誤りだと思います。
盗聴という行為に対しては、HTTPだろうがHTTPSだろうが関係ありません。
ただ、盗聴したあと、HTTPの場合は復号化の必要が無いということです。
つまり、復号化コストが0ということです。HTTPSの場合の復号化コストは
不明ですが、0よりはるかに大きいはずです。つまり、大小ではなく、
無か有かという話になると思います。
HTTPは盗聴に対する危険性を考慮しておらず(無)、HTTPSは考慮している
(有)ということになると思います。
私は、危険性の考慮を忘れていることは脆弱であると考えております。

以上、よろしくお願いいたします。

----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - ------------------------------------------------------------------
> このメールは、取扱い番号 IPA#60026469 に関する連絡です。
> - -----------------------------------------------------------------
>
> IPAセキュリティセンターです。
>
> ご連絡いただきまして、ありがとうございます。ご意見いただいた内容を
> 踏まえて、再度検討しましたが、本枠組みで定義する脆弱性では無いとの
> 判断に至りました。
>
> 内容をご一読いただき、取扱いに問題がありましたら、10 営業日を目途
> にご連絡をお願いします。
>
> 【判断理由】
> ============================================================
> 今回、頂いたご意見を要約すると、下記2点の論点があると考えております。
> それぞれに分けて見解を述べさせていただきます。
>
> ■脆弱性の判断について
> > 脆弱性というのは、企業のポリシーや法的な面を前提に考えな
> > ければならないものでしょうか?
> > 「脅威」は企業のポリシーなどを考慮してくれるでしょうか?
> > 「脆弱」かどうかという点は、「脅威」に対し考えるべきではな
> > いでしょうか?
>
> IPA では、文末に転記しました「早期警戒パートナーシップ」の脆弱性
> の定義に基づいて、届出情報の脆弱性判断をしております。
>
> 仰る通り、HTTP より HTTPS を実装した方が、盗聴のリスクが小さくなり、
> より安全な通信が行えます。ただ、ご意見にある"脆弱"という表現は、ウ
> ェブサイトの機能や性能を損なう要因ではなく、セキュリティの強度だと
> 考ます。
>
> 本枠組みでは、セキュリティの強度が低い、もしくは現在よりも高くでき
> ることだけを根拠に脆弱性の判断はしておりません。
>
> また、ウェブサイトの運営に関して、HTTPS を強制する規定・規則はなく、
> HTTPS の実装の可否はウェブサイトの運用ポリシーによるものになります。
>
> 当該サイトに関しては、「会員規約」や「個人情報保護ポリシー」を利用
> 者に向けて公開しており、そのポリシーに反した運用は行っていない為、
> 不適切な運用にも該当しないと判断します。
>
> 上記の点より届出内容については、本枠組みで定義する脆弱性ではないと
> 判断しております。
>
> ■以前と仕様が変わった件について
> > ・これまで(1ヵ月前まで)はSSL状態が保たれており、盗聴に対して
> > 防御されており、脆弱ではなかった。
>
> 発見者様が仰る通りならば、運営者側の利用者への配慮が足りていなかった
> ものと思われます。しかしながら、この点はサービスの内容に関する問題
> であり、ウェブアプリケーションの脆弱性に係る情報では無いと考えます。
>
> ただ、発見者様の言われていることも、十分に理解できますので、届出
> 情報については、参考情報として運営者へ送付したいと考えております。
>
> ============================================================
>
> 【告示およびガイドラインの該当箇所】
> =================================================================
> ●ソフトウエア等脆弱性関連情報取扱基準
> http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
> II.用語の定義
> 本基準で用いられる用語の定義は、以下のとおりとする。
> 1.脆弱性
> ソフトウエア等において、コンピュータウイルス、コンピュータ不正アク
> セス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の
> 問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者が
> アクセス制御機能により保護すべき情報等に誰もがアクセスできるような、
> 安全性が欠如している状態を含む。
>
> ●情報セキュリティ早期警戒パートナーシップガイドライン
> https://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
> II. 用語の定義と前提
>
> 1.脆弱性の定義
> 脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、
> コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、
> その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。
> なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適
> 切な運用によって、個人情報等が適切なアクセス制御の下に管理され
> ておらずセキュリティが維持できなくなっている状態も含みます。
> (ウェブサイトの不適切な運用に関しては付録4に示します。)
> =================================================================
>
> 以上、よろしくお願いします。
>
> ------------------------------
> 脆弱性情報に関する連絡を行う際には、PGP公開鍵による
> 暗号化をお願いいたします。
> https://www.ipa.go.jp/security/pgp/index.html
> ------------------------------
> 独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
> Mail vuln-info@ipa.go.jp
> Web https://www.ipa.go.jp/security/
> PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
> ------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
>
> iD8DBQFK1ZdxXHq+Zql17D0RAosQAJ9Jr3LHvyFgV6f1OUmQaIcXy9zgqwCdEGgR
> ZsOwFmkxPGqc+PrW3gEcw9Q=
> =289t
> -----END PGP SIGNATURE-----


 

10/27 IPAへ



独立行政法人 情報処理推進機構 (IPA)  セキュリティセンター 御中

[ふぅみん]です。
前回のメールより10日(除:土日)になるため、確認のためにメールいたします。
本件の取扱い状況についてお教えいただければと思います。

以上、よろしくお願いいたします。

----- Original Message -----
> 独立行政法人 情報処理推進機構 (IPA) セキュリティセンター 御中
>
> [ふぅみん]です。
> ご検討ありがとうございます。
> ユーザよりも運営側が優遇されているように読めてしまい、少々諦め気味です。
>
> お手数をおかけして申し訳ございませんが、何点か確認させてください。
> ・ポリシーで明記していれば、事前通告なく、認証画面や他の同社関連サイト
> (WEBメール等)のSSL暗号化がなくなったとしてもサイト運営側に脆弱性
> は無いのでしょうか?
> ・仮に、何らかの被害が発生した場合、盗聴が原因である、あるいは原因でない
> という明確な判断は可能でしょうか?
> ・サイト運営側には脆弱性がないのであれば、盗聴が原因の被害を発生させない
> ためには、ユーザとして、どのような対応が可能でしょうか?
> たとえば、公衆無線回線などを利用した場合、どの経路で通信するか分から
> ない以上、盗聴が無いと断言できません。
> ・届け出対象のサイトですが、通信経路上でリクエストパケットのみを盗聴し、
> なり済ましによるレスポンス取得が可能であることは確認済みです。
> 以下未検証ですが、恐らく、認証後のセッションおよびアクセス制御は
> Cookieのみで行われていると思われます。
> 各管理情報にアクセスするためのURLもユーザによらず固定のようですので、
> Cookieさえ盗聴できれば、サイト内の全データを取得するのはそれほど
> 難しいことではないと思います。
> また、同様に設定変更も不可能ではないと考えております。
> →これにより、サイトの機能や性能に影響を与えることが可能だと考えます。
> シングルサインオン用のセッションIDもCookieに含まれているようですので、
> 他の同社関連サイト(たとえば現状SSL暗号化されているWEBメール等)への
> アクセスも可能となる恐れがあるとも考えております。
> もし、そうだった場合のことを知るのが嫌なのと、SSL通信を解析・実装
> するのが少々手間なので、検証せずにおります。
> IPA様側ではどのあたりまでの可能性や検証を踏まえてご検討くださった
> のでしょうか?
> 以上、お答えいただければ幸いです。
>
> 1点。
> > 仰る通り、HTTP より HTTPS を実装した方が、盗聴のリスクが小さくなり、
> これは誤りだと思います。
> 盗聴という行為に対しては、HTTPだろうがHTTPSだろうが関係ありません。
> ただ、盗聴したあと、HTTPの場合は復号化の必要が無いということです。
> つまり、復号化コストが0ということです。HTTPSの場合の復号化コストは
> 不明ですが、0よりはるかに大きいはずです。つまり、大小ではなく、
> 無か有かという話になると思います。
> HTTPは盗聴に対する危険性を考慮しておらず(無)、HTTPSは考慮している
> (有)ということになると思います。
> 私は、危険性の考慮を忘れていることは脆弱であると考えております。
>
> 以上、よろしくお願いいたします。
>
> ----- Original Message -----
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > - ------------------------------------------------------------------
> > このメールは、取扱い番号 IPA#60026469 に関する連絡です。
> > - -----------------------------------------------------------------
> >
> > IPAセキュリティセンターです。
> >
> > ご連絡いただきまして、ありがとうございます。ご意見いただいた内容を
> > 踏まえて、再度検討しましたが、本枠組みで定義する脆弱性では無いとの
> > 判断に至りました。
> >
> > 内容をご一読いただき、取扱いに問題がありましたら、10 営業日を目途
> > にご連絡をお願いします。
> >
> > 【判断理由】
> > ============================================================
> > 今回、頂いたご意見を要約すると、下記2点の論点があると考えております。
> > それぞれに分けて見解を述べさせていただきます。
> >
> > ■脆弱性の判断について
> > > 脆弱性というのは、企業のポリシーや法的な面を前提に考えな
> > > ければならないものでしょうか?
> > > 「脅威」は企業のポリシーなどを考慮してくれるでしょうか?
> > > 「脆弱」かどうかという点は、「脅威」に対し考えるべきではな
> > > いでしょうか?
> >
> > IPA では、文末に転記しました「早期警戒パートナーシップ」の脆弱性
> > の定義に基づいて、届出情報の脆弱性判断をしております。
> >
> > 仰る通り、HTTP より HTTPS を実装した方が、盗聴のリスクが小さくなり、
> > より安全な通信が行えます。ただ、ご意見にある"脆弱"という表現は、ウ
> > ェブサイトの機能や性能を損なう要因ではなく、セキュリティの強度だと
> > 考ます。
> >
> > 本枠組みでは、セキュリティの強度が低い、もしくは現在よりも高くでき
> > ることだけを根拠に脆弱性の判断はしておりません。
> >
> > また、ウェブサイトの運営に関して、HTTPS を強制する規定・規則はなく、
> > HTTPS の実装の可否はウェブサイトの運用ポリシーによるものになります。
> >
> > 当該サイトに関しては、「会員規約」や「個人情報保護ポリシー」を利用
> > 者に向けて公開しており、そのポリシーに反した運用は行っていない為、
> > 不適切な運用にも該当しないと判断します。
> >
> > 上記の点より届出内容については、本枠組みで定義する脆弱性ではないと
> > 判断しております。
> >
> > ■以前と仕様が変わった件について
> > > ・これまで(1ヵ月前まで)はSSL状態が保たれており、盗聴に対して
> > > 防御されており、脆弱ではなかった。
> >
> > 発見者様が仰る通りならば、運営者側の利用者への配慮が足りていなかった
> > ものと思われます。しかしながら、この点はサービスの内容に関する問題
> > であり、ウェブアプリケーションの脆弱性に係る情報では無いと考えます。
> >
> > ただ、発見者様の言われていることも、十分に理解できますので、届出
> > 情報については、参考情報として運営者へ送付したいと考えております。
> >
> > ============================================================
> >
> > 【告示およびガイドラインの該当箇所】
> > =================================================================
> > ●ソフトウエア等脆弱性関連情報取扱基準
> > http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
> > II.用語の定義
> > 本基準で用いられる用語の定義は、以下のとおりとする。
> > 1.脆弱性
> > ソフトウエア等において、コンピュータウイルス、コンピュータ不正アク
> > セス等の攻撃によりその機能や性能を損なう原因となり得る安全性上の
> > 問題箇所。ウェブアプリケーションにあっては、ウェブサイト運営者が
> > アクセス制御機能により保護すべき情報等に誰もがアクセスできるような、
> > 安全性が欠如している状態を含む。
> >
> > ●情報セキュリティ早期警戒パートナーシップガイドライン
> > https://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
> > II. 用語の定義と前提
> >
> > 1.脆弱性の定義
> > 脆弱性とは、ソフトウエア製品やウェブアプリケーション等において、
> > コンピュータ不正アクセスやコンピュータウイルス等の攻撃により、
> > その機能や性能を損なう原因となり得るセキュリティ上の問題箇所です。
> > なお、ウェブアプリケーションにおいて、ウェブサイト運営者の不適
> > 切な運用によって、個人情報等が適切なアクセス制御の下に管理され
> > ておらずセキュリティが維持できなくなっている状態も含みます。
> > (ウェブサイトの不適切な運用に関しては付録4に示します。)
> > =================================================================
> >
> > 以上、よろしくお願いします。
> >
> > ------------------------------
> > 脆弱性情報に関する連絡を行う際には、PGP公開鍵による
> > 暗号化をお願いいたします。
> > https://www.ipa.go.jp/security/pgp/index.html
> > ------------------------------
> > 独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
> > Mail vuln-info@ipa.go.jp
> > Web https://www.ipa.go.jp/security/
> > PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
> > ------------------------------
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.8 (MingW32)
> >
> > iD8DBQFK1ZdxXHq+Zql17D0RAosQAJ9Jr3LHvyFgV6f1OUmQaIcXy9zgqwCdEGgR
> > ZsOwFmkxPGqc+PrW3gEcw9Q=
> > =289t
> > -----END PGP SIGNATURE-----


 

10/ IPAから



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- ------------------------------------------------------------------
このメールは、取扱い番号 IPA#60026469 に関する連絡です。
- ------------------------------------------------------------------

IPAセキュリティセンターです。

返信が遅くなり、申し訳ございません。

頂いたご意見を踏まえまして、本枠組みの概要を説明させていただいた上で、
取扱い方針について相談させてください。

まず、本枠組みですが、「ソフトウエア製品」と「ウェブアプリケーション」
の届出を受付けております。今回届けられたウェブアプリケーションに係る
本枠組みの概要を以下に説明いたします。

【本枠組みの概要】
================================================================
IPA では情報セキュリティ対策の一環として、経済産業省告示に従い、
一般の方や研究者の方が発見された、ウェブページのセキュリティ上の
問題点の届出を受けつけ、ウェブサイト運営者の方に連絡し、修正を促
しております。ただ、脆弱性修正に関しては、IPA から修正を促します
が、強制力を持つものではない為、最終的な対応の可否は運営者の判断
になります。

本枠組みでは、下記のような問題をウェブアプリケーションの脆弱性とし
て取り扱っております。

・XSS や SQL インジェクション等のウェブアプリケーションのセキュ
リティ上の実装不備に起因する問題
・ウェブサイト上で個人情報を含むファイルがアクセス制限なしに公開
 されている等のウェブサイト運営者の不適切な運用

詳細は、下記をご参照ください。
- ----------------------------------------------------------------
●経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」
 http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf

●情報セキュリティ早期警戒パートナーシップガイドライン
http://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
- ----------------------------------------------------------------

IPA では上記の告示およびガイドラインに基づき脆弱性関連情報を適切
に流通し、ウェブサイト運営者へ修正を促しております。しかし、ウェブ
サイトの運営方針やサービス内容の変更については、本枠組で対処できる
範囲外となります。
================================================================

上記の内容を踏まえまして、本件の取扱い方針について説明いたします。

【取扱い方針の相談】
================================================================
届出頂いた内容は、盗聴に対する危険性を踏まえて、利用者に事前通告
なく HTTPS でなくなった点を指摘されているものと考えます。

ただ、この点については、過日連絡した理由の通り、ウェブサイト運営
者の不適切な運用には該当せず、ウェブサイトの運営方針やサービス内
容(レベル)に関する問題と捉えております。

そのため、本枠組みでの取扱うべき脆弱性の定義外と判断しております。

ただ、届出頂いた情報は、サービスの内容に関する問題(※1)であると
考えますが、発見者様の言われていることも、十分に理解できますので、
本枠組みとは別に参考情報として運営者へ送付したいと考えております。

※1
HTTPS を使うためには、そのドメインにおける SSL サーバ証明書の取
得や管理、SSL によるサーバ負荷の対応等に費用が発生するため、運用
方針やサービス内容を決定する一要因であると考えます。
================================================================

過日連絡した内容を含めまして、当該ウェブサイトにおいて IPA が調査
した内容において間違いがありましたら、10営業日を目途にご連絡をお
願いします。

ご期待に添えず申し訳ございません。
以上、宜しくお願いします。

------------------------------
脆弱性情報に関する連絡を行う際には、PGP公開鍵による
暗号化をお願いいたします。
https://www.ipa.go.jp/security/pgp/index.html
------------------------------
独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
Mail vuln-info@ipa.go.jp
Web https://www.ipa.go.jp/security/
PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iD8DBQFK5tI5XHq+Zql17D0RAoN8AJ44D9SHOsFeIBb47Y942uhnO/rnkQCeLxD/
bbGLiMclhg7eApdO7G8cZZA=
=hEFC
-----END PGP SIGNATURE-----


 

10/27 IPAへ



独立行政法人 情報処理推進機構 (IPA)  セキュリティセンター 御中

[ふぅみん]です。
いろいろ知らないことが多く、公開したほうがいいと私は判断しますので、
本件はブログ記事にしたいと思います。問題があれば24時間以内に返信ください。
また、前回の問い合わせには全く触れていない点も併せて記載したいと思います。
未回答部分に関しては、憶測も含めて記載しますこと、ご了承ください。

期待してはいけないということは大変よくわかりました(秋の情報処理試験を
受けなくてよかったと思います)し、あまり長引かせたくありませんので、
当方よりのメールはこれで最後にいたします。

ご報告をお願いいたします。

その際、Nifty側ではログイン認識にCookieを使用すると明記しており、
これが盗まれる危険性についてもいくらかは認識していると判断できます。
(他サービスですが) http://my.nifty.com/my/html/notice.htm
その範囲がクライアントPC以外にもあるという認識が欠如しているという点も
あわせてご指摘いただければと思います。
#むしろこちらを悪用された場合の被害の方が大きいと思います。

なお、暗号化を行うだけであれば、オレオレ証明書で十分なはずですし、それを
有効化するように証明書インストールを求めることもできると思います。
しかし、実際にはSSLポートは生きており、証明書は今も存在するようです。
さらに、同一ホスト名にも関わらず、XML-RPC APIだけはSSLで公開されています。
そういったことを考えると、費用面やサーバ負荷という指摘も的外れかと思われます。
#ということを加味すると、IPA様側でも、本件に関する十分な検証がなされている
とは思えないというのが私の見解です。

以上です。
----- Original Message -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> - ------------------------------------------------------------------
> このメールは、取扱い番号 IPA#60026469 に関する連絡です。
> - ------------------------------------------------------------------
>
> IPAセキュリティセンターです。
>
> 返信が遅くなり、申し訳ございません。
>
> 頂いたご意見を踏まえまして、本枠組みの概要を説明させていただいた上で、
> 取扱い方針について相談させてください。
>
> まず、本枠組みですが、「ソフトウエア製品」と「ウェブアプリケーション」
> の届出を受付けております。今回届けられたウェブアプリケーションに係る
> 本枠組みの概要を以下に説明いたします。
>
> 【本枠組みの概要】
> ================================================================
> IPA では情報セキュリティ対策の一環として、経済産業省告示に従い、
> 一般の方や研究者の方が発見された、ウェブページのセキュリティ上の
> 問題点の届出を受けつけ、ウェブサイト運営者の方に連絡し、修正を促
> しております。ただ、脆弱性修正に関しては、IPA から修正を促します
> が、強制力を持つものではない為、最終的な対応の可否は運営者の判断
> になります。
>
> 本枠組みでは、下記のような問題をウェブアプリケーションの脆弱性とし
> て取り扱っております。
>
> ・XSS や SQL インジェクション等のウェブアプリケーションのセキュ
> リティ上の実装不備に起因する問題
> ・ウェブサイト上で個人情報を含むファイルがアクセス制限なしに公開
>  されている等のウェブサイト運営者の不適切な運用
>
> 詳細は、下記をご参照ください。
> - ----------------------------------------------------------------
> ●経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」
>  http://www.meti.go.jp/policy/netsecurity/downloadfiles/vulhandlingG.pdf
>
> ●情報セキュリティ早期警戒パートナーシップガイドライン
> http://www.ipa.go.jp/security/ciadr/partnership_guide.pdf
> - ----------------------------------------------------------------
>
> IPA では上記の告示およびガイドラインに基づき脆弱性関連情報を適切
> に流通し、ウェブサイト運営者へ修正を促しております。しかし、ウェブ
> サイトの運営方針やサービス内容の変更については、本枠組で対処できる
> 範囲外となります。
> ================================================================
>
> 上記の内容を踏まえまして、本件の取扱い方針について説明いたします。
>
> 【取扱い方針の相談】
> ================================================================
> 届出頂いた内容は、盗聴に対する危険性を踏まえて、利用者に事前通告
> なく HTTPS でなくなった点を指摘されているものと考えます。
>
> ただ、この点については、過日連絡した理由の通り、ウェブサイト運営
> 者の不適切な運用には該当せず、ウェブサイトの運営方針やサービス内
> 容(レベル)に関する問題と捉えております。
>
> そのため、本枠組みでの取扱うべき脆弱性の定義外と判断しております。
>
> ただ、届出頂いた情報は、サービスの内容に関する問題(※1)であると
> 考えますが、発見者様の言われていることも、十分に理解できますので、
> 本枠組みとは別に参考情報として運営者へ送付したいと考えております。
>
> ※1
> HTTPS を使うためには、そのドメインにおける SSL サーバ証明書の取
> 得や管理、SSL によるサーバ負荷の対応等に費用が発生するため、運用
> 方針やサービス内容を決定する一要因であると考えます。
> ================================================================
>
> 過日連絡した内容を含めまして、当該ウェブサイトにおいて IPA が調査
> した内容において間違いがありましたら、10営業日を目途にご連絡をお
> 願いします。
>
> ご期待に添えず申し訳ございません。
> 以上、宜しくお願いします。
>
> ------------------------------
> 脆弱性情報に関する連絡を行う際には、PGP公開鍵による
> 暗号化をお願いいたします。
> https://www.ipa.go.jp/security/pgp/index.html
> ------------------------------
> 独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
> Mail vuln-info@ipa.go.jp
> Web https://www.ipa.go.jp/security/
> PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
> ------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (MingW32)
>
> iD8DBQFK5tI5XHq+Zql17D0RAoN8AJ44D9SHOsFeIBb47Y942uhnO/rnkQCeLxD/
> bbGLiMclhg7eApdO7G8cZZA=
> =hEFC
> -----END PGP SIGNATURE-----


 

10/28 IPAから



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -------------------------------------------------------------------
このメールは、取扱い番号 IPA#60026469 に関する連絡です。
- -------------------------------------------------------------------

IPAセキュリティセンターです。

ブログへの掲載可否につきましては、当機構で判断できるものではござい
ませんので、発見者様の責任下でご判断ください。

なお、未回答部分とございました点については、頂いた質問を考慮した上で、
脆弱性の判断理由として回答させていただいております。

> そういったことを考えると、費用面やサーバ負荷という指摘も的外れかと思われます。
> #ということを加味すると、IPA様側でも、本件に関する十分な検証がなされている
> とは思えないというのが私の見解です。

上記の費用面に絡んだ例については、あくまで一般的な事例を示したもので、
届出のウェブサイトに特化したものではございません。
誤解を与えてしまい、申し訳ございません。

本件については、取扱いを終了させていただきますが、宜しいでしょうか。

取扱いを終了した場合でも、届出情報につきましては、参考情報として
運営者へ送付させていただきます。

取扱いに問題があるようでしたら、10営業日を目途にご連絡をお願いします。

以上、宜しくお願いします。

------------------------------
脆弱性情報に関する連絡を行う際には、PGP公開鍵による
暗号化をお願いいたします。
https://www.ipa.go.jp/security/pgp/index.html
------------------------------
独立行政法人 情報処理推進機構 (IPA) セキュリティセンター
Mail vuln-info@ipa.go.jp
Web https://www.ipa.go.jp/security/
PGP AA98 654C 16E1 DBD9 8B36 3680 5C7A BE66 A975 EC3D
------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)

iD8DBQFK6AkRXHq+Zql17D0RAlJaAJ409NuxaQ0cqtjsuP32bIl2f53SYwCcCkRQ
TLifB8/9YYyUjvJG4TDsFEc=
=Bglm
-----END PGP SIGNATURE-----


 

ここまで。

セキュリティレベルでも脆弱性でもなんでもいいんだけど、情報を扱う上での安全を啓蒙する本拠が安全でないものを放置できちゃうって、一体どういうことだろう。

|

« 終焉ノ参~救イの無い世界~ | トップページ | 終焉ノ悟~全テ偽リと悟るトキ~ »

ウェブログ・ココログ関連」カテゴリの記事

パソコン・インターネット」カテゴリの記事

日記・コラム・つぶやき」カテゴリの記事

コメント

この記事へのコメントは終了しました。