セキュアコーディングガイドラインの変遷
先週、私はセキュアコーディングガイドラインを最新のものにするために、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
アプリケーション・セキュリティ・リサーチャー、R&Dエンジニア、博士号取得者
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
アプリケーション・セキュリティ・リサーチャー、R&Dエンジニア、博士号取得者
先週、私はセキュアコーディングガイドラインを最新のものにするために、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
先週、私はセキュアコーディングガイドラインを最新のものにするために、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
先週、私はセキュアコーディングガイドラインを最新のものにするために、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
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
