アカウント名:
パスワード:
普通に考えて、ロギングライブラリとして求められる機能ではないように思うのだが、開発者にもともと脆弱性を仕込む意図があったのでは無いかと勘ぐってしまうな
例えば、異常検知やユーザーの異常行動の解析のためログの吐く先がDBの場合に、Appender インタフェースを使った JDBCAppenderがよく使われますが、そこでJNDIが使われてたりします。ご参考まで：https://logging.apache.org/log4j/2.x/manual/appenders.html
これに限らず、サービス化されている機能を介してログや設定を取ったり、ログを吐き出すのに、JNDIを使うことはまあ一般的です。
といっても、今回の脆弱性が、URI書式異常時の例外をトラップするもスルーし、しかも、”This is OK.”とかコメントを書いときながら、異常URIをそのままJNDI接続処理に回してた、修正はreturn文を1行追加するだけ、ってー感じの、ちょっと恥ずかしくなる類のミスなので、勘繰りたくもなりますよね…。
"This is OK."のコードは今回の脆弱性の修正過程で一時的に入ったもので、今回の脆弱性の原因じゃないですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
短慮かも知れないが (スコア:0)
普通に考えて、ロギングライブラリとして求められる機能ではないように思うのだが、
開発者にもともと脆弱性を仕込む意図があったのでは無いかと勘ぐってしまうな
Re:短慮かも知れないが (スコア:1)
例えば、
異常検知やユーザーの異常行動の解析のためログの吐く先がDBの場合に、
Appender インタフェースを使った JDBCAppenderがよく使われますが、
そこでJNDIが使われてたりします。
ご参考まで：https://logging.apache.org/log4j/2.x/manual/appenders.html
これに限らず、
サービス化されている機能を介してログや設定を取ったり、ログを吐き出すのに、
JNDIを使うことはまあ一般的です。
といっても、
今回の脆弱性が、URI書式異常時の例外をトラップするもスルーし、
しかも、”This is OK.”とかコメントを書いときながら、
異常URIをそのままJNDI接続処理に回してた、
修正はreturn文を1行追加するだけ、
ってー感じの、
ちょっと恥ずかしくなる類のミスなので、勘繰りたくもなりますよね…。
Re: (スコア:0)
"This is OK."のコードは今回の脆弱性の修正過程で一時的に入ったもので、今回の脆弱性の原因じゃないですよ。