スタイルズでは、Struts/Struts2およびSeasar2からSpringMVCの自動変換ツールをご提供し、移行コストの削減を図っています。このツールはコードを解析して、Struts/Struts2/Seasar2仕様のタグを、Spring/JSTL(Java Server Pages Standard Tag Library)のタグに自動変換します。このツールをご利用いただくことで機械的な移行作業コストを大幅に削減することが可能です。
また、変換ツール実施後は、変換不可能な部分の手動によるコード修正、書き直し、テストの実施をいたします。
1.ヒアリング( 動作環境、規模、システム内容等に関するもの)
2.機密保持契約(NDA)締結(ソースコードを受領するため)
3.ソースコード(プログラムソース・Warファイル)受領
4.自動コンバートツールの適用とチューニング
1.自動コンバート対象外ソースコードの解析
2.自動コンバート対象外ソースコードの手作業による修正・画面疎通テスト
※ステップ1/2はソースコードレベルでのサービス提供となるため仕様把握は行わない想定です。
・単体テスト・結合テスト・システムテスト
※弊社の「テスト支援サービス」を併用し単体テスト以降のテスト工程を実施致します。
変換ツールの適用だけではなく、多くを占める変換不可能な部分の手動によるコード修正、書き直し、テストも、実施しております。
JSP・アクション・フォームといった比較的共通性のある部分の移行は自社開発の変換ツールにより自動的に行います。
これにより、開発工数を削減し、納期・コストの縮小につなげます。
通常の移行作業では、システムの要件定義から始めるため、時間も工数も多くなりがちですが、現状のシステムをそのまま変換することで、変更の必要がない部分について無駄な要件定義をする必要がなくなります。
SpringMVCはSpring開発当初からあるコンポーネントで、現在も活発に開発が行われています。さらに移行実績があるスタイルズのノウハウを活用することで、迅速かつ移行後そのまま動くWebアプリケーションに仕上げます。
・Action/Form/JSP/その他 のファイル数とステップ数
・DB や Web Application Server などの変更を予定しているか?
・現行と移植先のプロダクト及びバージョンは?
・ビジネスロジック部分に Spring 等のフレームワークを利用しているか?
・ビジネスロジック部分に Struts 依存はあるか?
・O/R マッパーに iBatis/Hibernate 等のフレームワークを利用しているか?
・入力チェックに Validation XML を使用しているか?
・Form に Java で独自実装した validate メソッドがあるか?
・JavaScript はどの程度使用しているか?
・html:javascript タグの利用があるか?
・JSP に Struts 依存の Java コードが直接記載されていたりするか?
Javaリニューアルに関するご相談・お問合せはこちらから
1つの処理が複雑な傾向があり動作不良に遭遇すると原因究明に時間が掛かる傾向のあるシステム。
JavaScript による hidden タグの動的生成など移植の難易度を上げる実装もありました。
移植元Strutsバージョン | Struts 1.3 |
移植元のその他フレームワーク | Spring 3、MyBatis |
移植先バージョン | Spring 4 |
作業範囲 | ステップ1+ステップ2 |
Web アプリケーション数 | 3 |
アクション数 | 約1100メソッド |
ステップ数 | 約1,000,000ステップ |
工期 | 約5ヵ月 |
規模 | 約20人月 |
使用していた商用データベースを PostgreSQL にするミドルウェア変更も同時に実施した移行事例。
画面の遷移が特徴的なプロジェクトで、課題解決のためRedirectAttributes#addFlashAttribute を使用してリダイレクト先に Form と Error を引き渡す構成の Controller スケルトンを生成しました。
移植元Strutsバージョン | Struts 1.1~1.3 が混在 |
移植元のその他フレームワーク | Torque |
移植先バージョン | Spring 4 |
作業範囲 | ステップ1+ステップ2 |
Web アプリケーション数 | 6 |
アクション数 | 約1600メソッド |
ステップ数 | 約450,000ステップ |
工期 | 約3ヵ月 |
規模 | 約20人月 |
Seasar2 の O/R Mapper である S2JDBC への依存度が非常に高いアプリケーションの移行事例。
S2JDBC は Java コードでのメソッドチェーンを使用し、SQL を自動生成できるため自由度が高く、一般的な O/R Mapper (MyBatis, JPA) の標準機能では再現が困難です。
そのため、本プロジェクトでは S2JDBC で生成された SQL を採取し拡張した JPA, Hibernate でその SQL を使用することにより S2JDBC の動作を再現しました。
移植元Seasar2 バージョン | Seasar 2.4 (S2JDBC) |
移植先バージョン | Spring 4 |
作業範囲 | ステップ1+ステップ2 |
Web アプリケーション数 | 6 |
アクション数 | 約1400メソッド |
ステップ数 | 約150,000ステップ |
工期 | 約5ヵ月 |
規模 | 約25人月 |
データアクセスには Seasar2 の O/R Mapper である S2Dao を使用したアプリケーションの移行事例。
S2Dao の既存インターフェースを再利用して MyBatis への移植を行いました。
データアクセス層の動作確認は JUnit を使用して行い画面の動作確認とは分離しました。
データアクセス層を画面と切り離して動作確認することで画面の関心事にとらわれることなく効率的に作業できました。
移植元Seasar2 バージョン | Seasar 2.4 (S2Dao) |
移植先バージョン | Spring 5 |
作業範囲 | ステップ1+ステップ2 |
Web アプリケーション数 | 3 |
アクション数 | 約300メソッド |
ステップ数 | 約160,000ステップ |
工期 | 約5ヵ月 |
規模 | 約20人月 |
本事例では、Strus1 フレームワーク移行時に、商用データベースをオープン系データベースへと同時に移行することで、将来的に予測されていたライセンス費用を削減。
一方でそのライセンス費用をStrutsからSpringへマイグレーション費用として利用することで、システムトータルコストとしては同じ費用のまま、システム脆弱性の根本的な対応に貢献いたしました。
一般的に、Struts1からの移行先としては、通常、SpringかJAVA EEが候補とされていますが、
スタイルズでは、
Struts 1からの移行先として、ApacheではStruts 2を勧めていますが、以下の点から他のフレームワークに比べてStruts 2を採用するメリットが少ないと思われます。
企業のWebアプリケーション開発における基盤フレームワークの1つとして長い間利用されている「Struts」。今なお、Strutsをベースとしたアプリケーションは稼働し続けていますが、当初のStruts(Struts1)は開発が止まり、2013年4月にはサポートが終了しました。脆弱性への正式対応はなく、セキュリティ面では非常に危険な状態が続いています。
さらに、Struts2は任意のコードを実行できる脆弱性(S2-045、CVE-2017-5638)が見つかり、クレジットカード情報や個人情報の流出など、非常に深刻な被害が発生しています。
そのため、可能な限り迅速に、Struts系フレームワークの根本的な対策を行なうことが急務と言えます。
Seasar2はStrutsを利用したWebサイト同様に、2000年代後半から、会員100万人以上のWebサイトや、数十人月のプロジェクトを含む多くの業務システムでの採用実績があるフレームワークで、現在も多くのシステムで利用が続けられています。
しかしながらSeasar2プロジェクトが提供するプロダクトの多くは 2016年9月26日 をもってサポート切れ(End of Life)となっています。
これは、Struts同様に脆弱性への対応があった場合にも、プログラムの更新はされずに、自身で対応をしなくてはいけないということになります。
Javaリニューアルに関するご相談・お問合せはこちらから
10年以上前、Webシステム開発のデファクト・スタンダードは、Struts1でした。2013年4月にEOL(サポート切れ)を迎えましたが、多くのシステムがそのまま利用され続けているのが現状です。サポート切れ後には、大きな話題となった「ClassLoader を操作可能な脆弱性」等、多くのセキュリティ上の弱点が指摘されてきました。
https://www.ipa.go.jp/security/ciadr/vul/20140417-struts.html
https://www.lac.co.jp/security/alert/2014/04/24_alert_01.html
Apache Struts 2 に存在するとされた、リモートの第三者による任意のコード実行を許す脆弱性(CVE-2014-0094)と同様の問題がApache Struts 1 においても存在していることを確認しました。
この問題には、4月30日付けで、共通脆弱性識別子CVE-2014-0114が割り当てられました。
現在は、Struts 2 がサポートされていますが、2008年10月4日に最終版が公開され、2013年4月5日でサポート終了となった、Struts 1 においても、同様の脆弱性が存在します。しかし、Struts 1 はサポート終了しており、当該プロジェクトからは公式なアナウンスは出ておらず、今後正規の更新プログラムの提供もされないものと考えられます。
一方、Struts 1 が稼働しているWebサイトは、官公庁や公益法人、銀行などを含め国内に数多く存在しており、提供ベンダーからの個別サポートなど個々で特別な対応を行ってない限り攻撃に関して脆弱な状態のままと推測されます。
Struts2は、2014年以降、何度も脆弱性の問題が発見され、2017年に入っては、「任意のコードを実行できる脆弱性(S2-045、CVE-2017-5638)」が見つかり、クレジットカード情報や個人情報の流出など、非常に深刻な被害が発生しています。
[2016年04月18日]Apache Struts における任意のコードを実行される脆弱性(JVNDB-2016-002075)
[2017年03月09日] Apache Struts 2 の脆弱性 (S2-045) に関する注意喚起<<< JPCERT/CC Alert 2017-03-09 >>>
Struts系フレームワークは、過去に多くの脆弱性の指摘を受けている歴史からいって、今後も問題が発生する可能性が大きいことも指摘されており、以下の理由から被害が甚大化する可能性もあります。
・過去に多くのRCEを提供してきた実績があり、完全に攻撃者が目を付ける侵入経路となっている
・(WordPress等と比較して)大型で重要なWebシステムで使われているケースが多い
・日本国内においてはやや慎重なベンダーがシステムを運用しているケースが多く、バージョンアップが素早く行われない
そのため、Struts系フレームワークを採用している企業にとっては、可能な限り迅速に、根本的な対策を行なうことが急務と言えます。
stylezへのお問合せはこちらから
スタイルズ主催ウェビナー開催中
ウェビナー申し込み
〒101- 0052
東京都千代田区神田小川町1-2
風雲堂ビル6階