Jtest －Java対応自動テストツール－
今月のピックアップ
Parasoft Jtest 8.3 技術資料
セキュアコーディングのすすめ 2
WebGoat Example プロジェクト
Jtestを使用する
このアプリケーションはどこに脆弱性があったのでしょうか。このアプリケーションに対してJtestの静的解析を実行してみたいと思います。ここで問題になるソースに対してSecurity Assessmentテストコンフィギュレーションを使用してテストを行います。
[対象ファイル]
WebGoat-5.1 > Java Source > org.owasp.webgoat.lessons > ThreadSafetyProblem.java
図 5 Security Assessmentテストコンフィギュレーションによるテスト
結果を確認する
いくつか違反が検出されますが、その中でもスレッドと同期化の違反に注目します。
図 6 Jtest スレッドと同期化の違反
さらにドリルダウンすると、違反箇所が表示されます。
図 7 Jtest 違反の発生箇所
図 7 Jtest 違反の発生箇所をみると、このコードがスレッドセーフではなく、staticフィールドに同期化が必要な可能性がある、という旨のメッセージが表示されています。
ソースファイルの該当箇所を確認します。
図 8 検出箇所のソース
図 8 検出箇所のソースを確認すると、赤い四角で囲まれている部分が検出箇所です。クラスフィールドであるcurrentUserに値が設定されている箇所で違 反が検出されています。さらに上の青い四角で囲まれている箇所がcurrentUserの宣言箇所です。currentUserはstaticフィールドですが、final で宣言されていない、という事が今回の指摘です。
つまり、static 変数のインスタンスはひとつしかないため、すべてのアクセスを同期化するのでない限り、final ではない static 変数は同時アクセスがあった場合に予期しない変数の書き換わりが発生する可能性があります、ということを指摘しています。
Webアプリケーションのようなマルチスレッド環境では、スレッドが完了する前に別のスレッドが値を変更してしまう場合があるということです。そのため、脆弱性の確認を行ったときに2人のユーザが同時にアクセスすると、タイミングによってはスレッド上にひとつしかないcurrentUserのインスタンスにアクセスしたため、別のユーザ情報が表示されてしまったわけです。
この脆弱性は、今回の例のように誤った情報を第三者に公開してしまったり、計算結果が合わないなどの問題が発生します。そして、特定のタイミングでしか問題が発生しない場合が多いため、調査や追跡が困難な問題を発生させます。同期化の問題はインスタンスとWebアプリケーションのスレッドの関係を理解していない様な未熟な開発者に良く見られます。
いかがでしょうか。このように、Jtestを使ってソースをチェック自動化することで一定レベルの品質を保つことが出来るということをご理解頂けたでしょうか。今回紹介した内容は、Jtest チュートリアルにも記載されています。
Jtest8.3のセキュリティ機能に関しては無償のJtest セキュアコーディングセミナーを定期的に開催しております。興味がある場合はホームページにて日程を確認の上、お申し込みください。
また、無償のセキュアコードチェック評価支援も準備しておりますので、同様に興味がある場合はぜひお問い合わせください。