コーダーがセキュリティを征服する OWASP トップ 10 API シリーズ-認証失敗
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が Base64 を使ってそのクッキーを解読すると、そのクッキーがアプリケーショ ンのセッションとユーザをどのように定義しているかを知ることができます。例えば、デコードすると次のようなJSONが表示されるかもしれません。
{
"username" : "ShadyGuy",
"role" : "user"
{
その時点で、悪意のあるユーザーは、自分のユーザー名、役割、またはその両方を変更することができます。いくつかの値を変更することで、より高い権限レベルを持つ別のユーザーになることができます。
{
"username" : "GoodGuy",
"role" : "admin"
{
その時点で、攻撃者がその情報を再コード化し、それをクッキーの値として設定すると、実質的に、より高い権限レベルを持つ新しいユーザになります。このような変更を防ぐ方法がない限り、アプリケーションがその変更を受け入れる可能性が高いです。
認証の失敗や設定ミスをなくす
認証に失敗すると、全体的なセキュリティが損なわれる可能性が高くなります。しかし、アプリケーションをコーディングする際にいくつかの重要なガイドラインに従うことで、すべてを安全に保つことができます。
まず第一に、ユーザーがプログラムの機能にアクセスできるようにするための認証チェックをどこにでも必ず入れること。もし、認証チェックが全く存在しないのであれば、最初から勝負はついていません。
ベストプラクティスの観点からは、ユーザーがアクセスできるURLでセッションIDを公開しないようにすることが一つの良い点です。上記の2番目の例では、認証の失敗について、攻撃者がセッション・クッキーを解読しようとするのを防ぐには、セッション・クッキーが攻撃者の目に触れない方がずっと簡単です。
また、多要素認証を導入するのも良いアイデアです。これには、タイトなスケジュールでパスワードをアルゴリズムで生成するハードウェア・トークンを使用すると安全です。このようなデバイスをユーザーに提供できない場合は、SMSのテキストメッセージでも対応可能です。ただし、ユーザーからのリクエストは、30秒間に3〜4回という適度な回数に制限し、コードは数分で一斉に失効するようにする必要があります。英数字のコードを使用することで、潜在的なパスワードに文字や数字を追加してセキュリティを向上させることもできます。
最後に、可能であれば、ユーザー名や予測可能な連番の値をセッションIDとして使用することは避けてください。代わりに、毎回ランダムなセッションIDを生成する、安全なサーバーサイドセッションマネージャを使用してください。
安全な認証方法を実装することは、一般的な脆弱性対策よりも少し厄介です。しかし、認証はすべてのアプリケーション、プログラム、およびAPIにとって非常に重要であるため、正しい方法で認証を行うために時間をかける価値があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
認証は、多くの場合、アプリケーションへのゲートウェイとしてだけでなく、ネットワークの他の部分へのゲートウェイとしても機能するため、攻撃者にとって魅力的な標的です。認証プロセスが壊れていたり脆弱だったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れている時には、上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が Base64 を使ってそのクッキーを解読すると、そのクッキーがアプリケーショ ンのセッションとユーザをどのように定義しているかを知ることができます。例えば、デコードすると次のようなJSONが表示されるかもしれません。
{
"username" : "ShadyGuy",
"role" : "user"
{
その時点で、悪意のあるユーザーは、自分のユーザー名、役割、またはその両方を変更することができます。いくつかの値を変更することで、より高い権限レベルを持つ別のユーザーになることができます。
{
"username" : "GoodGuy",
"role" : "admin"
{
その時点で、攻撃者がその情報を再コード化し、それをクッキーの値として設定すると、実質的に、より高い権限レベルを持つ新しいユーザになります。このような変更を防ぐ方法がない限り、アプリケーションがその変更を受け入れる可能性が高いです。
認証の失敗や設定ミスをなくす
認証に失敗すると、全体的なセキュリティが損なわれる可能性が高くなります。しかし、アプリケーションをコーディングする際にいくつかの重要なガイドラインに従うことで、すべてを安全に保つことができます。
まず第一に、ユーザーがプログラムの機能にアクセスできるようにするための認証チェックをどこにでも必ず入れること。もし、認証チェックが全く存在しないのであれば、最初から勝負はついていません。
ベストプラクティスの観点からは、ユーザーがアクセスできるURLでセッションIDを公開しないようにすることが一つの良い点です。上記の2番目の例では、認証の失敗について、攻撃者がセッション・クッキーを解読しようとするのを防ぐには、セッション・クッキーが攻撃者の目に触れない方がずっと簡単です。
また、多要素認証を導入するのも良いアイデアです。これには、タイトなスケジュールでパスワードをアルゴリズムで生成するハードウェア・トークンを使用すると安全です。このようなデバイスをユーザーに提供できない場合は、SMSのテキストメッセージでも対応可能です。ただし、ユーザーからのリクエストは、30秒間に3〜4回という適度な回数に制限し、コードは数分で一斉に失効するようにする必要があります。英数字のコードを使用することで、潜在的なパスワードに文字や数字を追加してセキュリティを向上させることもできます。
最後に、可能であれば、ユーザー名や予測可能な連番の値をセッションIDとして使用することは避けてください。代わりに、毎回ランダムなセッションIDを生成する、安全なサーバーサイドセッションマネージャを使用してください。
安全な認証方法を実装することは、一般的な脆弱性対策よりも少し厄介です。しかし、認証はすべてのアプリケーション、プログラム、およびAPIにとって非常に重要であるため、正しい方法で認証を行うために時間をかける価値があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が Base64 を使ってそのクッキーを解読すると、そのクッキーがアプリケーショ ンのセッションとユーザをどのように定義しているかを知ることができます。例えば、デコードすると次のようなJSONが表示されるかもしれません。
{
"username" : "ShadyGuy",
"role" : "user"
{
その時点で、悪意のあるユーザーは、自分のユーザー名、役割、またはその両方を変更することができます。いくつかの値を変更することで、より高い権限レベルを持つ別のユーザーになることができます。
{
"username" : "GoodGuy",
"role" : "admin"
{
その時点で、攻撃者がその情報を再コード化し、それをクッキーの値として設定すると、実質的に、より高い権限レベルを持つ新しいユーザになります。このような変更を防ぐ方法がない限り、アプリケーションがその変更を受け入れる可能性が高いです。
認証の失敗や設定ミスをなくす
認証に失敗すると、全体的なセキュリティが損なわれる可能性が高くなります。しかし、アプリケーションをコーディングする際にいくつかの重要なガイドラインに従うことで、すべてを安全に保つことができます。
まず第一に、ユーザーがプログラムの機能にアクセスできるようにするための認証チェックをどこにでも必ず入れること。もし、認証チェックが全く存在しないのであれば、最初から勝負はついていません。
ベストプラクティスの観点からは、ユーザーがアクセスできるURLでセッションIDを公開しないようにすることが一つの良い点です。上記の2番目の例では、認証の失敗について、攻撃者がセッション・クッキーを解読しようとするのを防ぐには、セッション・クッキーが攻撃者の目に触れない方がずっと簡単です。
また、多要素認証を導入するのも良いアイデアです。これには、タイトなスケジュールでパスワードをアルゴリズムで生成するハードウェア・トークンを使用すると安全です。このようなデバイスをユーザーに提供できない場合は、SMSのテキストメッセージでも対応可能です。ただし、ユーザーからのリクエストは、30秒間に3〜4回という適度な回数に制限し、コードは数分で一斉に失効するようにする必要があります。英数字のコードを使用することで、潜在的なパスワードに文字や数字を追加してセキュリティを向上させることもできます。
最後に、可能であれば、ユーザー名や予測可能な連番の値をセッションIDとして使用することは避けてください。代わりに、毎回ランダムなセッションIDを生成する、安全なサーバーサイドセッションマネージャを使用してください。
安全な認証方法を実装することは、一般的な脆弱性対策よりも少し厄介です。しかし、認証はすべてのアプリケーション、プログラム、およびAPIにとって非常に重要であるため、正しい方法で認証を行うために時間をかける価値があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
レポートを表示デモを予約
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
マティアスは、15年以上のソフトウェアセキュリティの実務経験を持つ研究者および開発者です。フォーティファイ・ソフトウェアや自身の会社であるセンセイ・セキュリティなどの企業向けにソリューションを開発してきました。マティアスはキャリアを通じて、複数のアプリケーションセキュリティ研究プロジェクトを主導し、それが商用製品につながり、10件以上の特許を取得しています。デスクから離れている時には、上級アプリケーション・セキュリティ・トレーニング・コースの講師を務め、RSA Conference、Black Hat、DefCon、BSIMM、OWASP AppSec、BruConなどのグローバルカンファレンスで定期的に講演を行っています。
マティアスはゲント大学でコンピューター工学の博士号を取得し、そこでアプリケーションの内部動作を隠すためのプログラムの難読化によるアプリケーションセキュリティを学びました。
認証機構は、正しく実装するのが難しいことで知られています。なぜなら、その性質上、ほとんどの認証課題はユーザに公開されなければならないため、攻撃者は認証課題を研究し、悪用できるパターンや脆弱性を探すチャンスがあるからです。
最後に、認証は多くの場合、アプリケーションや潜在的にネットワークの他の部分へのゲートウェイとして機能するため、攻撃者にとって格好の標的となります。認証プロセスが壊れていたり、脆弱であったりすると、攻撃者がその弱点を発見して悪用する可能性が高くなります。
そこで、この章では、認証の問題で悪者をシャットアウトする方法を学びます。まずは自分のスキルを試してみたいという方は、ゲーム性のあるチャレンジに挑戦してみてください。
あなたのスコアを向上させたいですか？私たちがそれを分解する間、私に付き合ってください。
壊れた認証や誤って設定された認証の例としてはどのようなものがありますか？
問題がそれほど明白ではない例としては、認証方法がクレデンシャルスタッフィング（既知のユーザ名とパスワードのリストを使用してセキュリティを破ること）に対して脆弱な場合があります。多要素認証のような通常は非常に安全な認証方法であっても、リクエストが制限されていなかったり、スロットルが設定されていなかったり、その他の方法で監視されていたりすると、脆弱になる可能性があります。
例えば、攻撃者は、POST リクエストを / に送信し、リクエストボディにユーザー名を指定することで、パスワード回復リクエストを引き起こすことができます。api/system/verification-codesに POST リクエストを送信し、リクエストボディにユーザ名を指定することで、パスワード回復リクエストを引き起こすことができます。6 桁のコードをユーザの携帯電話に送信する SMS テキストメッセージチャレンジを使用しているアプリで、入力フィールドに制限がない場合、そのアプリはわずか数分で侵入することができます。攻撃者は、可能な限りすべての6桁の組み合わせを、正しいものに当たるまでアプリケーションに送信するだけでよいのです。
このシナリオでは、表面的には2ファクタ認証を導入することでアプリケーションの安全性を確保できるように見えます。しかし、ユーザーの入力が制限されていないため、認証が破られ、脆弱になっているのです。
別の例では、アプリケーションがエンコードされたユーザ・オブジェクトを認証クッキーとして使用する場合があります。しかし、低レベルのユーザ・アクセス権を持つ攻撃者が Base64 を使ってそのクッキーを解読すると、そのクッキーがアプリケーショ ンのセッションとユーザをどのように定義しているかを知ることができます。例えば、デコードすると次のようなJSONが表示されるかもしれません。
{
"username" : "ShadyGuy",
"role" : "user"
{
その時点で、悪意のあるユーザーは、自分のユーザー名、役割、またはその両方を変更することができます。いくつかの値を変更することで、より高い権限レベルを持つ別のユーザーになることができます。
{
"username" : "GoodGuy",
"role" : "admin"
{
その時点で、攻撃者がその情報を再コード化し、それをクッキーの値として設定すると、実質的に、より高い権限レベルを持つ新しいユーザになります。このような変更を防ぐ方法がない限り、アプリケーションがその変更を受け入れる可能性が高いです。
認証の失敗や設定ミスをなくす
認証に失敗すると、全体的なセキュリティが損なわれる可能性が高くなります。しかし、アプリケーションをコーディングする際にいくつかの重要なガイドラインに従うことで、すべてを安全に保つことができます。
まず第一に、ユーザーがプログラムの機能にアクセスできるようにするための認証チェックをどこにでも必ず入れること。もし、認証チェックが全く存在しないのであれば、最初から勝負はついていません。
ベストプラクティスの観点からは、ユーザーがアクセスできるURLでセッションIDを公開しないようにすることが一つの良い点です。上記の2番目の例では、認証の失敗について、攻撃者がセッション・クッキーを解読しようとするのを防ぐには、セッション・クッキーが攻撃者の目に触れない方がずっと簡単です。
また、多要素認証を導入するのも良いアイデアです。これには、タイトなスケジュールでパスワードをアルゴリズムで生成するハードウェア・トークンを使用すると安全です。このようなデバイスをユーザーに提供できない場合は、SMSのテキストメッセージでも対応可能です。ただし、ユーザーからのリクエストは、30秒間に3〜4回という適度な回数に制限し、コードは数分で一斉に失効するようにする必要があります。英数字のコードを使用することで、潜在的なパスワードに文字や数字を追加してセキュリティを向上させることもできます。
最後に、可能であれば、ユーザー名や予測可能な連番の値をセッションIDとして使用することは避けてください。代わりに、毎回ランダムなセッションIDを生成する、安全なサーバーサイドセッションマネージャを使用してください。
安全な認証方法を実装することは、一般的な脆弱性対策よりも少し厄介です。しかし、認証はすべてのアプリケーション、プログラム、およびAPIにとって非常に重要であるため、正しい方法で認証を行うために時間をかける価値があります。
をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。
目次
マティアス・マドゥ博士は、セキュリティ専門家、研究者、CTO、セキュア・コード・ウォリアーの共同創設者です。マティアスはゲント大学で静的解析ソリューションを中心としたアプリケーションセキュリティの博士号を取得しました。その後、米国のFortifyに入社し、開発者が安全なコードを書くのを手助けせずに、コードの問題を検出するだけでは不十分であることに気づきました。これがきっかけで、開発者を支援し、セキュリティの負担を軽減し、顧客の期待を超える製品を開発するようになりました。Team Awesomeの一員としてデスクにいない時は、RSAカンファレンス、BlackHat、DefConなどのカンファレンスでプレゼンテーションを行うステージでのプレゼンテーションを楽しんでいます。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする文化を築くお手伝いをします。アプリケーションセキュリティマネージャー、開発者、CISO、またはセキュリティ関係者であるかに関わらず、安全でないコードに関連するリスクを軽減するお手伝いをします。
デモを予約[ダウンロード]始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
