PEAK XOOPS - News in englishin japanese

Archive | RSS |
  
Poster : GIJOE on 2006-06-20 13:16:00 (11304 reads)

in englishin japanese
XSS (cross site scripting)は、きわめて一般的でありながら、チェーンによって極めて強力な攻撃に転じうる、怖い脆弱性と言えます。
特に怖いのが、JavaScriptのXMLHttpRequestを利用する攻撃で、同一ホストのどこか一箇所にXSSがあるだけで、クッキー流出やCSRF対策の無効化がなされます。ホストさえ同一なら、どこでもOKというのが怖いところで、クッキーのパスや、CSRF対策のチケットやリファラーチェックなども、ほとんど意味をなさなくなってしまいます。
(IEのバグで、Ajaxの技術を応用すれば、別ホストでも上記と同様の攻撃が可能、というのはここでは言及しません。明らかにIE側で修正すべき穴であり、Webアプリケーション側では手も足も出ません。)

とにかく、XSSを体系的に潰すことが何より重要だというのが、結論です。

本来、XSSというのは、正しいリクエスト処理・表示処理をしていれば防げるものではありますが、人間とは、ポカミスをしでかす生き物です。テンプレートシステムなどの、自動的にhtmlspecialchars()をかけるブラックボックス化、というのも手ではありますが、そういうブラックボックスを用意しても、HTMLを直に出力したい場面が必ず存在する以上、ブラックボックスを経由しない部分でポロっとXSSをだす可能性は大だと私は考えています。

テンプレートシステムなどではなく、Webアプリケーション全体を守ってくれる「大きな傘」のようなもの。これこそが、ほとんどのサイトに求められるXSS対策ではないでしょうか。

これだけ書くと、mod_securityのような「入口」でのチェックを思い浮かべたかもしれません。それも有効な手段ではあるでしょう。しかし、mod_securityでリクエスト制限を行った場合、面倒な問題が発生します。

例えば、"<script" という文字列を含むリクエストを禁止してしまう場合、JavaScriptの開発フォーラムが事実上機能しなくなってしまうでしょう。

かといって、obフィルターなどの「出口」側で "<script" を禁止してしまうと、今度は、本来機能して欲しいJavaScriptが死んでしまいます。


私自身、ここでしばらく悩んでいたのですが、ふと、ベストな解法が思い浮かびました。

「入口」で怪しいリクエストを見つけたらそれを覚えておき、「出口」でそのまま出力されていないかをチェックする

これこそが、「大きな傘」たり得る、XSS対策です!
通常、"<script" などのXSS攻撃に特徴的な文字列がリクエストされることは極めて稀なので、そういう特殊な状況でのみ、ob_start()で「出口」チェックを登録する、という方法で、パフォーマンスへの影響も避けられます。

実際のコーディングは(2)に続きます。

0 comments

Poster : GIJOE on 2006-06-06 18:10:55 (13278 reads)

in englishin japanese
「INと比較すべきは、LEFT JOIN(外部結合)ではなく、INNER JOIN(内部結合)だ」という指摘を、Marijuanaさんから受けました。
確かにその通りでしたので、あらためてベンチマークを行ってみました。

その結果、NULL処理が増えた場合のLEFT JOINが極端に遅いだけで、INNER JOINとINとの比較では、ほぼ同じくらいの速度性能であることが判明しました。しかも、これは極めてリーズナブルな結果と言えるでしょう。

ただ、速度的なメリットがなかったとしても、権限テーブルが複雑になればなるほど、それを途中で分解できることでコーディングしやすくなるメリットは十分にあるはずで、INを使う方が良い、という結論には違いがないと思います。

Read more... | 3238 bytes more |0 comments

Poster : GIJOE on 2006-06-04 04:32:00 (8102 reads)

in englishin japanese
MySQLの特徴の一つに、「単純なクエリでは圧倒的に速いが、複雑なクエリだとそうでもない」が挙げられます。

そのため、LAMPアプリケーションの設計では、クエリの回数を抑えることよりも、各クエリをバラバラにして、なるべく単純なクエリにすることが、速度向上の近道のようです。

例えば、「カテゴリー対グループという権限設定のついたアイテムを検索する」なんてありがちなケースを考えます。


CREATE TABLE cat (
  `cid` int NOT NULL default 0,
  `name` varchar(255) NOT NULL default '',
  PRIMARY KEY (cid)
) TYPE=MyISAM ;

CREATE TABLE cat_perm (
  `cid` int NOT NULL default 0,
  `gid` int NOT NULL default 0,
  PRIMARY KEY (cid,gid)
) TYPE=MyISAM ;

CREATE TABLE item (
  `id` int NOT NULL default 0,
  `cid` int NOT NULL default 0,
  `name` varchar(255) NOT NULL default '',
  PRIMARY KEY (id),
  KEY (cid)
) TYPE=MyISAM ;


こんな構造の場合、SQL書きを得意としている人間は、ついつい、

SELECT item.* FROM item LEFT JOIN cat_perm ON cat_perm.cid=item.cid WHERE cat_perm.gid=1;

なんてクエリを発行しがちですが、少なくともMySQL的には効率が悪いのです。


SELECT cid FROM cat_perm WHERE gid=1;

として、いったんcidを一通り得てから、

SELECT * FROM item WHERE cid IN (cid一覧);

と2回に分けることで、実はとてもMySQLの効率は良くなります。

もちろん、「cidを一通り」得てIN用の文字列を用意する部分の実行効率がどれほどであるかによってトータルのパフォーマンス違ってくるでしょうが、ざっとベンチマークをとった限り、通常のLAMP環境では、やはり後者の方が速い、という結果が得られました。(「カテゴリー数」が増えて、INの部分がかなり長いケースでも結果は同じ)

実際のケースでは、アイテムに対するカテゴリーは十分に小さく、逆に、権限テーブルはずっと複雑になりがちなので、その差はもっと開くと思います。

JOINよりもIN

標語としても良くできてますね
--------------------
(2006/06/06追記)
このベンチマーク自体は問題ないのですが、比較する相手が悪いという指摘を受けました。
確かにその通りだったので、訂正記事の方も参照してください。


Poster : GIJOE on 2006-05-31 06:08:21 (7350 reads)

in englishin japanese
XUGJにおいてPukiWiki-Modでマニュアルを書いていたときに、チケットのタイムアウトを喰らいました。しかもこれ、拙作のgticket(もしくはその派生クラス)です。

この時の投稿内容は相当長かったのですが、それをうまく救い出すことができず、本当に悲しみが雪のように積もりました。それがきっかけで、再POST機能を実装したgticket2をリリースすることになるのですが、それは以下のニュースをご覧ください。

http://www.peak.ne.jp/xoops/md/news/article.php?storyid=95

一見すると、PukiWiki-Modにこのgticket2をインストールすれば良いだけ、と思われがちですが、ここの話題はそれではありません。

「CSRF対策」という名の元に行われてきた、数々のユーザの利便性無視こそが問題なのです。

「CSRF対策」が絶対的に必要なのは、「不可逆な処理」に対してです。可逆な処理であれば、たいていの場合、致命的な状況にはなりません。(その遷移状態からチェーンできる攻撃があれば別ですが)

果たして、Wikiの編集操作は不可逆ですか? 誰かが悪意ある編集をしても、別の誰かがすぐにロールバックできる。それがWikiの売りでしょう? もし誰かがCSRF攻撃を喰らって、あるエントリを変に書き換えてしまったとしても、簡単に元に戻せるのです。

つまり、Wikiの編集操作にチケットチェックを入れることは無意味です。むしろ、CSRFとは何であるかが判っていない証拠ともなってしまいます。

ただ、ここで面白いのは、それくらいWikiの基本思想が優れているという事実です。「CSRF対策」はどうしてもユーザの利便を損なう形になってしまいますが、Webアプリケーションの設計において、操作の可逆性を担保すれば、それこそが最高のCSRF対策になるのです。

チケットエラーが出た時に特にガッカリするのは、「投稿」「編集」といったアクションです。ですから、これらについて可逆性を用意して、いわゆる「CSRF対策」に頼らないことは、これからのWebプログラマーに必要とされる標準スキルと言えるかもしれません。

0 comments

Poster : GIJOE on 2006-05-25 06:34:07 (16004 reads)

in englishin japanese
最近、ELFさんとSQLにおける文字列エスケープ方法について議論をかわしたのですが、それが面白かったのでここにメモしておきます。

私自身はaddslashes()派です。その理由は以下のようなものです。

(A) 速度
(B) magic_quotes_gpc 環境との親和性
(C) 逆変換関数が存在する
(D) コネクションの有無に依らず利用可能
※とはいいつつ、コネクションがなければ利用できないのって、mysql_real_escape_string()くらいか?
※※ DBエンジンをMySQLとPostgreSQLで交換してもソースコードがそのまま流用できる、というメリットはあえて外してあります。

ELFさんはこれに対して、*_escape_string()派です。その理由はこちら。

(1) やろうとしていることが一目でわかる.マニュアルも引いても関数を使う意図がわかる
(2) grepでエスケープしているところを調べられる.関数名が変わってもsedですぐに置換できる
(3) 将来エスケープが変更されるのではなく拡張されることがあってもあわせてくれることをそれに期待できる

さらに、(B)への反論として、magic_quotes_gpc環境なんて自分が管理するサーバではあり得ないし、他者が管理するサーバであれば、magic_quotes_sybase=on環境だってあり得る、というのもありました。

さすがはELFさん。(1)〜(3)とも理にかなっています。最初、(1)や(2)については、私から「addslashes()だってSQL用の文字列エスケープ以外に用途なんてないでしょ」とか反論しましたが、ELFさんに、PHPソースコードを吐き出す場合などに、addslashes()を使う可能性を指摘され、納得しました。

ちなみに、(B)については、バックグラウンドの違いかな、という気はします。私自身、magic_quotes_gpc環境なんて駄目駄目だとは思いますが、想像以上に、デフォルトがmagic_quotes_gpc=onとなっているホスティングサービスは多いのです。(逆に、デフォルトでmagic_quotes_sybase=on環境のホスティングサービスは聞いたことありません)

Read more... | 1043 bytes more |2 comments

« 1 2 3 (4) 5 6 »
Login
Username or e-mail:

Password:

Remember Me

Lost Password?

Register now!