セキュアコーディングガイドラインの進化

先週、セキュアコーディングガイドラインを最新の状態に更新するため、Java Springの脆弱性について調査していました。プラットフォーム上の既存の課題を確認していたところ、JSPページでURLパラメータを表示する際のXSSに関する課題がいくつか見つかりました。不適切なコード例は、以下のようなものです。

   <input type="text" name="username" value="${param.username}">

正しい解決策はURLパラメータを完全に削除することですが、説明にはURLパラメータを適切にエスケープすることも安全であると記載されていました。

私の仕事は、開発者にとって明確であり、かつセキュアなコードを維持しつつ制限を最小限に抑えたセキュアコーディングガイドラインを策定することです。今回の場合、開発者が意図した機能を維持できるよう、URLパラメータをエスケープして安全に実装することを推奨したいと考えました。これにより、コードからXSS脆弱性を排除できます。上記の例は、次のように修正することで安全になります。

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

これが数日間、私たちのセキュアコーディングガイドラインとなっていましたが、ある時式言語インジェクションに関するOWASPのページを見つけました。このページでは、Spring式言語（SpEL）が悪用され、リモートコード実行を含む深刻な影響を及ぼすインジェクション攻撃について説明されています。私たちのガイドラインに従ったコードであっても、この脆弱性の影響を受ける可能性があるかどうかを判断するのは私の役割でした。そこで、SpEL式を評価する簡単なテストアプリケーションを作成し、XMLエスケープの有無で入力をテストして、検知できないシナリオがないか確認しました。その結果、XMLエスケープで捕捉されない悪意のある式が存在することが判明しました。動作するデモをGitHubで公開しており、こちらから確認できます。

もちろん、セキュアコーディングガイドラインを更新し、現在は「Spring式言語（SpEL）を使用してURLパラメータを表示または評価しないこと」としています。

この問題の全体的な影響度は「高」であり、理由は以下の通りです。 - 攻撃者がアプリケーションサーバー上の機能を変更・実行できる。 - データや機能への不正アクセス、アカウントの乗っ取り、リモートコード実行が可能。 - 攻撃が成功した場合、機密性および完全性が損なわれる。

https://www.owasp.org/index.php/Expression_Language_Injection