アカウント名:
パスワード:
■根本的解決 1)-1 SQL文の組み立てにバインド機構を利用する
素で謎なんですがSQLインジェクションって入力時の問題ですよね。
データをやりとりするメソッド/関数の所で縛っておく
システムの動作までおかしくなったら、 適切にエスケープされること、エスケープすれば問題無いデータしか出力されないこと、 どちらも保障できなくなるとか考えられませんか？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
サニタイズ言うな (スコア:4, 参考になる)
○出力データの適切なエスケープ
Re:サニタイズ言うな (スコア:1, おもしろおかしい)
Re: (スコア:0)
Re:サニタイズ言うな (スコア:1, おもしろおかしい)
夏だし。
Re:サニタイズ言うな (スコア:1, おもしろおかしい)
「安全なウェブサイトの作り方」読めって (スコア:1)
「RDBMSに」「SQLを」「出力するとき」の話だよ。
Re: (スコア:0)
Re: (スコア:0)
「evalしてくれるインタプリタに」
「危険なソースになっちゃってるかも知れない文字列を」
「出力するとき」
の話なんだよな。
ところで高木氏のこの文章が興味深いです。
http://takagi-hiromitsu.jp/diary/20051227.html#p03 [takagi-hiromitsu.jp]
＞そもそも、ASPから始まって、JSP、PHP、ERBと受け継がれてきた、 HTML中にプログラムを埋め込むというこの仕組みが、最初からデフォルトでエスケープされるように作られていたらよかったのに
Re:「安全なウェブサイトの作り方」読めって (スコア:1, すばらしい洞察)
Re:「安全なウェブサイトの作り方」読めって (スコア:1, 興味深い)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
システムの動作までおかしくなったら、
適切にエスケープされること、エスケープすれば問題無いデータしか出力されないこと、
どちらも保障できなくなるとか考えられませんか？
Re:サニタイズ言うな (スコア:1, すばらしい洞察)
何が誤った解釈を引き起こさせるかなんて入力時に分かる性質のものではありません。
SQL インジェクションを起こす「危険な文字列」と XSS を起こす「危険な文字列」は全く違いますから。
各脆弱性が起きる条件を少し調べて考えれば、出力時以外にはエスケープを行っても意味が無いことが分かるはずです。
変なデータを入力されてシステムの動作がおかしくなるなら、「変なデータ」を扱う部分でエスケープ相当の無害化が行われていないか不十分ということです。SQL インジェクションや XSS と本質はそう違いません。
データを利用する部分が適切に処理されていればそのような問題は発生しません。
# 仕様バグで仕様に脆弱性があってエスケープに相当するものが無い場合はちょっと困ったことになりますが…。
Re: (スコア:0)
そう。そもそも、
「出力時」以外のところでは、「エスケープ」という概念自体が成り立たない。
なぜなら、エスケープとはその場の文法に応じて定義されるものだから。
CGI入力とかのところで「エスケープします」とか言うこと自体、全くおかしい。
Re: (スコア:0)
>絶対に安全な「共通の」エスケープなんて存在しないのです。
「共通」にする必要は有るんでしょうか？
どこへ出力するかが決まっていればその出力先に見合ったエスケープをすればいいし、
ライブラリみたいに直接どこに出力するかは事前にわからない奴でも、
「xxxへ出力する(させられる)ことを想定しています」
ってインタフェース定義で謳えばいい
のじゃないんでしょうか？
裏返せば、なんでもかんでも同じく「String」型と見なすことが危険だ、とも言います。
同じだと見なすから代入互換だ
Re: (スコア:0)
メソッド/関数の引数に渡すことと、SQL を構築すること、HTML に出力することはすべて「出力」です。
その仕様に合わせて「出力時にエスケープ」するのが正しく、#1397612 の話は「サニタイズ」とは全く関係なく、むしろ「エスケープ」について語っているのではないかと思います。
「入力時のサニタイズ」に関するツリーの中での発言なので、#1396868 の 1 行目の「エスケープ」は「サニタイズ」の処理内容としての「エスケープ処理」の事です。
Re: (スコア:0)
> 同じだと見なすから代入互換だという考え方が生じてしまう。
> SQLString型とか
> HttpRequestString型とか
> HTMLString(HttpResponseString)型とか
> といったラッパーが有ったほうが良いのかな、とも思います。
フォーマットを持つ文字列と持たない文字列は別の型であるというのは私も同意見です。ただ、HTMLだけでも、テキストノード、属性値、マークを含む#PCDATAといった種類がある訳で、その違いを本当に型として表現すると、かなり複雑になります
Re: (スコア:0)
それ、CGIの考え方の暗黒面というか安易面が現れているように思います。
CGIはResponse(HTML)を
「標準出力にそのまま出せば」OK！という気楽さが売りですが、
そのとき無思慮に STDOUT.puts hoge などとしてしまう辺りに問題がありそうです。
(…今ふと思ったのですが、
(たとえばRubyだと)
上記のように書くならば、
STDOUTオブジェクトを乗っ取るという手が使えるかも知れません。)
で、どういうわけか、その困った文化が、
CGI以外の例えばJavaServlet系とかにも伝染しているように見えます。
>全要素に対してオブジェクトを生成するというオーバーヘッドの大
Re: (スコア:0)
それとも君のコンピュータは、ときどき、1 + 1 → 3 になったりするのかね？