大垣さんと徳丸のパリデーション論争のリンク集
第一次論争 XSSのホワイトリスト防御について 2008年2月 ホワイトリストはどう作る?（大垣さん） 徳丸コメント：XSSの攻撃方法を出発点として「ホワイトリスト」を検討するのはおかしいと思います。 2008年7月 ホワイトリスト方式の優位は神話（徳丸） 2008年8月 プログラミングではホワイトリスティングが基本（大垣さん） 徳丸コメント：バリデーションの基準は、「ホワイトリスト」（って何?）ではなくアプリケーションの仕様が基準 プログラミングではホワイトリスティングが基本ではない（徳丸） ホワイトリストとブラックリスト(SAWA, Izumiさん) 今こそXSS対策についてまとめよう（徳丸） 続・ホワイトリストとブラックリスト(SAWA, Izumiさん) 第二次論争 バリデーションは「セキュリティ対策なのか」 2011年12月 妥当性とは仕様の所作 - SQLインジェクション対策と
勝手に解説：大垣流バリデーション入門
大垣さんは、かねてより「バリデーションは重要なセキュリティ対策である」という持論を持っておられます。そして、それは「世界の常識」と指摘されています。 「入力バリデーションはセキュリティ対策である」は世界の常識です。少なくとも大多数の世界のセキュリティ専門家は「入力バリデーションはセキュリティ対策」は常識だと考えています。 第45回 入力バリデーションはセキュリティ対策 ：なぜPHPアプリにセキュリティホールが多いのか?より引用 私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていま
もう入力値検証はセキュリティ対策として *あてにしない* ようにしよう
スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です。 スタ
Yahoo!の『秘密の「質問」と「答え」』の変更方法
Yahoo!Japan IDは、現在は新規登録時に必ず『秘密の「質問」と「答え」』の登録が義務づけられており、パスワードリセットなどで用いられます。 そして、この『秘密の「質問」と「答え」』は、いったん登録すると変更することができません。 秘密の「質問」と「答え」の内容は、Yahoo! JAPAN IDの登録後に、確認および変更できません。 http://help.yahoo.co.jp/help/jp/edit/edit-43.html しかしながら、『秘密の「質問」と「答え」』の質問の方は、あらかじめ用意された選択肢から選ぶようになっており、第三者が予測できそうなものが多いのが現状です。 子どものころのあだ名は？初めて買った曲のタイトルは？初恋の人の名前は？子どものころの夢は？座右の銘は？初めて飼ったペットの名前は？祖父の下の名前は？生まれた病院は？初めて行った海外の国・地域は？小学1
Evernoteのテキストを暗号化する方法
本日早朝に、Evernoteが外部からの攻撃を受けて、ユーザ名、メールアドレス、パスワードハッシュ値（ソルト付きハッシュ）にアクセスされたという報告（セキュリティ関連のお知らせ：Evernoteでのパスワード再設定のお願い）がありました。 Evernoteのユーザは、このお知らせの指示にしたがい、パスワードをリセットしましょう。問題は、Evernoteのコンテンツ（ノート）にアクセスされたかどうかですが、Evernote社では、以下のように、ノートにはアクセスされた形跡はないと主張しています。 弊社セキュリティ調査の結果、Evernote に保存されているコンテンツが外部からアクセス・変更・消失された形跡は確認されませんでした。また、Evernote プレミアムおよび Evernote Business のお客様の決済情報がアクセスされた形跡も確認されていませんのでご安心ください。 一応こ
勝手に査読:Webアプリにおける11の脆弱性の常識と対策
「Webアプリにおける11の脆弱性の常識と対策」という記事を久しぶりに読みました。出た当事も思いましたが、基本的な誤りが多く、読者が誤解しそうです。このため、編集部から頼まれたわけではありませんが、「勝手に査読」してみようと思います。 細かい点に突っ込んでいくとキリがないので、大きな問題のみ指摘したいと思います。 ※2013年2月25日追記 このエントリに対して、編集部が元記事を修正くださいました。徳丸も修正に協力いたしましたが、十分正確な内容ではないことをお含みおきください。 ※追記終わり 同記事の想定読者は誰か査読にあたり、この記事の想定読者を明確にしておいた方がよいですね。記事の冒頭には、連載の説明があります。 本連載は、JSP／サーブレット＋StrutsのWebアプリケーション開発を通じて、Java言語以外（PHPやASP.NET、Ruby on Railsなど）の開発にも通用する
セッションアダプションがなくてもセッションフィクセイション攻撃は可能
大垣（@yohgaki）さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPのSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか？結論は ログイン時に
PHP5.3.2以降ではfcloseで自動的にアンロックされない
PHPの本家サイトでflockの説明を読んでいたら、以下の変更履歴に気がつきました。 5.3.2 ファイルのリソースハンドルを閉じたときにロックを自動的に解放する機能が削除されました。 ロックの解放は、常に手動で行わなければなりません。 http://php.net/manual/ja/function.flock.php ところがネットの解説を見ると、ロック開放はflock($fp, LOCK_UN); ではなく、fcloseでやれとしている解説が結構あります。 (4)fcloseの前にflock解除するな … fcloseの前にflock(ファイルポインタ, LOCK_UN) する人は実に多いのですが、これははっきりと間違いだと断言します @ITのPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http
IE10にはパスワード表示ボタンが付いている
昨日のブログエントリ「楽天koboのログイン画面にも「パスワードの表示」ボタンがついた」に対して、twitterでコメントを頂戴しました。 そういえばIE10には目アイコン（マウスボタン押下している間伏せ字解除）が付いてたような…… QT @ockeghem: 日記書いた 楽天koboのログイン画面にも「パスワードの表示」ボタンがついた - ockeghemのtumblr bit.ly/Tnk0I8 11月 11, 2012手元のノートPCにWindows8を導入してIE10のパスワード欄を確認したら、確かに目アイコン(というのかな?)があり、マウスボタンを押下している間だけパスワードを表示しますね。 以下は、Windows8上のIE10で、evernoteのログイン画面を表示しているところです。IDとパスワードは架空のものです。 上記のように、通常はパスワードが伏せ字になっていますが、パ
Opera11.6以降でnoframesの表示方法が変わったっぽい
Operaでは標準機能でフレームを表示しないという設定が可能です。 この場合、コンテンツのframe要素は無視され、noframes要素があれば、それが表示されるはずです。以下のHTMLファイルで試してみました。frame要素はダミーで、noframesの中味が表示されるはずです。 Opera11.50での表示は以下となります。 大丈夫ですね。 しかし、Opera11.60（以降）では以下となります。 なんということでしょう! noframes要素の中味がプレーンテキストとしてそのまま表示されました。 なんとなくですが、Opera11.5以前の仕様が正しいような気がするのですが、よくわかりません(>_ 識者の方の解説を待ちたいと思います。 追記(11/10 7:20)twitterで@vyv03354さんからコメントをいただきました。 @ockeghem Opera 11.60でHTML5
祝:名著「金床本」のKindle対応
紙の本について、かつてこう書きました。 本を手にとって最初に思うことは、その大部さである。いまどき、箱入り、ハードカバーで494ページもあり、ずしりとした手ごたえを感じる。日常のリファレンスや満員電車のお供にするのであれば、もっと軽薄短小であって欲しいと思うところだが、本書の場合そうではない。その理由は後述する。 【中略】 繰り返すが、本書は初心者向けの解説では決してなく、上級者が自身の楽しみに読むのが正しいと思う。であれば、箱入りであるとかハードカバーであることは決してデメリットではない。楽しい読み物として末永く楽しむべき本には、それにふさわしい体裁があるというものである。 書評 - ウェブアプリケーションセキュリティより こう書いたものの、やはり手元で「あれ、これはどうだっけ」と調べるには、電子書籍だと便利ですね。それに、紙の本が4,830円であるのに対して、Kindle版は2,800
なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性
なりすまし犯行予告が話題になっています。現在問題になっているものは、マルウェアが使われているようですが、それ以外に、無線LANの乗っ取りや、Webアプリケーションの脆弱性悪用などの手法があります。NHKの報道では、クロスサイトリクエストフォージェリ(CSRF)脆弱性が、過去に悪用された事例が紹介されています（ただしmixiの例と思われます）。 また、３つ目として、利用者からの投稿を受け付ける掲示板側にセキュリティー上の欠陥があった場合、利用者がウイルスに感染しなくても、書き込みをされるおそれがあります。 このうち、ＣＳＲＦ＝クロスサイトリクエストフォージェリと呼ばれる攻撃手法では、利用者に攻撃者が用意したホームページのリンクをクリックさせただけで、別の掲示板に文章を投稿させることが可能だということです。 この場合、利用者はクリックしただけなので、文章を投稿したことにはほとんど気付かないとい
「ブラインドSQLインジェクションとは何ですか？」への回答
以下は、Yahoo!知恵袋での下記質問に対する回答です。 ブラインドSQLインジェクションとは何ですか？ できるだけ詳細に教えて下さい 回答した後に、質問が取り消されてしまいました。Yahoo!知恵袋の仕様として、取り消しされた質問は2週間で削除されるため、備忘のため転載します。 ブラインドSQLインジェクションというのは、SQLインジェクション攻撃の一種です。 通常のSQLインジェクション攻撃では、検索結果の文字列が表示されたり、SQLのエラーメッセージが表示される箇所があり、それら表示の一部に、本来とは別のSQL文の検索結果を表示させることで、隠れた情報を表示します。 しかし、SQLインジェクション脆弱性はあるが、表示として検索結果の表示もなく、エラーメッセージにもSQLのエラーが表示されない場合があります。例えば、以下に紹介する例では、指定したメールアドレスが登録済みかどうかのみを返
Gmailの成りすまし事件、傾向と対策
池田信夫氏のGmailアカウントがハックされて、寸借詐欺メールが送信されたようです。 Gmailの振り込め詐欺にご注意池田信夫、自らのメールアカウントを乗っ取られ今日も見事な醜態を晒す私の周囲でも、知人が同種の被害にあっていますので、他人事ではない気がします。池田氏が被害にあった原因は不明のようですが、このエントリではその原因を予想（妄想）し、対策について検討します。 池田氏の主張：twitter連携アプリからの漏洩池田氏は自らのブログエントリで以下のように主張しています。 Gmailのパスワードを知らせたことはないのですが、ツイッターと共通にしていたため、「連携アプリ」を認証するときパスワードを入力します。これはシステム側に通知されないことになっていますが、悪意をもって偽装することは容易です。かなりあやしげなアプリも含めて20ぐらい使っていたので、そこから推測してGmailにログインされ
hostsにループバックアドレスを指定することでリスクが増大するケース
前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス（127.0.01）を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します（転載の許諾はいただいています）。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ
hostsファイルにループバックアドレスを指定することは危険か?
Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ（ルート化必要）が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostのIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
