「予告.in、XSS攻撃を受け不正コードを埋め込まれる」記事へのコメント

サニタイズ言うな

[tietew (6130)]

×入力データのサニタイズ
○出力データの適切なエスケープ

Re:サニタイズ言うな

[Anonymous Coward]

事件は入力段階で起こるんでないの？

Re:

[Anonymous Coward]

どこでどんなわけわからんデータが入り込もうとも、出力するときに適切にエスケープすれば問題は起こりえないって話です。

Re:サニタイズ言うな

[Anonymous Coward]

んで「入力のときにエスケープしとけば問題なくね？」っていう頭の悪い奴が現れて議論は堂々巡りになるんですね。
夏だし。

Re:サニタイズ言うな

[Anonymous Coward]

素で謎なんですがSQLインジェクションって入力時の問題ですよね。

「安全なウェブサイトの作り方」読めって

[matarillo (12702)]

情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方 [ipa.go.jp]

■根本的解決
1)-1 SQL文の組み立てにバインド機構を利用する

「RDBMSに」「SQLを」「出力するとき」の話だよ。

Re:

[Anonymous Coward]

いや、injectionだから入力時の話って言うこと…かもしれない。

Re:

[Anonymous Coward]

まあたしかにどれもこれも
「evalしてくれるインタプリタに」
「危険なソースになっちゃってるかも知れない文字列を」
「出力するとき」
の話なんだよな。

ところで高木氏のこの文章が興味深いです。

http://takagi-hiromitsu.jp/diary/20051227.html#p03 [takagi-hiromitsu.jp]
＞そもそも、ASPから始まって、JSP、PHP、ERBと受け継がれてきた、 HTML中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに

Re:「安全なウェブサイトの作り方」読めって

[Anonymous Coward]

うちの廊下の入口は、リビングの出口です。

Re:「安全なウェブサイトの作り方」読めって

[Anonymous Coward]

ぼくの肛門は入口でしょうか？出口でしょうか？

Re:

[Anonymous Coward]

あなたが美しいボク少女なら入口、そうでないなら出口です。

Re:

[Anonymous Coward]

少女ならわざわざ後ろの穴に突っ込むこともなかろうに。いや、別に否定はしないけど。

Re:

[Anonymous Coward]

「アナール学派と社会史」と似た感じのタイトルのDVDを一枚買ったきりなのに、なんかいろいろおすすめされてしまって…

Re:

[Anonymous Coward]

素で謎なんですがSQLインジェクションって入力時の問題ですよね。

違います。 入力時の問題と間違って理解したプログラマが減らない限り、XSSは減りませんな。。

Re:

[Anonymous Coward]

わけわからんデータでシステムの動作もわけわからんになり得る時代ですよ。
システムの動作までおかしくなったら、
適切にエスケープされること、エスケープすれば問題無いデータしか出力されないこと、
どちらも保障できなくなるとか考えられませんか？

Re:サニタイズ言うな

[Anonymous Coward]

とりあえず、SQL、HTML/XML/SGML、JavaScript、JSON 等々ウェブとその関連部分で利用される各種データ形式だけ考えても、絶対に安全な「共通の」エスケープなんて存在しないのです。

何が誤った解釈を引き起こさせるかなんて入力時に分かる性質のものではありません。
SQL インジェクションを起こす「危険な文字列」と XSS を起こす「危険な文字列」は全く違いますから。

各脆弱性が起きる条件を少し調べて考えれば、出力時以外にはエスケープを行っても意味が無いことが分かるはずです。

変なデータを入力されてシステムの動作がおかしくなるなら、「変なデータ」を扱う部分でエスケープ相当の無害化が行われていないか不十分ということです。SQL インジェクションや XSS と本質はそう違いません。
データを利用する部分が適切に処理されていればそのような問題は発生しません。
# 仕様バグで仕様に脆弱性があってエスケープに相当するものが無い場合はちょっと困ったことになりますが…。

Re:

[Anonymous Coward]

＞出力時以外にはエスケープを行っても意味が無いことが分かるはずです。

そう。そもそも、
「出力時」以外のところでは、「エスケープ」という概念自体が成り立たない。
なぜなら、エスケープとはその場の文法に応じて定義されるものだから。
CGI入力とかのところで「エスケープします」とか言うこと自体、全くおかしい。

Re:

[Anonymous Coward]

文脈を誤解してたらすみません。

>絶対に安全な「共通の」エスケープなんて存在しないのです。

「共通」にする必要は有るんでしょうか？

どこへ出力するかが決まっていればその出力先に見合ったエスケープをすればいいし、
ライブラリみたいに直接どこに出力するかは事前にわからない奴でも、
「xxxへ出力する(させられる)ことを想定しています」
ってインタフェース定義で謳えばいい
のじゃないんでしょうか？

裏返せば、なんでもかんでも同じく「String」型と見なすことが危険だ、とも言います。
同じだと見なすから代入互換だ

Re:

[Anonymous Coward]

データをやりとりするメソッド/関数の所で縛っておく

何らか(ユーザから受け取った、DB から取り出した、プログラムで構築した等)のデータを出力先とのインタフェースにとって「安全な形式」にするのがこのストーリー中でたくさん出現している「エスケープ」です。

メソッド/関数の引数に渡すことと、SQL を構築すること、HTML に出力することはすべて「出力」です。
その仕様に合わせて「出力時にエスケープ」するのが正しく、#1397612 の話は「サニタイズ」とは全く関係なく、むしろ「エスケープ」について語っているのではないかと思います。

「入力時のサニタイズ」に関するツリーの中での発言なので、#1396868 の 1 行目の「エスケープ」は「サニタイズ」の処理内容としての「エスケープ処理」の事です。

Re:

[Anonymous Coward]

> 裏返せば、なんでもかんでも同じく「String」型と見なすことが危険だ、とも言います。
> 同じだと見なすから代入互換だという考え方が生じてしまう。
> SQLString型とか
> HttpRequestString型とか
> HTMLString(HttpResponseString)型とか
> といったラッパーが有ったほうが良いのかな、とも思います。

フォーマットを持つ文字列と持たない文字列は別の型であるというのは私も同意見です。ただ、HTMLだけでも、テキストノード、属性値、マークを含む#PCDATAといった種類がある訳で、その違いを本当に型として表現すると、かなり複雑になります

Re:

[Anonymous Coward]

>HTMLだけそういったものの定番が無いですが

それ、CGIの考え方の暗黒面というか安易面が現れているように思います。

CGIはResponse(HTML)を
「標準出力にそのまま出せば」OK！という気楽さが売りですが、
そのとき無思慮に STDOUT.puts hoge などとしてしまう辺りに問題がありそうです。

(…今ふと思ったのですが、
(たとえばRubyだと)
上記のように書くならば、
STDOUTオブジェクトを乗っ取るという手が使えるかも知れません。)

で、どういうわけか、その困った文化が、
CGI以外の例えばJavaServlet系とかにも伝染しているように見えます。

>全要素に対してオブジェクトを生成するというオーバーヘッドの大

Re:

[Anonymous Coward]

システムの動作までおかしくなったら、 適切にエスケープされること、エスケープすれば問題無いデータしか出力されないこと、 どちらも保障できなくなるとか考えられませんか？

全然。コンピュータは書かれたプログラム通りに動作する。
それとも君のコンピュータは、ときどき、1 + 1 → 3 になったりするのかね？

Re:

[Anonymous Coward]

先のコメントについてた高木センセイのblogを読んでも何が言いたいのかよく分からんかったんけど、そういうことね。

最初からこう言ってくれればよいのに。

# セキュリティの素人なのでAC

Re:

[Anonymous Coward]

原文は「入力データのサニタイズはセキュリティの基礎」です。
出力データの適切なエスケープは「セキュリティの基礎」ではありません。

仮に入力時に充分な検査をしたり、そもそも利用者からの入力を求めないシステムだとしても、
HTMLを出力する際に出力データの適切なエスケープをしていないシステムは間違っています。