SQLインジェクション対策はおすみですか?
開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、
脆弱性発見後の適切な対策まで
トップ 最新 追記
過去の日記

2007-06-04 本格運用開始

tDiary: html_anchorを導入

yyyymmdd.htmlでアクセスできるようにしたかったので、html_anchorを導入したはよかったけど、.htaccessでActionディレクトティブではまってしまった。これ、mod_actionsが導入されていないと駄目なのね。考えてみれば当たり前なのだけれど、「mod_actionsが導入されていることを確認せよ」と指示されてなかったので、試行錯誤してしまった。結局、Actionディレクティブをあきらめて(共用レンタルサーバーなので)、ErrorDocumentディレクティブに変更して、こちらはあっさりと動きました。
うーむ。

まぁ、ErrorDocumentとActionの二つが書いてあって、ErrorDocumentのデメリットは書いてあったけど、Actionのデメリットは書いてなかった。二つの方法があるなら、メリットとデメリットがあるはずとぼんやり感じていてた「変だなぁ」のだけど、そこらを突っ込まなかったのが悪いのですね。

とはいえ、これで、はてなダイアリーからの移行が可能になった・・・と思っています。だって、「?date=yyyymmdd」だと、全然検索エンジンに登録されないようですしね。


2007-06-05 はてなダイアリーから転載

Firefox 2.0.0.4におけるXSSワンクリックパスワード窃取問題

Firefox2.0.0.4でも直ってないですね。

ockeghem(徳丸浩)の日記 - Firefoxのパスワード・マネージャの脆弱性その後

Firefoxユーザーがクロスサイト・スクリプティングXSS脆弱性のあるWebサイトパスワードを記憶させている場合には,細工が施されたリンクをクリックするだけでそのパスワードを盗まれる恐れがある

直す方法はあると思うんだがなぁ。勝手に全自動でパスワード補完しないで、Operaみたいに一回キーを叩かせるだけでも、インパクトはかなり緩和されると思います。

まぁ、サイト側にXSS脆弱性がなければ上記は発動しないので、「けっ、サイト側の問題ジャン。XSSくらい直せよ」と思っているんだろうね>Mozilla中の人

だけど、XSSのあるサイトなんて山のようにあるよ。それも、はせがわさん(id:hasegawayosuke)の指摘するようなマニアックなやつでなくて、ごく単純なXSS

とりあえずは、

ということで自衛しましょう。


2007-06-14 変数に型のない言語におけるSQLインジェクション対策に対する考察(4)

SQLの「暗黙の型変換」で実行速度が遅くなるのはどのような場合か

数値リテラルをシングルクォートで囲むことの是非にて、「変数に型のない言語」(Perl、PHP、Rubyなど)で数値項目に対するSQLインジェクション対策について検討した。その際に、数値リテラルを文字列リテラルとしてシングルクォートで囲む(中の値はエスケープする)という方法を紹介した上で、文字列型から数値型への「暗黙の型変換」により、SQLの実行が遅くなる可能性を指摘した。
 この情報は、ネット上で検索すればすぐに見つかるものであるが、私自身試したことはなかった(なにせ暗黙の型変換などやりたくないクチなので)。
 しかし、実験もせずに「SQLの暗黙の型変換はパフォーマンスが劣化する」と断言するのもエンジニアとしてどうかと思い、簡単なサンプルで実験を行ってみた。
 実験には、Oracle Database 10g Express Editionを使用して、TKPROFユーティリティにより測定を行った。ただし、データ量が1万件しかないので実行速度については有意な差が出なかったので、インデックスの利用有無により間接的な判定を行った。
 結論から言えば、SQLインジェクション対策時に発生する「暗黙の型変換」については、パフォーマンスは低下しないようである。
 「暗黙の型変換」でパフォーマンスが低下する場合は確かに検証できたが、

文字列型の列と数値リテラルに対する演算

の場合であった。具体的には、以下のような場合である(DOC_IDは文字列型とする)。

SELECT * FROM HOGE WHERE DOC_ID = 123

この場合、すべてのDOC_IDを数値に変換しながらWHERE句が実行されるため、インデックスを使用することができずにパフォーマンスが低下する。
一方、DOC_NIDが整数型だとして、

SELECT * FROM HOGE WHERE DOC_NID = '123'

の場合は、まず'123'を整数型に変換してから検索実行されるので、インデックスが有効活用される。すなわち、パフォーマンス低下はない。
SQLインジェクション対策にあらわれる「暗黙の型変換」は後者のパターンであるため、SQLインジェクション対策に限って言えば、パフォーマンス低下は認められなかった。

しかしながら、このような実験を行うとともに、この問題に対する考察を深めた結果、やはり数値リテラルをシングルクォートで囲むというやり方には問題があると思う。その内容については稿をあらためて説明したい。


SQLインジェクション対策はおすみですか?
開発開始時点からのコンサルティングから、公開済みWebサイトの脆弱性検査、
脆弱性発見後の適切な対策まで
トップ 最新 追記