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

  • ockeghem(徳丸浩)の日記 - XSS対策:どの文字をエスケープするべきなのか - コメント#1

    ITproの連載中に、id:hasegawayosukeさんから以下のようなコメントをいただいていました。 対策遅らせるHTMLエンコーディングの「神話」:ITpro - 葉っぱ日記 全ての文字をエスケープしようなどと非現実的なことは言わないけれど(とはいえMicrosoft Anti-Cross Site Scripting Libraryのようにほとんど全ての文字を実体参照に置き換えるものもあるので、あながち非現実的とも言えないのかも知れない)、エスケープ対象を「'」「"」「<」「>」「&」の5文字に限定しているのは何かこの記事に書かれていない理由があるはずだと思ったからです。 はてぶの方は見ていましたが、日記の方を見落としていまして、お返事が遅れました(_ _)。 なぜ、「<」、「>」、「&」、「"」、「'」の5種類の文字をエスケープするのかについては、色々考えるところがあります。

    ockeghem(徳丸浩)の日記 - XSS対策:どの文字をエスケープするべきなのか - コメント#1
  • 数値リテラルをシングルクォートで囲むことの是非 - ockeghem's blog

    高木浩光氏からの批判の一つは、数値リテラルをシングルクォートで囲むことに対する論拠のあいまいさであったように思う。 「性能的にも不利だし」 < 性能の影響は皆無。問題はそこではなく、挙動がSQL仕様で定義されているか。 以下にもう少し掘り下げて考察してみよう。 SQL仕様でどう定義されているか? 以下のようなSQLで、列IDがint型であると仮定しよう DELETE FROM DOCUMENTS WHERE ID=1 この数値リテラル1をシングルクォートで囲んだ場合の動作はどう規定されているか? DELETE FROM DOCUMENTS WHERE ID='1' 今手元にJIS SQLなどの規定がないので記憶に頼って書くしかないが、このような場合は、varchar型などの文字型から、int型への「暗黙の型変換」が実施される。つまり、'1'という文字列は、1という数値(整数)に変換されてか

    数値リテラルをシングルクォートで囲むことの是非 - ockeghem's blog
  • 携帯電話向けWebアプリケーションのセッション管理手法 - ockeghem's blog

    高木浩光@自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのかに、高木浩光氏が携帯電話向けWebアプリケーションの安全性についてコメントされておられる。 なぜ「URLにセッションIDが含まれる場合はセキュリティに注意する必要があり」なのかと言えば、Refererによってリンク先にセッションID入りのURLが流出し、流出先サイトの人にセッションハイジャックされてしまうからだ。 確かにそうなのだが、携帯電話向けWebアプリケーションでは、セッションIDをURLに埋め込むことが定石として用いられている。 その理由は、他に適当な方法がないからである。 携帯電話向けWebの代表例であるi-modeでは、Cookieをサポートしていない。そのため、セッションIDを埋められる場所というと、 URLに埋め込む Hiddenフィールドに埋め込んでPOSTで送出する くらいしか代替手段がな

    携帯電話向けWebアプリケーションのセッション管理手法 - ockeghem's blog
  • 2007-03-06

    ケータイWebアプリの脆弱性問題は、私の専門分野であるので、もう少し突っ込んでみたいと思う。 高木浩光氏の高木浩光@自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか 携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。 この問いかけに対して、技術論ではなく、脆弱性検査を実施した結果の統計情報で回答する。 というには、私の勤務先では、まさにケータイ向けWeb脆弱性診断をやっていて、昨年一年間の脆弱性傾向の統計を発表しているからだ。 https://www.kccs.co.jp/contact/paper_websecurity/index.html このホワイトペーパ

    2007-03-06
  • 1