バリデーション、エスケープ、フィルタリング、サニタイズの用語は分かりにくいので、イメージで説明します。 “><script>alert(‘xss’);</script> という入力文字列が、それぞれどうなるかを示します。 ※1 厳密な定義ではありません(要件や文脈により変化します) ※2 バリデーションという用語は非常に幅があります(ここの「名称補足」参照)。 ※3 サニタイズという用語は非常に幅があるで、使う場合は事前に語義を定義しましょう(参照)。
![バリデーション、エスケープ、フィルタリング、サニタイズのイメージ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ce284b72b2bf7ac8d26b094424f315d7b304cd5a/height=288;version=1;width=512/https%3A%2F%2F64.media.tumblr.com%2Ff5ed7af3492e677775f336113429c1cd%2F0f414542401d3482-20%2Fs500x750%2Fe0b9bc3c580336a66c299fdaefefdb4b62f40aa3.png)
スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前(ファイル名を使う直前)に行うべきだ、という考え方です。 スタ
本日早朝に、Evernoteが外部からの攻撃を受けて、ユーザ名、メールアドレス、パスワードハッシュ値(ソルト付きハッシュ)にアクセスされたという報告(セキュリティ関連のお知らせ:Evernoteでのパスワード再設定のお願い)がありました。 Evernoteのユーザは、このお知らせの指示にしたがい、パスワードをリセットしましょう。問題は、Evernoteのコンテンツ(ノート)にアクセスされたかどうかですが、Evernote社では、以下のように、ノートにはアクセスされた形跡はないと主張しています。 弊社セキュリティ調査の結果、Evernote に保存されているコンテンツが外部からアクセス・変更・消失された形跡は確認されませんでした。また、Evernote プレミアムおよび Evernote Business のお客様の決済情報がアクセスされた形跡も確認されていませんのでご安心ください。 一応こ
「Webアプリにおける11の脆弱性の常識と対策」という記事を久しぶりに読みました。出た当事も思いましたが、基本的な誤りが多く、読者が誤解しそうです。このため、編集部から頼まれたわけではありませんが、「勝手に査読」してみようと思います。 細かい点に突っ込んでいくとキリがないので、大きな問題のみ指摘したいと思います。 ※2013年2月25日追記 このエントリに対して、編集部が元記事を修正くださいました。徳丸も修正に協力いたしましたが、十分正確な内容ではないことをお含みおきください。 ※追記終わり 同記事の想定読者は誰か査読にあたり、この記事の想定読者を明確にしておいた方がよいですね。記事の冒頭には、連載の説明があります。 本連載は、JSP/サーブレット+StrutsのWebアプリケーション開発を通じて、Java言語以外(PHPやASP.NET、Ruby on Railsなど)の開発にも通用する
先にエントリ「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」に対して、大垣(@yohgaki)さんから、「セッションフィクセイションはアダプション脆弱性修正で防御可能」というブログエントリで反論をいただきました。 大垣さんのエントリは長いのですが、反論のポイントは、以下の2点だと思いました。 徳丸のPoC(概念実証コード)では、セッションDBが分かれていないが、現実のレンタルサーバー等はセッションDBが分かれているので、攻撃はできないセッションには有効期間があり、セッションアダプションがない場合は、有効期間の過ぎたセッションIDが送信されても、セッションIDは再生成される。だから攻撃はできない以下、上記に反論します。 セッションDBは元々関係ないセッションフィクセイション攻撃において、セッションを扱うのは、攻撃対象のサーバーだけです。大垣さんは、セッションフィクセイ
以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは? と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ?と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ
昨日のブログエントリ「楽天koboのログイン画面にも「パスワードの表示」ボタンがついた」に対して、twitterでコメントを頂戴しました。 そういえばIE10には目アイコン(マウスボタン押下している間伏せ字解除)が付いてたような…… QT @ockeghem: 日記書いた 楽天koboのログイン画面にも「パスワードの表示」ボタンがついた - ockeghemのtumblr bit.ly/Tnk0I8 11月 11, 2012手元のノートPCにWindows8を導入してIE10のパスワード欄を確認したら、確かに目アイコン(というのかな?)があり、マウスボタンを押下している間だけパスワードを表示しますね。 以下は、Windows8上のIE10で、evernoteのログイン画面を表示しているところです。IDとパスワードは架空のものです。 上記のように、通常はパスワードが伏せ字になっていますが、パ
以下は、Yahoo!知恵袋での下記質問に対する回答です。 ブラインドSQLインジェクションとは何ですか? できるだけ詳細に教えて下さい 回答した後に、質問が取り消されてしまいました。Yahoo!知恵袋の仕様として、取り消しされた質問は2週間で削除されるため、備忘のため転載します。 ブラインドSQLインジェクションというのは、SQLインジェクション攻撃の一種です。 通常のSQLインジェクション攻撃では、検索結果の文字列が表示されたり、SQLのエラーメッセージが表示される箇所があり、それら表示の一部に、本来とは別のSQL文の検索結果を表示させることで、隠れた情報を表示します。 しかし、SQLインジェクション脆弱性はあるが、表示として検索結果の表示もなく、エラーメッセージにもSQLのエラーが表示されない場合があります。例えば、以下に紹介する例では、指定したメールアドレスが登録済みかどうかのみを返
池田信夫氏のGmailアカウントがハックされて、寸借詐欺メールが送信されたようです。 Gmailの振り込め詐欺にご注意池田信夫、自らのメールアカウントを乗っ取られ今日も見事な醜態を晒す私の周囲でも、知人が同種の被害にあっていますので、他人事ではない気がします。池田氏が被害にあった原因は不明のようですが、このエントリではその原因を予想(妄想)し、対策について検討します。 池田氏の主張:twitter連携アプリからの漏洩池田氏は自らのブログエントリで以下のように主張しています。 Gmailのパスワードを知らせたことはないのですが、ツイッターと共通にしていたため、「連携アプリ」を認証するときパスワードを入力します。これはシステム側に通知されないことになっていますが、悪意をもって偽装することは容易です。かなりあやしげなアプリも含めて20ぐらい使っていたので、そこから推測してGmailにログインされ
前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス(127.0.01)を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します(転載の許諾はいただいています)。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ
Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ(ルート化必要)が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostのIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事
アノニマス匿名のハッカーがpastebinにtwitterアカウントのユーザ名とパスワード55,000以上を漏洩させたという書き込みがありました。(注:当初anonymous hackersをアノニマスハッカーと訳していましたが、ここは「匿名の」という意味ですね。訂正します) 真偽のほどはよくわかりませんが、ここに貼られていたパスワードを少し分析してみました。当然ながら、このパスワードを使ってログインしてみる、というのは違法行為ですので、絶対にやってはいけません。以下はあくまでもパスワード文字列の統計的な分析です。 まず、貼られていたアカウントの数ですが、単純に数えると、58,978個あり、約59,000というところです。ところが重複がかなりあり、ユニークなID:パスワードの組み合わせだと、34,069に減少します。さらに、「同一ユーザ名でパスワードが異なる」組み合わせが6個ありました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く