てきとうなメモ

本の感想とか技術メモとか

Struts1の脆弱性(CVE2014-0094)の回避策いろいろ

Security Java

回避策をいろいろ見かけるようになったのでちょっとまとめる

サーブレットのFilterでフィルタ

FilterでStrutsにリクエストが来る前にclassを含むクエリパラメタをエラーにしてしまう。

リンク先のコードだとマルチパートリクエストに対応できていない。マルチパートリクエストに対応することは可能だが、Strutsのコードの外なのでStrutsのコードが変更されるとうまくいかなくなるかもしれない

StrutsのRequestUtilsにパッチをあてる

RequestUtilsでbeanutilsを利用している直前にclass等を含むクエリパラメタを無視するようにしている。

マルチパートリクエストと通常のリクエストのパラメタをまとめた後に処理しているので、マルチパートリクエストにも対応。

コードの修正量が少ないのとstruts1.1以降全てに対応している部分がメリットかな。

beanutilsの外で実装しているので、beanutilsの仕様が変化するとうまくいかなくなるかもしれない。

StrutsのRequestProcessorを拡張

RequestProcessorを拡張してリクエストを処理する部分でclassを含むようなリクエストをエラーにしている。

マルチパートの部分のコードなどをコピーしているのでコード量が多いかな。

RequestProcessorを設定できるのはStruts1.3からのはず。

beanutilsの外で実装しているので、beanutilsの仕様が変化するとうまくいかなくなるかもしれない。

beanutilsのget/setNestedPropertyにパッチをあてる

beanutilsの中で途中でClassクラスなどを取得しないようにしている

beanutilsを直接いじるのでバージョンアップされた場合に管理が面倒かな。パッチをあて直さないといけない。Struts1を使っているということはアプリに同梱するbeanutilsをアップデートする可能性は小さいと思うが

beanutilsの内部に書かれているので、パラメタをparseする部分はbeanutilsにまかせることができる

beanutilsのDefaultResolverを拡張

beanutilsのpublicなAPIを利用しているので、パラメタのparseはbeanutilsにまかせることができる

beanutilsを直接修正していないのでbeanutilsがバージョンアップされた時の管理が面倒になるということがない。

DefaultResolverを拡張して設定できるのはbeanutils 1.8からの機能。

beanutilsの設定をいじってしまうので、他のライブラリなどがclass経由でプロパティを設定していた場合そこが動かなくなる可能性がある。可能性はまずないとは思うけど。

まとめ

方法 修正対象 修正量 strutsのバージョン beanutilsのバージョン beanutilsのparseを利用
Filter アプリ 多*1 - - ×
RequestUtils Struts 少 1.1〜 - ×
RequestProcessor アプリ 多 1.3 - ×
get/setNestedProperty beanutils 少 - ? ◯
DefaultResolver アプリ 少 1.2〜 1.8〜 ◯

*1:マルチパートリクエスト対応すると多くなる