アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
サニタイズ言うな (スコア: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といった種類がある訳で、その違いを本当に型として表現すると、かなり複雑になります。しかも利用者が型の種類と使うべき場所を覚える必要があるわけで、この方法は現実的ではないと思われます。
もう少し考えてみると、文字列が持つべきフォーマットというのは、その文字列が使われる場所によって決まります。使われる場所の方はその文字列がどういうフォーマットであるべきがということをあらかじめ知っているのですから、そっちの方でが特殊文字等を良きに計らってくれれば良いのではないかということに思い当たります。
そう考えると、実はそういうものはすでにあるんですよね。SQLならバインド機構、HTTP Requestならそれをラップするオブジェクトとか。HTMLだけそういったものの定番が無いですが、DOM的に扱うテンプレートシステムというのはいくつか存在します。ノードを表すオブジェクトが良きに計らってくれる訳ですが、全要素に対してオブジェクトを生成するというオーバーヘッドの大きさが導入の進まない理由かもしれません。
Re: (スコア:0)
それ、CGIの考え方の暗黒面というか安易面が現れているように思います。
CGIはResponse(HTML)を
「標準出力にそのまま出せば」OK!という気楽さが売りですが、
そのとき無思慮に STDOUT.puts hoge などとしてしまう辺りに問題がありそうです。
(…今ふと思ったのですが、
(たとえばRubyだと)
上記のように書くならば、
STDOUTオブジェクトを乗っ取るという手が使えるかも知れません。)
で、どういうわけか、その困った文化が、
CGI以外の例えばJavaServlet系とかにも伝染しているように見えます。
>全要素に対してオブジェクトを生成するというオーバーヘッドの大