アカウント名:
パスワード:
やってみろSQLインジェクション等されまくって個人情報ダダ漏れになって簡単に死ねるから
「佐々木」の入力すら想定できない開発者が、SQLのドキュメントに基づいて適切にエスケープできるわけないじゃん
ヒント:Prepared Statement
DBプログラミングやったことないと知らないかもだけど、もはや基本テクニックの一つ。#車輪の再発明を避けるってのはこういうことだ。、
全部を監督できる環境ならいいけど、他システムからの入力だのがあって文字コード変換や予期しないサロゲートペアだのが放り込まれて、エスケープしたつもりがU+00A5を通しちゃいましたとかなるからだろ
他システムからの入力をエスケープできない段階でアプリ関係なくアウトなのでは
クライアント側に緩和策入れて「直叩き対策は?」って聞くと「アプリの改変は規約違反だから起こらない」とか意味不明の言い訳するやついるよね
社内の端末の専用アプリからしか入力がないエスケープが必要がなかったシステムに、スマホからユーザが入力した文字列が入ってくるようになったとき、エスケープ処理を追加するより、ホワイトリストで許されるものしか通さないようにするほうが楽じゃね?
って思うじゃん? いや、確かに楽だよ。楽だけどさ、結局今回のような問題が発生するわけで。
ホワイトリスト制限するのは自由だけど、だからといってエスケープ処理をしなくていいという考えは危険だと思うよ。
サーバで落とせや!!!!!!!1
> 意味のある記号をエスケープすればいいだけいやぁ、『々』を見落としちゃう現場ですよ?「すればいいだけ」なんて言ってると絶対にまた見落としが出ます。
というか、意味のある記号だけエスケープって、文字列のデータしか考慮してないですか?数値を埋め込むべきところにandとか通常の英字をぶち込まれるのは考慮しないつもりなんですか?全部文字列データとして渡せば解決と思ってますか?暗黙の型変換でもっと色々死ねますよ?
SQLインジェクション対策に入力文字制限とか普通しないって。かな英数字ならともかく、漢字の範囲なんか簡単にはできないでしょ。これアプリのレビュー見ると散々だよ?この問題だけじゃなく至る所でやらかしてる感じだよ。どんな開発会社に頼んだんだよ。
そういうSQLエスケープ処理は、データベース製品についてくるライブラリの仕事じゃないの。暗号処理と一緒。
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
上の方でサニタイズ言ってる人たちがそれに当たりそうで怖い・・・w
いや、本当にそうでも、自分で書こうとする人が後を絶たない知らないだけなんだろうけど
今どきweb設計するときにHTMLタグエスケープしないだの、SQL place holder使わないだのなんてありえないでしょ。だからこそ文字種制限に意味あるのかと感じるんだけど。
実際コードを書いていないシステムエンジニアやセキュリティエンジニアの方は知らないでしょうが、複雑なシステムではプレースホルダは非現実的で、バグの温床になりますよ。
そういう人から、プレースホルダ使えと言われると、現場はいい迷惑です。現実的に考えて 価格.com のスペック検索 [kakaku.com] をプレースホルダで作れますか?
理論上不可能ではありませんが、場合分けでif文等が数十重にもなって、訳がわからないことになり、製作時間も数十倍、バグ発生リスクも数十倍になるでしょうね。
あと、プレースホルダ使えばSQLインジェクションが理論上絶対に発生しないといった出鱈目をまき散らしているセキュリティの専門家も多くいらっしゃ
おいおい、ユーザにデータベースやテーブル名を指定させるのかww?まず設計を見直そうな。
そもそも、バリデーションとエスケープは別の概念だぞ。
> 価格.com のスペック検索
似たようなもの作ったことあるけどさ、 conds = [] conds << [" COLOR = ?" , foo] conds << [" SIZE = ?" , bar]みたいに投入していって、 conds.map{ |v| v.first ].join(" AND ")と取り出せばいいだけじゃないかな。
素人かよwwwプレースホルダ動的に作れば良いんだよw
逆にどこら辺が複雑だと思ってるの??
会社で10年以上運用してるシステムも絵文字でもなんでも受け付ける仕様なんだけどダメなかな?プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
> プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
それで正しいですよ。むしろ「文字種制限しないと SQL Injection や XSS の危険があるようなシステム」の方がはるかに危ないです。プレースホルダーとか適切なフレームワークを使ってないっていう意味ですからね。
>適切なフレームワーク某言語に被せる形の名ばかりフレームワークみたいなのがあるからねぇ…#フレームワーク名乗るなよと言いたい
残念なことに、世の中にはPREPAREがない似非SQLサーバが蔓延ってる。そんなもの捨ててPREPAREすればいいだけ。
特許庁もこのレベルの連中がやってんだろうなあ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
何で文字種制限しようとするのか (スコア:0)
Re:何で文字種制限しようとするのか (スコア:0)
やってみろ
SQLインジェクション等されまくって
個人情報ダダ漏れになって
簡単に死ねるから
Re:何で文字種制限しようとするのか (スコア:1)
SQLとして意味のある記号をエスケープすればいいだけなのに、SQLとして意味がある記号が何か分からない(ドキュメント見れば全部書いてあるのに!)から手当たり次第に制限してんだよね。
そんなカーゴカルトプログラミング手法で本当に危険な記号を排除できてるとどうして信じられるんだろう・・・
Re:何で文字種制限しようとするのか (スコア:3, すばらしい洞察)
「佐々木」の入力すら想定できない開発者が、SQLのドキュメントに基づいて適切にエスケープできるわけないじゃん
Re: (スコア:0)
ヒント:Prepared Statement
DBプログラミングやったことないと知らないかもだけど、もはや基本テクニックの一つ。
#車輪の再発明を避けるってのはこういうことだ。、
Re: (スコア:0)
全部を監督できる環境ならいいけど、他システムからの入力だのがあって文字コード変換や予期しないサロゲートペアだのが放り込まれて、エスケープしたつもりがU+00A5を通しちゃいましたとかなるからだろ
Re:何で文字種制限しようとするのか (スコア:2, すばらしい洞察)
他システムからの入力をエスケープできない段階でアプリ関係なくアウトなのでは
Re: (スコア:0)
クライアント側に緩和策入れて「直叩き対策は?」って聞くと「アプリの改変は規約違反だから起こらない」とか意味不明の言い訳するやついるよね
Re: (スコア:0)
社内の端末の専用アプリからしか入力がないエスケープが必要がなかったシステムに、スマホからユーザが入力した文字列が入ってくるようになったとき、エスケープ処理を追加するより、ホワイトリストで許されるものしか通さないようにするほうが楽じゃね?
Re:何で文字種制限しようとするのか (スコア:2, すばらしい洞察)
って思うじゃん? いや、確かに楽だよ。楽だけどさ、結局今回のような問題が発生するわけで。
ホワイトリスト制限するのは自由だけど、だからといってエスケープ処理をしなくていいという考えは危険だと思うよ。
Re: (スコア:0)
サーバで落とせや!!!!!!!1
Re: (スコア:0)
> 意味のある記号をエスケープすればいいだけ
いやぁ、『々』を見落としちゃう現場ですよ?
「すればいいだけ」なんて言ってると絶対にまた見落としが出ます。
というか、意味のある記号だけエスケープって、文字列のデータしか考慮してないですか?
数値を埋め込むべきところにandとか通常の英字をぶち込まれるのは考慮しないつもりなんですか?
全部文字列データとして渡せば解決と思ってますか?暗黙の型変換でもっと色々死ねますよ?
Re:何で文字種制限しようとするのか (スコア:1)
SQLインジェクション対策に入力文字制限とか普通しないって。
かな英数字ならともかく、漢字の範囲なんか簡単にはできないでしょ。
これアプリのレビュー見ると散々だよ?
この問題だけじゃなく至る所でやらかしてる感じだよ。
どんな開発会社に頼んだんだよ。
Re: (スコア:0)
そういうSQLエスケープ処理は、データベース製品についてくるライブラリの仕事じゃないの。
暗号処理と一緒。
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
Re: (スコア:0)
上の方でサニタイズ言ってる人たちがそれに当たりそうで怖い・・・w
Re: (スコア:0)
え、自分でエスケープ処理を書いているって? そもそも、それが危ない。。
いや、本当にそう
でも、自分で書こうとする人が後を絶たない
知らないだけなんだろうけど
Re: (スコア:0)
今どきweb設計するときにHTMLタグエスケープしないだの、SQL place holder使わないだのなんてありえないでしょ。
だからこそ文字種制限に意味あるのかと感じるんだけど。
複雑なシステムではプレースホルダは非現実的 (スコア:0)
実際コードを書いていないシステムエンジニアやセキュリティエンジニアの方は知らないでしょうが、
複雑なシステムではプレースホルダは非現実的で、バグの温床になりますよ。
そういう人から、プレースホルダ使えと言われると、現場はいい迷惑です。
現実的に考えて 価格.com のスペック検索 [kakaku.com] をプレースホルダで作れますか?
理論上不可能ではありませんが、場合分けでif文等が数十重にもなって、訳がわからないことになり、製作時間も数十倍、バグ発生リスクも数十倍になるでしょうね。
あと、プレースホルダ使えばSQLインジェクションが理論上絶対に発生しないといった出鱈目をまき散らしているセキュリティの専門家も多くいらっしゃ
Re: (スコア:0)
おいおい、ユーザにデータベースやテーブル名を指定させるのかww?
まず設計を見直そうな。
そもそも、バリデーションとエスケープは別の概念だぞ。
Re: (スコア:0)
> 価格.com のスペック検索
似たようなもの作ったことあるけどさ、
conds = []
conds << [" COLOR = ?" , foo]
conds << [" SIZE = ?" , bar]
みたいに投入していって、
conds.map{ |v| v.first ].join(" AND ")
と取り出せばいいだけじゃないかな。
Re: (スコア:0)
素人かよwww
プレースホルダ動的に作れば良いんだよw
逆にどこら辺が複雑だと思ってるの??
Re: (スコア:0)
会社で10年以上運用してるシステムも絵文字でもなんでも受け付ける仕様なんだけどダメなかな?
プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
Re:何で文字種制限しようとするのか (スコア:3, すばらしい洞察)
> プレースホルダー使ってれば大丈夫と気楽に考えてるんだが…
それで正しいですよ。
むしろ「文字種制限しないと SQL Injection や XSS の危険があるようなシステム」の方がはるかに危ないです。
プレースホルダーとか適切なフレームワークを使ってないっていう意味ですからね。
Re: (スコア:0)
>適切なフレームワーク
某言語に被せる形の名ばかりフレームワークみたいなのがあるからねぇ…
#フレームワーク名乗るなよと言いたい
Re: (スコア:0)
残念なことに、世の中にはPREPAREがない似非SQLサーバが蔓延ってる。
そんなもの捨ててPREPAREすればいいだけ。
Re: (スコア:0)
特許庁もこのレベルの連中がやってんだろうなあ