セキュア・コーディング・ガイドラインはどのように進化するか
先週、セキュア・コーディング・ガイドラインを最新のものにするために、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 エスケープを使用した場合と使用しない場合で入力をテストして、検出されないシナリオが見つかるかどうかを確認しました。実際に行ったのですが、XmlScape で捕捉された文字を一切含まない悪質な表現があります。作業デモをGitHubに公開しました。GitHubで見つけることができます。 ここに。
そしてもちろん、「Spring Expression Language (SpEl) を使用して URL パラメーターを表示したり評価したりしないでください」という安全なコーディングガイドラインを更新しました。
この問題の全体的な影響は、次の理由により深刻です。-攻撃者がアプリケーションサーバーの機能を変更したり呼び出したりする可能性があります。-データや機能への不正アクセス、アカウントの乗っ取り、リモートコードの実行。-攻撃成功による機密性と完全性の懸念
https://www.owasp.org/index.php/Expression_Language_Injection
アプリケーションセキュリティ研究者-研究開発エンジニア-博士候補者
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャ、開発者、CISO、またはセキュリティ関係者のいずれであっても、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
アプリケーションセキュリティ研究者-研究開発エンジニア-博士候補者
先週、セキュア・コーディング・ガイドラインを最新のものにするために、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 エスケープを使用した場合と使用しない場合で入力をテストして、検出されないシナリオが見つかるかどうかを確認しました。実際に行ったのですが、XmlScape で捕捉された文字を一切含まない悪質な表現があります。作業デモをGitHubに公開しました。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 エスケープを使用した場合と使用しない場合で入力をテストして、検出されないシナリオが見つかるかどうかを確認しました。実際に行ったのですが、XmlScape で捕捉された文字を一切含まない悪質な表現があります。作業デモをGitHubに公開しました。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 エスケープを使用した場合と使用しない場合で入力をテストして、検出されないシナリオが見つかるかどうかを確認しました。実際に行ったのですが、XmlScape で捕捉された文字を一切含まない悪質な表現があります。作業デモをGitHubに公開しました。GitHubで見つけることができます。 ここに。
そしてもちろん、「Spring Expression Language (SpEl) を使用して URL パラメーターを表示したり評価したりしないでください」という安全なコーディングガイドラインを更新しました。
この問題の全体的な影響は、次の理由により深刻です。-攻撃者がアプリケーションサーバーの機能を変更したり呼び出したりする可能性があります。-データや機能への不正アクセス、アカウントの乗っ取り、リモートコードの実行。-攻撃成功による機密性と完全性の懸念
https://www.owasp.org/index.php/Expression_Language_Injection
始めるためのリソース
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
