回避策をいろいろ見かけるようになったのでちょっとまとめる
サーブレットの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にパッチをあてる
- Struts1の脆弱性問題の対処方法 - エンタープライズギークス (Enterprise Geeks)
- Struts1の脆弱性対策（続き） - エンタープライズギークス (Enterprise Geeks)
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:マルチパートリクエスト対応すると多くなる
