タグ

ブックマーク / ockeghem.hatenablog.jp (10)

  • はてなブックマークボタンがマイクロアド社の新ガイドラインに従ったらこうなる - ockeghem's blog

    すでにこちらでご案内の通り、私のブログ(徳丸浩の日記およびEGセキュアソリューションズオフィシャルブログ)に貼っていた「はてなブックマークボタン」により、読者の皆様の閲覧行動がマイクロアド社によりトラッキングされておりました。読者の皆様に断りなく不快な結果を強いていたことに対してお詫び申し上げます。既に当該ボタンは撤去しております。 その後、株式会社はてな社長の近藤淳也氏およびはてなの日記にて行動情報の提供をやめる旨のアナウンスが一昨日ありました(こことここ)。さらに、マイクロアド社からは、昨日以下のアナウンスがありました。 今後マイクロアドでは、ブログパーツや外部ボタン等、マイクロアドと直接提携関係にあるパートナー以外の第三者にあたる媒体・配信面に付与される可能性のあるものについて、それらの表示領域にマイクロアドからの行動履歴情報の蓄積を無効化するオプトアウトページへの導線設置を義務化い

    rti7743
    rti7743 2012/03/16
    そのうち行動ターゲティング広告で使います的アイコンが作られて、そのアイコンを表示することが告知とみなすとかやるんじゃね?SSLの鍵アイコンの真逆みたいな。アイコンクリックで詳細へリンクとか。
  • 大垣本を読んで「バリデーションはセキュリティ対策」について検討した - ockeghem(徳丸浩)の日記

    このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんのを読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション

    大垣本を読んで「バリデーションはセキュリティ対策」について検討した - ockeghem(徳丸浩)の日記
    rti7743
    rti7743 2011/12/26
    そろそろwikipedia にバリデーションの記事作って欲しい
  • モテるセキュ女子力を磨くための4つの心得「SQLインジェクションができない女をアピールせよ」等 - ockeghem's blog

    こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん! addslashes当にマジでチョームカつくんですけどぉぉお〜!」と言って、男に「どうしたの?」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜! サテ技に載ってたからずっとaddslashes使ってるんですけどぉ〜! 日語が化けるんですぅ〜! ぷんぷくり〜ん(怒)」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か

    モテるセキュ女子力を磨くための4つの心得「SQLインジェクションができない女をアピールせよ」等 - ockeghem's blog
    rti7743
    rti7743 2011/05/19
    徳丸先生までwww
  • 僕が「ホワイトリスト」を採用しなかった訳 - ockeghem's blog

    ホワイトリストという用語はセキュリティの分野では非常に基的な用語ですが、セキュアプログラミングという文脈では意外に曖昧な使われ方がされているように見受けます。エントリでは、ホワイトリストという用語の意味を三種類に分類し、この用語の実態に迫ります。拙著体系的に学ぶ 安全なWebアプリケーションの作り方(以下、徳丸)では、ホワイトリストという用語を一度も使っていませんが、その理由に対する説明でもあります。 ホワイトリストの分類 私の調査によると、ホワイトリストは以下の3種類に分類されます。 許可されたものの一覧表(第一種ホワイトリスト) セキュリティ上安全と考えられる書式(第二種ホワイトリスト) アプリケーション仕様として許可された書式(第三種ホワイトリスト) 以下順に説明します。 許可されたものの一覧表(第一種ホワイトリスト) ホワイトリストというくらいですから、来のホワイトリストは

    僕が「ホワイトリスト」を採用しなかった訳 - ockeghem's blog
  • 携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog

    最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、書にはブログやSNSなど認証が必要なアプリケーションも登場する。書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て

    携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
    rti7743
    rti7743 2009/07/14
  • PHP逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog

    404方面でも絶賛されていたPHP逆引きレシピを購入した。書はとても丁寧な仕事で素晴らしいと思ったが、セキュリティに関しては若干残念な思いをしたので、それを書こうと思う。 目次は以下のようになっている。 第1章 準備 第2章 PHPの基構文 第3章 PHPの基テクニック 第4章 ファイルとディレクトリ 第5章 PEARとSmarty 第6章 Webプログラミング 第7章 クラスとオブジェクト 第8章 セキュリティ 8.1 セキュリティ対策の基 8.2 PHPの設定 8.3 セキュリティ対策 第9章 トラブルシューティング 第10章 アプリケーション編 PHP逆引きレシピ オフィシャルサポート 書は、タイトルの示すように、コレコレしたいという目的ごとにPHPでの書き方が書かれている。よくある逆引き辞典タイプのだが、類書に比べて丁寧に書かれている印象を受けた。私が感心したのは、PH

    PHP逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog
    rti7743
    rti7743 2009/07/12
  • 正規表現で「制御文字以外」のチェック - ockeghem's blog

    一般に、セキュアコーディングの基として入力値の検証(Validation)をせよということになっていますが、これが変な方向に行くといわゆる「サニタイズ」のような手法になってしまいます。以前も指摘したように、アプリケーションとしてのValidationは仕様に従って行うべきものです。 ですが、概ねどの場合でも行うべき検証として以下があると思います。 文字エンコーディングの妥当姓 制御文字(\x00〜\x1f, \x7f)のチェック 文字列長のチェック このうち後ろ二つを正規表現として書くにはどうすればいいかを考えていました。つまり、「制御文字以外の文字でm文字以上n文字以下」というようなチェックです。m文字以上、n文字以下は、{m,n}で書けるので、問題は「制御文字以外の文字」です。これはtextタイプのinput要素で、かつアプリケーション仕様としては文字種の制限をしない場合を想定してい

    正規表現で「制御文字以外」のチェック - ockeghem's blog
    rti7743
    rti7743 2009/03/07
  • SQLインジェクション攻撃はDB上の任意データを盗み出す - ockeghem's blog

    前回に引き続き、Think IT上の連載「SQLインジェクション大全」の第4回:ケース別、攻撃の手口を読んで感じたことを書きたい。 まず、この記事は以下のような書き出しから始まっている。 記事は、システムを防御するにはまず敵を知らなければならない、という意図の下に、攻撃手法を紹介する。 dfltweb1.onamae.com – このドメインはお名前.comで取得されています。 この趣旨に異論があるわけではないが、しかしこの表現は誤解を生みやすいものだと思う。 というのは、「敵」(攻撃方法)を知ったからと言って、防御の方法が導き出せる訳ではないからだ。例えば、開発者が「最近のSQLインジェクションの自動化攻撃にはT-SQLのDECLARE文が用いられる」という情報を得て独自に対策を考えた場合、DECLAREという単語をチェックしてエラーにしたり、単語を削除することを考えがちだと思う。現に

    SQLインジェクション攻撃はDB上の任意データを盗み出す - ockeghem's blog
    rti7743
    rti7743 2009/03/07
  • とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog

    やぁ、みんな,元気?とくまるひろしです。今日はSession Fixation攻撃の方法をこっそり教えちゃうよ。 いつもは防御側で漢字の名前でやってるんだけど,きょうは攻撃側ということで,名乗りもひらがなに変えたんだ。だってさ,今度デブサミでご一緒するはせがわようすけさんとか,はまちちゃんとか,ひらがなの人たちの方が格好良さそうじゃないか。 では始めよう。 このエントリは、http://blog.tokumaru.org/2009/01/introduction-to-session-fixation-attack.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。

    とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
    rti7743
    rti7743 2009/01/31
  • 「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog

    はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル

    「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
    rti7743
    rti7743 2009/01/30
  • 1