HTTPSを使ってもCookieの改変は防げないことを実験で試してみた
寺田さんのブログエントリ「他人のCookieを操作する」には、通信路上の攻撃者がいる場合は、SSLを使っても、Cookieの盗聴を防ぐことはできるが、Cookieの改変を防ぐことはできないと指摘されています。いかにも寺田さんらしい簡にして要を得たエントリで、これに付け加えることはあまりないのですが、残念ながらまだ読んでいない人が多そうだと言うことと、より広い読者に向けて具体的に説明した方がよいだろうと考えました。 そこで、通信路上に攻撃者がいる典型例として、公衆無線LANの偽AP（アクセスポイント）があるケースを題材として、「HTTPSを使ってもCookieの改変は防げない」ことを説明します（Secure属性使うと盗聴は防げますが、改変は防げません）。長いエントリなので結論を先に書いておきます。 Secure属性がないCookieはHTTPSでも盗聴できる Cookieの改変についてはSe
HTML5関連のセキュリティ情報 - 葉っぱ日記
HTML5に関連したセキュリティの話題で、とりあえずこれまでに話した資料の一覧や、考察した記事。今後もっと増える予定です。「このAPI使う上で気を付けることないの？」みたいなリクエストもあればぜひ言って下さいませ。 JavaScript Security beyond HTML5 (2013-09-20 Developers Summit Kansai 2013) HTML5セキュリティ その1:基礎編、XSS編 (2013-06-13 OWASP Night 6th) Web::Security beyond HTML5 (2012-09-28 YAPC::Asia 2012) HTML5時代のWebセキュリティ (2012-09-15 第5回愛媛情報セキュリティ勉強会) Same-Origin Policy とは何なのか。 - 葉っぱ日記 XMLHttpRequestを使ったCSRF対
Masato Kinugawa Security Blog: U+2028/2029とDOM based XSS
ECMAScriptの仕様では、0x0A/0x0D以外にU+2028/2029の文字も改行とすることが明記されています。 これはあまり知られていないように思います。 以下はアラートを出します。 <script> //[U+2028]alert(1) </script> 知られていないだけでなく、知っていたとしても、スクリプトで文字列を処理するときに、U+2028/2029まで考慮する開発者がどれだけいるのかという話です。 実際、U+2028/2029を放り込むと文字列リテラル内にその文字が生のまま配置され、エラーが出るページは本当にたくさんあります。まあ、エラーがでるだけなら、大抵の場合大きな問題にはなりません。 ところが、U+2028/2029によってXSSが引き起こされてしまう場合というのを最近実際に見ました。 Googleのサービスで見つけた2つのケースを取り上げたいと思います。 ケ
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
パスワードの定期的変更について徳丸さんに聞いてみた(2)
高橋: こんにちは、高橋です。前回に引き続き、徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: はい。よろしくお願いします。 高橋: 前回は、「オンライン攻撃に対する予防としてパスワードの定期的変更は意味がない」という結論でしたが、今回は、事後の被害軽減策として、パスワードの定期的変更に意味があるか、というテーマですね。 徳丸: はい。その事後の話ですが、2つの話題があります。まず、前回の続きで、パスワードハッシュ値が漏洩してオフライン攻撃で解読されるまでの時間稼ぎとして、パスワードの定期的変更に意味があるか、次に、パスワードそのものが漏れている場合の緩和策として、定期的変更に意味があるかです。 高橋: それでは、まずハッシュ値が漏洩しているケースについてお願いします。 徳丸: はい。まず、前提として「パスワードを3ヶ月毎に変
SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ
はじめに 以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド（英語）が閲覧できますので、時間がある方はぜひ目を通してみてください。 CRIMEの意味 CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY（あるいはHTTPボディ部のgzip圧縮）で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。 BEASTとの関係 CRIMEはB
パスワードの定期的変更について徳丸さんに聞いてみた(1)
高橋: こんにちは、高橋です。今日は徳丸さんをお招きして、パスワードの定期的変更問題についてお話を伺います。徳丸さん、よろしくお願いします。 徳丸: 徳丸です。よろしくお願いします。 高橋: まず、お伺いしたいことですが、パスワードを定期的に変更すべしという根拠には、どのようなものがあるのでしょうか? 徳丸: 大きく分けて2つの理由が挙げられていると思います。一つは、パスワードを定期的に変更すると、パスワードを破って侵入する攻撃の予防になるというもの、すなわち事前の予防策です。もう一つは、パスワードが漏洩した際に、被害を軽減できるというもので、事後の緩和策ということですね。 高橋: もう少し詳しくお願いします。 徳丸: まず、「事前」の方ですが、オンライン攻撃とオフライン攻撃があります。 高橋: オンライン攻撃とはどのようなものでしょうか? 徳丸: オンライン攻撃は、ネット経由でパスワード
JPEG画像のEXIFヘッダにマルウェアを隠して実行させる新しい手口が登場
JPEG画像のEXIFヘッダに隠された仕掛けられたマルウェアを、Sucuri Research Labの調査チームが発見しました。このマルウェアはPHPの機能を用いてEXIFヘッダを読み込ませ、自らを実行させるようになっていました。 Malware Hidden Inside JPG EXIF Headers | Sucuri Blog http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html Sucuri Research Labのチームは攻撃サイト認定されたサイトでこのマルウェアを発見しました。通常、バックドアはBASE64変換やgzip圧縮で身を隠しますが、このマルウェアはJPEG画像のEXIFヘッダに隠されていて、PHPの機能を用いて実行されるようになっています。 まず、サイト内で見つかった
パスワード攻撃に対抗するWebサイト側セキュリティ強化策
Webサイトのパスワード認証を狙った攻撃が大きな脅威になっています。 Tサイト（プレスリリース） goo（プレスリリース） フレッツ光メンバーズクラブ（プレスリリース） eBook Japan（プレスリリース） My JR-EAST（プレスリリース） これらの事例のうちいくつか（あるいは全て）は、別のサイトで漏洩したIDとパスワードの一覧表を用いた「パスワードリスト攻撃（後述）」であると考えられています。パスワードリスト攻撃を含めて、パスワードを狙った攻撃が成立してしまう原因は、利用者のパスワード管理に問題がある場合が多く、攻撃を受けたWebサイト側には、直接の責任はないケースが多いと考えられます。 しかしながら、 大半の利用者はパスワード管理に興味がない パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情 インターネットが「とても危険なもの」となるとネット
Androidアプリセキュリティ 〜Webサイト閲覧でroot権限を取得されてしまう脆弱性(1)〜 | Remote TestKit
Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得されてしまうのはどういった仕組みで起きるのかについて解説します。 「○○○の脆弱性により任意のコードが実行される可能性があります」といった文章を一度は見たことがあると思います。 しかし、実際にどのような流れで任意のコードが実行されるのか？読者の皆さんはイメージできるでしょうか？ 今回説明するのは、Androidのブラウザ(図中ではWebkitと記載)の脆弱性を利用して相手の端末の管理者権限を取得する、という少し過激な内容です。 読者の皆様、特にAndroidアプリケーション開発技術者の方々に、今回の記事を通して少しでもセキュリティに興味を持っていただき、セキュアなアプリケーション開発のヒントになればと思います。 1．全体の流れ 遠回りになっていまいますが、まずは、「Android端末からWe
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
Same-Origin Policy とは何なのか。 - 葉っぱ日記
ちょっと凝ったWebアプリケーションを作成していたり、あるいはWebのセキュリティに関わっている人ならば「Same-Origin Policy」(SOP)という言葉を一度は聞いたことがあると思います。日本語では「同一生成元ポリシー」あるいは「同一生成源ポリシー」などと訳されることもありますが、個人的には「オリジン」は固有の概念を表す語なので下手に訳さず「同一オリジンポリシー」と書いておくのが好きです。 さて、この「オリジン」とは何なのかという話ですが、これは「RFC 6454 - The Web Origin Concept」で定められており、端的に言うと「スキーム、ホスト、ポート」の組み合わせをオリジンと定め、それらが同じものは同一のオリジンとして同じ保護範囲のリソースとして取り扱うということです。 例えば、http://example.jp/fooとhttp://example.jp:
Web StorageやindexedDBを扱う上でのセキュリティ上の注意点 - 葉っぱ日記
localStorageやsessionStorage、あるいはindexedDBのようなブラウザ上でのデータの保存が可能になったことで、これらを取り扱ううえでもセキュリティ上の注意点が必要である。 これらのストレージは、localStorageやindexedDBは永続的に、sessionStorageはブラウザやタブを閉じるまでの間データが保持され続けるので、例えばWebアプリケーションがログイン機構を持っている場合にログイン中にこれらのストレージに書き込まれたデータは、ログアウト後も当然参照および書き換えが可能である。Webアプリケーション上のアカウントに紐づいたデータをこれらのストレージに書き込んでいる場合、ログアウト後もアクセス可能なことが問題を引き起こす可能性がある。 例えばTwitterのようなサービスがあったとして、(navigator.onLineプロパティなどを利用して
XMLHttpRequestを使ったCSRF(補足編) - 葉っぱ日記
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記を書いていて思ったけど、いまいちXHRを使ったCSRF(というかクロスオリジン通信)について理解されていないような感じだったので、ちょっと書いておきます。とりあえず日本語のリソース的には、HTTP access control | MDN が詳しくて、それを読めばだいたい事足りるんで、あとはCSRFに関連しそうな話題だけ。 Q. そもそも「クロスオリジン」って何？ スキーム、ホスト、ポートの3つの組み合わせが一致している場合を同一オリジン(same-origin)、いずれか一つでもことなる場合をクロスオリジン(cross-origin)と言います。つまり、XHRでドメインを超えて通信している場合は典型的なクロスオリジン通信となります。 Q. え？ XMLHttpReuest って他のドメインにリクエストを発行できないんじゃ い
XMLHttpRequestを使ったCSRF対策 - 葉っぱ日記
合わせて読んでください：Flashと特定ブラウザの組み合わせでcross originでカスタムヘッダ付与が出来てしまう問題が未だに直っていない話 (2014-02/07) XMLHttpRequestを使うことで、Cookieやリファラ、hidden内のトークンを使用せずにシンプルにCSRF対策が行える。POSTするJavaScriptは以下の通り。(2013/03/04:コード一部修正) function post(){ var s = "mail=" + encodeURIComponent( document.getElementById("mail").value ) + "&msg=" + encodeURIComponent( document.getElementById("msg").value ); var xhr = new XMLHttpRequest(); xhr
RDocの脆弱性情報に見るjQueryの安全な使い方
2013-02-06に以下の脆弱性情報が公開されました。 RDoc で生成した HTML ドキュメントにおける XSS 脆弱性 (CVE-2013-0256) これはRDocの脆弱性情報ですが、実際にはdarkfish.jsというファイルの修正のみでありJSの問題であることがわかります。 問題のdarkfish.jsを確認すると該当の処理は「var anchor = window.location.hash.substring(1);から取得した値を$(“a[name=” + anchor + “]”);に渡した」処理であったことがわかります。 （このファイルが脆弱性情報のファイルと同じかは確認してないですが、ファイル名とコードから同一と判断しました） 修正方法としては$(“a[name=” + anchor + “]”)でのセレクター埋め込みをやめて$(“a[name]”).eachのe
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
大垣（@yohgaki）さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか？結論は ログイン時に
高木浩光さんへ、しっかりしてください - 最速転職研究会
技術者としての良心に従ってこの記事を書きます。俺はセキュリティとプライバシーの人ではなく、JavaScriptとUIの人である。法律の勉強だって自分の生活と業務に関わりのある範囲でしかしないだろう。しかし少なくともJavaScriptやブラウザが絡むような部分については、確実に自分のほうが理解していると思っている。高木浩光さんが、あからさまに間違ったことを書いたり、おかしなことを書いていたりしても、徐々に誰も指摘しなくなってきたと思う。おかしなこと書いていたとしても、非技術者から見たときに「多少過激な物言いだけど、あの人は専門家だから言っていることは正論なのだろう」とか、あるいは技術者から見た時でも、専門分野が違えば間違ったことが書かれていても気付けないということもあるだろう。 もう自分には分からなくなっている。誰にでも検証できるような事実関係の間違い、あるいは、技術的な間違いが含まれてい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ダイアリーとブログとXSS // Speaker Deck
地獄のJavaScriptセキュリティ