[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > 脆弱性届出状況2005年Q1

脆弱性届出状況2005年Q1

2005年4月19日(火曜日)

脆弱性届出状況2005年Q1

更新: 2005年11月1日

2005年 Q1 の脆弱性届出状況が公表されました。

今四半期中に、製品開発者により脆弱性ではないと判断されたもの、不受理としたものはありませんでした。

以上、ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第1四半期（1月～3月）] より

「不受理とした」ものはあるような気がしますが、その後に「やっぱり脆弱性として取り扱うことにしました」といって受理された場合には不受理にはカウントされないということなのでしょうね。まあそりゃそうか。

ウェブアプリケーションの方では、「新しい」脆弱性として CSRF について言及されています。

「クロスサイト・リクエスト・フォージェリ」は、ウェブサイトにアクセスすると自動的にログインするような機能を悪用して、そのウェブサイトの正規の利用者に対し、ユーザ登録内容の変更や意図しない商品購入などをさせるものです。「クロスサイト・リクエスト・フォージェリ」の対策としては、悪用しにくいユーザ登録フォームや商品購入フォームを設計する9ことなどが挙げられます。

(～中略～)

9 この攻撃ではHTTP のGETメソッドが使われることが多いため、フォームの処理にPOSTメソッドのみを使用することで、悪用されにくくなります。

いや、その注釈はちょっと……。POST メソッドで踏ませるのも難しいことではないと思いますし。Internet Watch の方では

CSRF対策には、リファラーのチェックを行なうなどのWebサイト作成者や管理者による処置が必要だ。

以上、SSIインジェクションやCSRFなどの新たな問題も～IPAの脆弱性届出状況 より

となっていて、こちらはまあ問題ないと思いますが。

※CSRF に関して、個人的には「パスワードを変更するようなフォームでは、必ず同時に旧パスワードを入力させるべし」というのを強く訴えたいところですね。そうでないパスワード変更フォームが CSRF で攻撃されると何が起きるのかはすぐ分かると思いますが、同時に旧パスワードを入力する必要があれば大丈夫です。

※2005-11-01 追記: 私が届け出ていた問題は修正されました。CSRF 直った参照。

面白いことに、脆弱性の類型にこんなものがあります。

HTTPSの不適切な 利用

HTTPSによる暗号化をしているが、ユーザへの説明に間違いがある、または、ウェブサイトの設計上、ユーザから証明書が確認できない

以上、ソフトウエア等の脆弱性関連情報に関する届出状況 [2005年第1四半期（1月～3月）] より

いや、私もこれは脆弱性なのかどうか微妙だと思ったのですが、試しに届け出てみたらあっさり受理されたという。

関連する話題: セキュリティ / IPA / JPCERT/CC / CSRF / 情報セキュリティ早期警戒パートナーシップ

最近の日記

関わった本など