セキュアコーディングガイドラインの変遷

先週、私はセキュアコーディングガイドラインを最新のものにするために、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 Expression Language (SpEL)がどのようにインジェクションに悪用され、リモートコードの実行を含む深刻な影響を与えるかが説明されています。私たちの安全なコーディング・ガイドラインに従ったコードが、この脆弱性の影響を受けるケースがあるかどうかを調べるのは、私の役目でした。そこで、SpEL式を評価する簡単なテストアプリケーションを作成し、Xmlエスケープを使用した場合と使用しない場合の入力をテストして、引っかからないシナリオがあるかどうかを確認しました。その結果、XmlEscapeに引っかからない文字を含む悪意のある式があることがわかりました。このデモはgithubで公開していますので、こちらをご覧ください。

そしてもちろん、安全なコーディングのガイドラインを更新しました。"Spring Expression Language (SpEL)を使用して、URLパラメータを表示または評価しないでください。"

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

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