アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
サニタイズ言うな (スコア:4, 参考になる)
○出力データの適切なエスケープ
Re: (スコア:1, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
システムの動作までおかしくなったら、
適切にエスケープされること、エスケープすれば問題無いデータしか出力されないこと、
どちらも保障できなくなるとか考えられませんか?
Re: (スコア:1, すばらしい洞察)
何が誤った解釈を引き起こさせるかなんて入力時に分かる性質のものではありません。
SQL インジェクションを起こす「危険な文字列」と XSS を起こす「危険な文字列」は全く違いますから。
各脆弱性が起きる条件を少し調べて考えれば、出力時以外にはエスケープを行っても意味が無いことが分かるはずです。
変なデータを入力されてシステムの動作がおかしくなるなら、「変なデータ」を扱う部分でエスケープ相当の無害化が行われていないか不十分ということです。SQL インジェクションや XSS と本質はそう違いません。
データを利用する部分が適切に処理されていればそのような問題は発生しません。
# 仕様バグで仕様に脆弱性があってエスケープに相当するものが無い場合はちょっと困ったことになりますが…。
Re: (スコア:0)
>絶対に安全な「共通の」エスケープなんて存在しないのです。
「共通」にする必要は有るんでしょうか?
どこへ出力するかが決まっていればその出力先に見合ったエスケープをすればいいし、
ライブラリみたいに直接どこに出力するかは事前にわからない奴でも、
「xxxへ出力する(させられる)ことを想定しています」
ってインタフェース定義で謳えばいい
のじゃないんでしょうか?
裏返せば、なんでもかんでも同じく「String」型と見なすことが危険だ、とも言います。
同じだと見なすから代入互換だ
Re: (スコア:0)
> 同じだと見なすから代入互換だという考え方が生じてしまう。
> SQLString型とか
> HttpRequestString型とか
> HTMLString(HttpResponseString)型とか
> といったラッパーが有ったほうが良いのかな、とも思います。
フォーマットを持つ文字列と持たない文字列は別の型であるというのは私も同意見です。ただ、HTMLだけでも、テキストノード、属性値、マークを含む#PCDATAといった種類がある訳で、その違いを本当に型として表現すると、かなり複雑になります
Re:サニタイズ言うな (スコア:0)
それ、CGIの考え方の暗黒面というか安易面が現れているように思います。
CGIはResponse(HTML)を
「標準出力にそのまま出せば」OK!という気楽さが売りですが、
そのとき無思慮に STDOUT.puts hoge などとしてしまう辺りに問題がありそうです。
(…今ふと思ったのですが、
(たとえばRubyだと)
上記のように書くならば、
STDOUTオブジェクトを乗っ取るという手が使えるかも知れません。)
で、どういうわけか、その困った文化が、
CGI以外の例えばJavaServlet系とかにも伝染しているように見えます。
>全要素に対してオブジェクトを生成するというオーバーヘッドの大きさが導入の進まない理由かもしれません。
「わびさび配列」などの流派では、処理エンジンをCで書くことで性能を稼いでいるようですね。
>HTTP Requestならそれをラップするオブジェクトとか。
ほんの数年前まで、
「そんなものがあると重くなるだけだ。自力で処理しろ」
と吼えていた人が
(そういえばスラドに)居たと思います。
もし彼のいいぶんが正しかったのだとすると、
逆にいえばここ数年でそのオーバーヘッドが気にならないくらい
CPU速度が向上した証ともいえそうです。
この調子でいけば、HTML出力のラッパーも
数年後には実用的になるかも知れません。
#数年ぶりに某システムでCコンパイラ動かしたら、あまりに速くなってて驚愕したのでAC。以前だと数分単位だったのが今だと1秒以下。ここまで速くなると方法論が変わります。