アカウント名:
パスワード:
なんか「+」で異常動作するのが盲点だったように書かれているけど、原因はシングルクォートのエスケープ漏れという基本中の基本だから。
今時、そんなエスケープ処理を自前でやらねーだろ。バインド変数使うだろ。
まぁ素人に毛が生えた程度の奴らはsqlに外部から入ってきた変数を直書きしている奴らをみるけど(某大手質問サイトで今システムを作ってますとかいう奴らによく見る。こいつらサービスは絶対に使いたくないなと傍観していますが)
それはそうだけど、今回のバグをどう表現するかっていうと、自分も安易に「エスケープ漏れ」とか言っちゃうなー。これに限らず生のコードを実行しちゃう系のものを一切合切。対策として「きちんとエスケープする」ではなく「バインド変数を使う」にはなるんだけどさ。
どうみても後半の文句を言いたかっただけじゃない冒頭部分に真面目に答えても意味ないよ
どうみても後半の文句を言いたかっただけじゃない 冒頭部分に真面目に答えても意味ないよ
一行目についてはそうかもしれないけど、二行目について、書き込んだ当人だけが読むわけじゃないから意味ないとは思わないです。
今時強制的にPreparedStatement使わせないFWなんて存在するのかよ、と思ってネタ元見てみたらかなり古いお手製ECってだけだったでござる。こんなありふれたWEBアプリケーションの古典的失敗談をいまさら記事にすることなの?
こんなありふれたWEBアプリケーションの古典的失敗談をいまさら記事にすることなの?
脆弱性の内容ではなくて、脆弱性診断を依頼する側にテストサイトでの実施の重要性を認識してもらうための定期ネタとしての価値があると思う。
要件として稼働環境に対してライブテストしてほしいってのはあるでしょ。常に完全に同一を保証できるテスト環境が存在するとは限らないんだし。SQLインジェクションを検知するだけなら参照系の命令でテンプレ作っとけってこと。客に対する注意喚起じゃなく、あくまでテスト者の失敗談であって、本番でテストを実施する際に注意すべき項目だよ。
テスト用メールアカウントとして存在しないであろうてきとーなドメインでテストしたら実際に実在する誰かにメールが飛んじゃったなんていうことがあるから必ず使われていないことが保障されてるexample.com使えってあるある失敗談としておもしろおかしく先輩に教わるのと同じレベルの話。
ちょっと的外れじゃないですか。パスワードリセットはシステムに備わっている機能なので参照系の命令云々は関係ないですよね。どちらかというと入力値が条件文として不適切だったという方が正しいです。
いやいや客に対する注意喚起にも使えるでしょ。本番環境でやった理由はテスト環境構築を省いてコストを削減することなんだけど、それのリスクも正しく認識してもらわないと。というか、多少なりともリスクを認識してたからこそバックアップをとってたと思うし。まぁこの程度は想定の範囲内で大したリスクではない、と言うなら別に良いのでしょうけど、皆が皆そうだとは思えないんで。
いいからネタ元読め。これ以上恥を晒すな。
脆弱性診断の段階で(調査だけにも関わらず)発生させてしまった事例、というのがトピックスであって、脆弱性そのものに深い意味はない。
昔のシステムならそらありえるわな。最近作られたようなのだとプリペアするのが当たり前当たり前当たり前!なんだから普通のインジェクションが入り込む余地がない。Webシステム系に入ったばかりで右も左もわからないような時期ですらSQL文への代入はプリペアするなんて常識だったし。WebのHello Worldレベルの基本。
ODBCの初期の頃はドライバの挙動がおかしいDB型が変などなどの理由であえて使わなかったりもしたけど
ログに出す際はバインド変数からSQL文に展開したりするけどね
今時、>原因はシングルクォートのエスケープ漏れという基本中の基本だから。こんな突っ込みをする奴がいるとは基本中の基本はプリペアードステートメントを使って処理をしてなかったことだろ。何が、エスケープ処理だよ。何年前の基本中の基本だ?
おまえは二度とDB接続をするプログラミングをするな。
「プリぺアステートメントを使わない」=「エスケープ漏れ」ってことなんじゃないの?色々方法はあるんだし。まぁ落ち着けや。
prepared statmentの方が確実なのは分かる。(MySQLなどは文字コードによってエスケープ対象が変わったりするので)
でもprepared statmentにすると実行したSQL自体の生ログが吐けないことがあるので、デバッグや問題発生時の原因究明に困ることってない?MySQLだったらバイナリログとかあるんだけど、他のDBMSだとどうしてるのか教えてほしい。
ちょっと知ったかしてる新人はこれだから困る。
新人は育てればいいだけだがいい歳なのに人を罵倒するだけのためにコメントするような奴が一番仕事していて困る
ライブラリー側でパースしているやつなら、プリペアードステートメントを使っていてもSQLインジェクションされるらしいですよ某システムはきちんとプリペアードステートメントを使っているでも、第三者に攻撃を依頼したら、できてしまった調べてみたら、ライブラリー側でプリペアードステートメントからSQLに復元する処理に漏れがあるのが原因だったなんてこともあるんで
ソースはこちらhttp://www.tokumaru.org/d/20100701.html [tokumaru.org]
PDOの場合、PDO::ATTR_EMULATE_PREPARESを指定しないとSQLインジェクションができるらしいです。
エスケープ漏れの前に、メアドとして正しいか確認しないの?
シングルクオートとか+がドメイン部にあったらその時点で弾けよと思う
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
「+」は関係ない (スコア:0)
なんか「+」で異常動作するのが盲点だったように書かれているけど、
原因はシングルクォートのエスケープ漏れという基本中の基本だから。
Re: (スコア:0)
今時、そんなエスケープ処理を自前でやらねーだろ。
バインド変数使うだろ。
まぁ素人に毛が生えた程度の奴らはsqlに外部から入ってきた変数を直書きしている奴らをみるけど
(某大手質問サイトで今システムを作ってますとかいう奴らによく見る。こいつらサービスは絶対に使いたくないなと傍観していますが)
Re:「+」は関係ない (スコア:1)
それはそうだけど、今回のバグをどう表現するかっていうと、自分も安易に「エスケープ漏れ」とか言っちゃうなー。これに限らず生のコードを実行しちゃう系のものを一切合切。対策として「きちんとエスケープする」ではなく「バインド変数を使う」にはなるんだけどさ。
LIVE-GON(リベゴン)
Re: (スコア:0)
どうみても後半の文句を言いたかっただけじゃない
冒頭部分に真面目に答えても意味ないよ
Re:「+」は関係ない (スコア:1)
一行目についてはそうかもしれないけど、二行目について、書き込んだ当人だけが読むわけじゃないから意味ないとは思わないです。
LIVE-GON(リベゴン)
Re: (スコア:0)
今時強制的にPreparedStatement使わせないFWなんて存在するのかよ、
と思ってネタ元見てみたらかなり古いお手製ECってだけだったでござる。
こんなありふれたWEBアプリケーションの古典的失敗談をいまさら記事にすることなの?
Re:「+」は関係ない (スコア:1)
こんなありふれたWEBアプリケーションの古典的失敗談をいまさら記事にすることなの?
脆弱性の内容ではなくて、脆弱性診断を依頼する側にテストサイトでの実施の重要性を認識してもらうための定期ネタとしての価値があると思う。
Re: (スコア:0)
要件として稼働環境に対してライブテストしてほしいってのはあるでしょ。
常に完全に同一を保証できるテスト環境が存在するとは限らないんだし。
SQLインジェクションを検知するだけなら参照系の命令でテンプレ作っとけってこと。
客に対する注意喚起じゃなく、あくまでテスト者の失敗談であって、
本番でテストを実施する際に注意すべき項目だよ。
テスト用メールアカウントとして存在しないであろうてきとーなドメインでテストしたら
実際に実在する誰かにメールが飛んじゃったなんていうことがあるから
必ず使われていないことが保障されてるexample.com使えって
あるある失敗談としておもしろおかしく先輩に教わるのと同じレベルの話。
Re: (スコア:0)
ちょっと的外れじゃないですか。
パスワードリセットはシステムに備わっている機能なので参照系の命令云々は関係ないですよね。
どちらかというと入力値が条件文として不適切だったという方が正しいです。
Re: (スコア:0)
いやいや客に対する注意喚起にも使えるでしょ。
本番環境でやった理由はテスト環境構築を省いてコストを削減することなんだけど、それのリスクも正しく認識してもらわないと。
というか、多少なりともリスクを認識してたからこそバックアップをとってたと思うし。
まぁこの程度は想定の範囲内で大したリスクではない、と言うなら別に良いのでしょうけど、
皆が皆そうだとは思えないんで。
Re:「+」は関係ない (スコア:3, すばらしい洞察)
いいからネタ元読め。
これ以上恥を晒すな。
脆弱性診断の段階で(調査だけにも関わらず)発生させてしまった事例、
というのがトピックスであって、脆弱性そのものに深い意味はない。
Re: (スコア:0)
昔のシステムならそらありえるわな。
最近作られたようなのだとプリペアするのが当たり前当たり前当たり前!なんだから
普通のインジェクションが入り込む余地がない。
Webシステム系に入ったばかりで右も左もわからないような時期ですら
SQL文への代入はプリペアするなんて常識だったし。
WebのHello Worldレベルの基本。
Re: (スコア:0)
ODBCの初期の頃はドライバの挙動がおかしいDB型が変などなどの理由で
あえて使わなかったりもしたけど
ログに出す際はバインド変数からSQL文に展開したりするけどね
Re: (スコア:0)
今時、
>原因はシングルクォートのエスケープ漏れという基本中の基本だから。
こんな突っ込みをする奴がいるとは
基本中の基本はプリペアードステートメントを使って処理をしてなかったことだろ。
何が、エスケープ処理だよ。何年前の基本中の基本だ?
おまえは二度とDB接続をするプログラミングをするな。
Re:「+」は関係ない (スコア:2)
「プリぺアステートメントを使わない」=「エスケープ漏れ」
ってことなんじゃないの?
色々方法はあるんだし。
まぁ落ち着けや。
Re:「+」は関係ない (スコア:1)
prepared statmentの方が確実なのは分かる。(MySQLなどは文字コードによってエスケープ対象が変わったりするので)
でもprepared statmentにすると実行したSQL自体の生ログが吐けないことがあるので、デバッグや問題発生時の原因究明に困ることってない?
MySQLだったらバイナリログとかあるんだけど、他のDBMSだとどうしてるのか教えてほしい。
Re: (スコア:0)
ちょっと知ったかしてる新人はこれだから困る。
Re: (スコア:0)
新人は育てればいいだけだが
いい歳なのに人を罵倒するだけのためにコメントするような奴が一番仕事していて困る
Re: (スコア:0)
ライブラリー側でパースしているやつなら、プリペアードステートメントを使っていてもSQLインジェクションされるらしいですよ
某システムはきちんとプリペアードステートメントを使っている
でも、第三者に攻撃を依頼したら、できてしまった
調べてみたら、ライブラリー側でプリペアードステートメントからSQLに復元する処理に漏れがあるのが原因だった
なんてこともあるんで
Re: (スコア:0)
ソースはこちら
http://www.tokumaru.org/d/20100701.html [tokumaru.org]
PDOの場合、PDO::ATTR_EMULATE_PREPARESを指定しないとSQLインジェクションができるらしいです。
Re: (スコア:0)
エスケープ漏れの前に、メアドとして正しいか確認しないの?
シングルクオートとか+がドメイン部にあったらその時点で弾けよと思う