タグ

ブックマーク / tumblr.tokumaru.org (13)

  • バリデーション、エスケープ、フィルタリング、サニタイズのイメージ

    バリデーション、エスケープ、フィルタリング、サニタイズの用語は分かりにくいので、イメージで説明します。 “><script>alert(‘xss’);</script> という入力文字列が、それぞれどうなるかを示します。 ※1 厳密な定義ではありません(要件や文脈により変化します) ※2 バリデーションという用語は非常に幅があります(ここの「名称補足」参照)。 ※3 サニタイズという用語は非常に幅があるで、使う場合は事前に語義を定義しましょう(参照)。

    バリデーション、エスケープ、フィルタリング、サニタイズのイメージ
  • 大垣さん流の「入力ミス」と「入力バリデーションエラー」を区別するスクリプトを書いてみた

    大垣さんとの「バリデーション論争」において、大垣さんは「入力ミス」と「入力バリデーションエラー」を区別するものだと主張されています(参考:「入力ミス」と「入力バリデーションエラー」の違いに関する大垣さんと徳丸のやり取り)。 しかし、「入力ミス」と「入力バリデーションエラー」の区別の方法が分からないので伺ったところ、大垣さん曰く @ockeghem もしプログラマが「入力ミスと入力バリデーションエラーの区別ができない」という事は「プログラマが入力仕様を理解していない」という事です。正直、何が難しいのか理解できません。 http://t.co/Xkzs44zIJw ということでしたが、ブログエントリを書いていただきました。 簡単な問題です。プログラムが「想定する入力」以外は「妥当な入力」ではありません。プログラムを作っているプログラマが想定する入力を明確に理解していないなら、どのような入力仕様

  • Gmailの成りすまし事件、傾向と対策

    池田信夫氏のGmailアカウントがハックされて、寸借詐欺メールが送信されたようです。 Gmailの振り込め詐欺にご注意池田信夫、自らのメールアカウントを乗っ取られ今日も見事な醜態を晒す私の周囲でも、知人が同種の被害にあっていますので、他人事ではない気がします。池田氏が被害にあった原因は不明のようですが、このエントリではその原因を予想(妄想)し、対策について検討します。 池田氏の主張:twitter連携アプリからの漏洩池田氏は自らのブログエントリで以下のように主張しています。 Gmailのパスワードを知らせたことはないのですが、ツイッターと共通にしていたため、「連携アプリ」を認証するときパスワードを入力します。これはシステム側に通知されないことになっていますが、悪意をもって偽装することは容易です。かなりあやしげなアプリも含めて20ぐらい使っていたので、そこから推測してGmailにログインされ

    Gmailの成りすまし事件、傾向と対策
    cubed-l
    cubed-l 2012/12/27
    スマホ使いで2要素認証を使わない理由はないと思われ
  • セッションアダプションに対する私の見解

    先にエントリ「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」に対して、大垣(@yohgaki)さんから、「セッションフィクセイションはアダプション脆弱性修正で防御可能」というブログエントリで反論をいただきました。 大垣さんのエントリは長いのですが、反論のポイントは、以下の2点だと思いました。 徳丸のPoC(概念実証コード)では、セッションDBが分かれていないが、現実のレンタルサーバー等はセッションDBが分かれているので、攻撃はできないセッションには有効期間があり、セッションアダプションがない場合は、有効期間の過ぎたセッションIDが送信されても、セッションIDは再生成される。だから攻撃はできない以下、上記に反論します。 セッションDBは元々関係ないセッションフィクセイション攻撃において、セッションを扱うのは、攻撃対象のサーバーだけです。大垣さんは、セッションフィクセイ

    セッションアダプションに対する私の見解
  • セッションアダプションがなくてもセッションフィクセイション攻撃は可能

    大垣(@yohgaki)さんと、セッションアダプション脆弱性が「重大な脅威」か否かで論争を続けています。 大垣さん:第25回 PHPのアキレス腱 ── セッション管理徳丸:PHPSession Adoptionは重大な脅威ではない大垣さん:PHPのセッションアダプション脆弱性は修正して当然の脆弱性議論がかみ合わないので、twitterで「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい」とツイートしたところ、大垣さんがブログで返信下さいました。 大垣さん: セッションアダプション脆弱性がないセッション管理が必要な理由これを読んでかみ合わない理由が分かりました。大垣さん、ありがとうございます。以下大垣さんのブログの末尾を引用します。 脱線しましたが、何が改善されるのか?結論は ログイン時に

    セッションアダプションがなくてもセッションフィクセイション攻撃は可能
  • 書式文字列によるSQLインジェクション攻撃例

    以下のようなコードがあり、nameは画面入力なのでSQLインジェクションが起こるのでは? と作成者に確認したところ、"%s"してあるから大丈夫との返事をもらいました。 ネット調べるとmysql_real_escape_stringでエスケープしてから"%s"で変換すれば大丈夫といった内容は見つけたのですが、mysql_real_escape_stringなど不要との返事をもらいました。 なぜ?と聞くとそういうものだとしか回答がありません。 ひどいですね。これは質問者が正しく、sprintfの%sで受けただけでは、SQLインジェクション脆弱性となります。 しかし、どうしてこのような間違った知識が出てきたのかと考えるに、数値を%dで受ける場合と混乱したのではないかと憶測しました。数値の場合、書式%dで受けていれば、仮に攻撃コードが入力されたとしても、%dで整数に強制変換されるので、SQLインジ

    書式文字列によるSQLインジェクション攻撃例
  • 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) する人は実に多いのですが、これははっきりと間違いだと断言します @ITPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http

    PHP5.3.2以降ではfcloseで自動的にアンロックされない
    cubed-l
    cubed-l 2012/12/04
  • IE10にはパスワード表示ボタンが付いている

    昨日のブログエントリ「楽天koboのログイン画面にも「パスワードの表示」ボタンがついた」に対して、twitterでコメントを頂戴しました。 そういえばIE10には目アイコン(マウスボタン押下している間伏せ字解除)が付いてたような…… QT @ockeghem: 日記書いた 楽天koboのログイン画面にも「パスワードの表示」ボタンがついた - ockeghemのtumblr bit.ly/Tnk0I8 11月 11, 2012手元のノートPCWindows8を導入してIE10のパスワード欄を確認したら、確かに目アイコン(というのかな?)があり、マウスボタンを押下している間だけパスワードを表示しますね。 以下は、Windows8上のIE10で、evernoteのログイン画面を表示しているところです。IDとパスワードは架空のものです。 上記のように、通常はパスワードが伏せ字になっていますが、パ

    IE10にはパスワード表示ボタンが付いている
  • なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性

    なりすまし犯行予告が話題になっています。現在問題になっているものは、マルウェアが使われているようですが、それ以外に、無線LANの乗っ取りや、Webアプリケーションの脆弱性悪用などの手法があります。NHKの報道では、クロスサイトリクエストフォージェリ(CSRF)脆弱性が、過去に悪用された事例が紹介されています(ただしmixiの例と思われます)。 また、3つ目として、利用者からの投稿を受け付ける掲示板側にセキュリティー上の欠陥があった場合、利用者がウイルスに感染しなくても、書き込みをされるおそれがあります。 このうち、CSRF=クロスサイトリクエストフォージェリと呼ばれる攻撃手法では、利用者に攻撃者が用意したホームページのリンクをクリックさせただけで、別の掲示板に文章を投稿させることが可能だということです。 この場合、利用者はクリックしただけなので、文章を投稿したことにはほとんど気付かないとい

    なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性
  • hostsにループバックアドレスを指定することでリスクが増大するケース

    前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス(127.0.01)を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します(転載の許諾はいただいています)。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ

    hostsにループバックアドレスを指定することでリスクが増大するケース
  • hostsファイルにループバックアドレスを指定することは危険か?

    Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ(ルート化必要)が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事

    hostsファイルにループバックアドレスを指定することは危険か?
  • TポイントツールバーのWEB閲覧履歴を開示請求した

    Tポイントツールバーが収集したWEB閲覧履歴の開示請求ができることを8月19日(日)知りました。届出書は以下からダウンロードできます。 (A)『個人情報保護法に基づく請求』に用いる届出書 Ⅳ(開示請求:TポイントツールバーWEB閲覧履歴専用) これに記入(Tカード番号、住所、氏名などの個人情報)して、人確認書類のコピーを添えて簡易書留で郵送すれば、開示されると理解しました。料金は不要です。一方、削除請求というのもありますが、8月31日(金)付けで削除されたということなので、現時点でこれを使う機会はなさそうです。 私は、Tポイントツールバーを導入してWEB閲覧をしていましたので、開示請求をして、どのような形で閲覧履歴が開示されるかを見てみたいと思いました。幸い、以下のように試すのは容易なようでした。 必要事項を書くだけで事務的に開示されるようで請求側の心理的負担が少ない例えば、開示理由を書

    TポイントツールバーのWEB閲覧履歴を開示請求した
  • pastebinに貼られた「twitterユーザのパスワード」を軽く分析した - ockeghemのtumblr

    アノニマス匿名のハッカーがpastebinにtwitterアカウントのユーザ名とパスワード55,000以上を漏洩させたという書き込みがありました。(注:当初anonymous hackersをアノニマスハッカーと訳していましたが、ここは「匿名の」という意味ですね。訂正します) 真偽のほどはよくわかりませんが、ここに貼られていたパスワードを少し分析してみました。当然ながら、このパスワードを使ってログインしてみる、というのは違法行為ですので、絶対にやってはいけません。以下はあくまでもパスワード文字列の統計的な分析です。 まず、貼られていたアカウントの数ですが、単純に数えると、58,978個あり、約59,000というところです。ところが重複がかなりあり、ユニークなID:パスワードの組み合わせだと、34,069に減少します。さらに、「同一ユーザ名でパスワードが異なる」組み合わせが6個ありました。

    pastebinに貼られた「twitterユーザのパスワード」を軽く分析した - ockeghemのtumblr
  • 1