アカウント名:
パスワード:
認証無視で管理者権限アカウントとか脆弱性ってより裏仕様のバックドアばれちゃったみたいなはなしですね
本当にバグだったんだろうか
オンラインでソースが見られないのでよくわかりませんが、本家のアナウンスを見ると
The 'realname' parameter is not correctly filtered on user account creation, which could lead to user data override.
とあるので、「realname」というパラメータの入力値のチェック漏れでSQLインジェクションか何かを許してしていたのではないでしょうか。普通の脆弱性ではないかと。
高木センセーの仰ってる通り、サニタイズとかじゃなくてパラメータライズドクエリを使え、と。こんなメジャーなシステムでそんな初歩的なミスをしていたなんて、ちょっと驚きですね。
#ふと思ったんですが、プリペアドステートメントとパラメータライズドクエリ、どっちがメジャーな呼び方なんでしょうかね。
Oracleから入った私としてはPreparedStatementなんですが, これを使う理由としてはセキュリティ上の理由よりも, 実行時コンパイルとその再利用による性能向上が主目的でした.
# なにしろ性能が1桁違ってきますから, オンライントランザクション系なんかでは最重要のチューニングポイントで
こうした実行時コンパイル形式の実装をとっているDBMSでは, これが同時にパラメータの型制限になるわけですが, そうでない場合, 例えば渡されたパラメータを保存されているSQL文に字句展開して評価するような実装だと, セキュリティ的な効果は無いと以前に指摘されたことがあります. 具体的にどのDBMSがそうなのかは知らないのですが, 一般的な対策としては, パラメータ方式に頼らずに, サニタイズも併用するのが吉みたいです.
一例としてはMySQL Connector/J(MySQL+JAVA)がコネクタ内で字句展開していて、実際にSQLインジェクションを許す不具合を出してました。 [jvn.jp]現行バージョンも同様なのかは不明ですが、こういうケースも有るので多層防御の観点から入力段階でI/Fや設計した値の範囲内かのチェックは必要でしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
バックドア? (スコア:0)
認証無視で管理者権限アカウントとか
脆弱性ってより裏仕様の
バックドアばれちゃったみたいなはなしですね
本当にバグだったんだろうか
Re: (スコア:4, 参考になる)
オンラインでソースが見られないのでよくわかりませんが、本家のアナウンスを見ると
The 'realname' parameter is not correctly filtered on user account creation, which could lead to user data override.
とあるので、「realname」というパラメータの入力値のチェック漏れでSQLインジェクションか何かを許してしていたのではないでしょうか。
普通の脆弱性ではないかと。
Re: (スコア:2, 興味深い)
高木センセーの仰ってる通り、サニタイズとかじゃなくてパラメータライズドクエリを使え、と。
こんなメジャーなシステムでそんな初歩的なミスをしていたなんて、ちょっと驚きですね。
#ふと思ったんですが、プリペアドステートメントとパラメータライズドクエリ、どっちがメジャーな呼び方なんでしょうかね。
Re: (スコア:1)
Oracleから入った私としてはPreparedStatementなんですが, これを使う理由としてはセキュリティ上の理由よりも, 実行時コンパイルとその再利用による性能向上が主目的でした.
# なにしろ性能が1桁違ってきますから, オンライントランザクション系なんかでは最重要のチューニングポイントで
こうした実行時コンパイル形式の実装をとっているDBMSでは, これが同時にパラメータの型制限になるわけですが, そうでない場合, 例えば渡されたパラメータを保存されているSQL文に字句展開して評価するような実装だと, セキュリティ的な効果は無いと以前に指摘されたことがあります. 具体的にどのDBMSがそうなのかは知らないのですが, 一般的な対策としては, パラメータ方式に頼らずに, サニタイズも併用するのが吉みたいです.
Re:バックドア? (スコア:1)
こうした実行時コンパイル形式の実装をとっているDBMSでは, これが同時にパラメータの型制限になるわけですが, そうでない場合, 例えば渡されたパラメータを保存されているSQL文に字句展開して評価するような実装だと, セキュリティ的な効果は無いと以前に指摘されたことがあります. 具体的にどのDBMSがそうなのかは知らないのですが, 一般的な対策としては, パラメータ方式に頼らずに, サニタイズも併用するのが吉みたいです.
一例としてはMySQL Connector/J(MySQL+JAVA)がコネクタ内で字句展開していて、実際にSQLインジェクションを許す不具合を出してました。 [jvn.jp]
現行バージョンも同様なのかは不明ですが、こういうケースも有るので多層防御の観点から入力段階でI/Fや設計した値の範囲内かのチェックは必要でしょうね。