脆弱性報告制度 << mixi Developer Center (ミクシィ デベロッパーセンター)
株式会社ミクシィは、お客様に安心してご利用いただけるサービスを提供するため、脆弱性に関する報告の重要性を認識しております。より安全なサービスの実現を目指し、脆弱性報告に対して、正当な対価をお支払いすることを目標に、脆弱性報告制度を開始しましたので、ご案内いたします。 概要 弊社のサービスにおいて、脆弱性を発見した場合に、窓口にご報告いただき、その重要度によって、報酬をお支払いする制度です。 対象 本制度は、株式会社ミクシィとその子会社がリリースした、ウェブアプリケーションおよびクライアントアプリケーションの脆弱性を対象とします。 ただし、次に該当するものは含まれません。 既に公表されている脆弱性 弊社にとって既知の脆弱性 報告されてから修正が完了する前に公表された脆弱性 攻撃が成立する可能性が著しく低いと考えられる脆弱性 原理的に修正が不可能な脆弱性 本制度の期間外に報告された脆弱性 窓口
HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
