アカウント名:
パスワード:
コイツいっつもお漏らししてんな
セーフなやつを教えてくれwマイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。
Javaの場合は言語(SDK/ライブラリ)の問題とVMという実行環境の問題がセットになってますから目立つんでしょうね。
他言語でも、たとえば C/C++であれば glibc の脆弱性が今年はじめに見つかっていますがこれはWin環境(MSコンパイラ)では影響ありませんからC/C++ そのものの脆弱性とは認識されないところがあります。https://www.security-next.com/133636 [security-next.com]
あるいは C# だとVMがある点でJavaと似た感じですが、実行環境の脆弱性は Windows update で勝手に対策してくれてる感あってWindows自体の脆弱性に紛れている感ありますよね・・・。
それだけじゃない。Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。
Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]
今回はSpringのCVE-2022-22965について、それが12年前の脆弱性が蘇ったものであるという点などについて技術的な解説をしてみました。個人的にはStruts2と同じく、外部からgetterやsetterをかなり自由に呼べてしまうという根本的な設計思想そのものが非常に危険だと考えており、自分や自社の開発でSpringを利用することはありえないと考えています。あるクラスがgetterやsetterで「公開」しているのは基本的にJavaプログラム内のアクセスの話であり、HTTP経由でインターネットの向こう側からプロパティをセットしてくれ、と考えているわけではありません。TomcatのAccessLogValveを開発した人は間違いなくそう考えているだろうと思います。長いJavaの(特にエンタープライズ寄りの)開発の歴史においてJava Beansという概念があり、その流れからこのようなプロパティアクセスがウェブフレームワークに入り込んだのだろうと推測しますが、普通に常識的に冷静に考えてセキュリティ的にあり得ないのではというのが個人的な見解です。
今回はSpringのCVE-2022-22965について、それが12年前の脆弱性が蘇ったものであるという点などについて技術的な解説をしてみました。個人的にはStruts2と同じく、外部からgetterやsetterをかなり自由に呼べてしまうという根本的な設計思想そのものが非常に危険だと考えており、自分や自社の開発でSpringを利用することはありえないと考えています。
あるクラスがgetterやsetterで「公開」しているのは基本的にJavaプログラム内のアクセスの話であり、HTTP経由でインターネットの向こう側からプロパティをセットしてくれ、と考えているわけではありません。TomcatのAccessLogValveを開発した人は間違いなくそう考えているだろうと思います。長いJavaの(特にエンタープライズ寄りの)開発の歴史においてJava Beansという概念があり、その流れからこのようなプロパティアクセスがウェブフレームワークに入り込んだのだろうと推測しますが、普通に常識的に冷静に考えてセキュリティ的にあり得ないのではというのが個人的な見解です。
"Bean" 規約が良くなかった。publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、としてFWが設計されていれば getClass() 経由でのアレコレは無かった。
もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。
con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
まーたJavaか (スコア:0)
コイツいっつもお漏らししてんな
Re: (スコア:0)
セーフなやつを教えてくれw
マイナーな物はニュースにならないだけで、どの言語、環境でも致命的な問題は常に見つかっているよ。
Re: (スコア:2)
Javaの場合は言語(SDK/ライブラリ)の問題とVMという実行環境の問題がセットになってますから目立つんでしょうね。
他言語でも、たとえば C/C++であれば glibc の脆弱性が今年はじめに見つかっていますが
これはWin環境(MSコンパイラ)では影響ありませんから
C/C++ そのものの脆弱性とは認識されないところがあります。
https://www.security-next.com/133636 [security-next.com]
あるいは C# だとVMがある点でJavaと似た感じですが、
実行環境の脆弱性は Windows update で勝手に対策してくれてる感あって
Windows自体の脆弱性に紛れている感ありますよね・・・。
Re:まーたJavaか (スコア:0)
それだけじゃない。
Java製フレームワークって脆弱性を作り込みやすい危うい設計のものが多い印象。
例えを単純化すると、ユーザー入力を受け入れる口にそのまま生のSQLを流し込める作りというか。
Re:まーたJavaか (スコア:2, 興味深い)
Struts2が脆弱性連発してSpringに移行する流れがあったけど、SpringもELでgetterにアクセスし放題な構造はまったく同じなのでは? と思っていたら案の定だった。
https://www.scutum.jp/information/waf_tech_blog/2022/04/waf-blog-082.html [scutum.jp]
Re: (スコア:0)
"Bean" 規約が良くなかった。
publci field が開放されてる物であり、getter/setter でアクセス出来る物は隠蔽されてる物、
としてFWが設計されていれば getClass() 経由でのアレコレは無かった。
もうちょっと遡るとOOPでカプセル化の過剰なアゲが良く無かった。
Re: (スコア:0)
con.ecec(“delete“+hoge+...なんてことくらいどの言語の標準APIでもできるでしょ。標準APIというか各言語のDB操作関連APIの仕様か。