コーダーがセキュリティインフラストラクチャを征服するコードシリーズ:欠けている機能レベルのアクセス制御
次回のInfrastructure as Codeシリーズの記事では、皆さんのような開発者が組織内に安全なインフラストラクチャを導入する際に、まったく新しいレベルのセキュリティ意識へと導きます。
ところで、前回のブログで取り上げたセキュリティ設定ミスの課題にどう対処しましたか？足りない機能レベルのアクセス制御の脆弱性に今すぐ取り組みたいなら、プラットフォームに進んでください。
（上記のリンクからKubernetesチャレンジに移動できますが、プラットフォームにアクセスしたら、ドロップダウンを使用してAnsible、CloudFormation、Terraform、Dockerから選択することもできます。選択はあなた次第です。)
現在導入されているほとんどすべてのアプリケーションには、要求された機能を実行する権限がユーザーに付与されているかどうかを確認する、何らかのアクセス制御メカニズムがあります。これは、アプリケーションを作成するときの機能性だけでなく、優れたセキュリティの基礎でもあります。実際、さまざまな権限を持つユーザーがプログラムを使用できるようにするには、すべての Web アプリケーションにアクセス制御が必要です。
ただし、アクセス制御の同じ検証機能がインフラストラクチャレベルで実行されなかったり、誤って構成されたりすると、問題が発生する可能性があります。インフラストラクチャーレベルのアクセス制御が完璧な順序でなければ、企業全体がハッカーにさらされ、ハッカーはその脆弱性を不正なスヌーピングや全面攻撃の入り口として利用する可能性があります。
実際、機能アクセス制御の脆弱性が見つからない、または誤って構成されている脆弱性を悪用することは非常に簡単です。攻撃者は過度に熟練している必要すらありません。必要なのは、そのアプリケーションをサポートしているフレームワークの中で、どのコマンドが関数を実行するのかを知ることだけです。もしそうなら、それは試行錯誤の問題です。許可されてはいけないリクエストを継続的に送信する可能性があり、成功するとすぐに、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開される可能性があります。
ミッシング・ファンクション・レベル・アクセス・コントロール・エクスプロイトの仕組み
機能レベルのアクセス制御が組織に浸透する方法はいくつかあります。たとえば、機能レベルのアクセスはアプリケーションに任せて、基盤となるインフラストラクチャでは検証されない場合があります。あるいは、インフラストラクチャーレベルのアクセス制御が誤って設定されている可能性もあります。管理者が、権限のないユーザーにはインフラストラクチャーのリソースへのアクセス方法がわからないと考え、上位レベルのユーザーだけが見ることができるはずの「セキュリティ・バイ・セキュリティー (Security by Obscurity)」モデルを使用することがありますが、これはほとんど機能しません。
あいまいさによるセキュリティの例として、次の URL は攻撃を受けやすい可能性があります。
http://companywebsite.com/app/NormalUserHomepage
認証されたユーザーが強制URLブラウズと呼ばれる手法を使用すると、管理者にのみ表示されるページにアクセスしようとする可能性があります。例としては、次のようなものが考えられます。
http://companywebsite.com/app/AdminPages
サーバー側での検証が行われていない場合は、管理ページが表示され (その名前がリクエストと一致する場合)、管理者が新しいページから行う追加機能にアクセスできるようになります。サーバーが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページに付けられた名前がわかるまで試行を続けることができます。
攻撃者の場合、悪用 機能レベルのアクセス制御がない 同様のプロセスです。権限のないページを閲覧しようとする代わりに、関数リクエストを送信します。たとえば、管理者権限を持つ新しいユーザーを作成しようとするかもしれません。そのため、フレームワークによっては次のようなリクエストになります。
投稿/アクション/ユーザー名作成=ハッカー&pw=パスワード&ロール=管理者
機能レベルのアクセス制御が存在しない場合、上記の例は成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者としてログインし直すと、そのネットワークまたはサーバー上の他の管理者と同じアクセス権と権限を持つことになります。
機能レベルのアクセス制御が欠けている場合の修正
機能レベルのアクセス制御に欠けている脆弱性は、攻撃者が簡単に悪用できるため、脆弱性を発見、修正、防止することが重要です。ありがたいことに、ある程度のノウハウと基本的なインフラストラクチャがあれば、これはそれほど難しくありません。 コードセキュリティトレーニング。
主な保護策は、インフラストラクチャレベルでロールベースの認証を実装することです。アプリケーションがその機能を処理することを決して信頼しないでください。たとえそうであっても、インフラストラクチャー側の承認があれば、見落としがないことが保証されます。認証は、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用される一元的な場所 (AWS IAM、Azure IAM など) から行うのが理想的です。これらの承認プロセスは、フレームワーク自体から行うことも、いくつもの使いやすい外部モジュールから行うこともできます。
最後に、組織は最小権限の概念を採用する必要があります。デフォルトではすべてのアクションと機能を拒否し、承認プロセスを使用して有効なユーザーに必要な操作を行う権限を与える必要があります。ユーザーには、必要な機能を実行するのに十分な権限のみを、必要な期間だけ付与する必要があります。
機能レベルのアクセス制御が欠けていると、壊滅的な打撃を受ける可能性があります。しかしありがたいことに、優れたインフラストラクチャレベルの認証方法を組織に組み込むことで、この問題の発生を簡単に防ぐことができます。
アクセス制御のバグを実際に発見する準備はできていると思いますか？次の Docker コードスニペットを比較してください。1 つは脆弱で、もう 1 つは安全です。
傷つきやすい:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザールート
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
安全:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザーなし
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
詳細を学び、自分自身に挑戦してください
をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥や脆弱性による被害から組織や顧客を保護する方法について、さらに詳しく知るためのブログページをご覧ください。
また、以前に見逃した場合でも、 IaC ゲーミフィケーションセキュリティチャレンジを試してみる Secure Code Warriorプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。
次章をお楽しみに！
インフラストラクチャレベルのアクセス制御が完璧な順序でなければ、企業全体が攻撃者に危険にさらされ、攻撃者はこの脆弱性を不正なスヌーピングや全面攻撃のゲートウェイとして利用する可能性があります。
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und mehr als 10 Patente angemeldet.Wenn er nicht an seinem Schreibtisch sitzt, unterrichtet Matias Fortgeschrittenenkurse zum Thema Anwendungssicherheit und hält regelmäßig Vorträge auf globalen Konferenzen wie der RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matthias promovierte an der Universität Gent in Informatik und lernte dort Anwendungssicherheit durch Programmverschleierung, um die interne Funktionsweise von Anwendungen zu verbergen.
次回のInfrastructure as Codeシリーズの記事では、皆さんのような開発者が組織内に安全なインフラストラクチャを導入する際に、まったく新しいレベルのセキュリティ意識へと導きます。
ところで、前回のブログで取り上げたセキュリティ設定ミスの課題にどう対処しましたか？足りない機能レベルのアクセス制御の脆弱性に今すぐ取り組みたいなら、プラットフォームに進んでください。
（上記のリンクからKubernetesチャレンジに移動できますが、プラットフォームにアクセスしたら、ドロップダウンを使用してAnsible、CloudFormation、Terraform、Dockerから選択することもできます。選択はあなた次第です。)
現在導入されているほとんどすべてのアプリケーションには、要求された機能を実行する権限がユーザーに付与されているかどうかを確認する、何らかのアクセス制御メカニズムがあります。これは、アプリケーションを作成するときの機能性だけでなく、優れたセキュリティの基礎でもあります。実際、さまざまな権限を持つユーザーがプログラムを使用できるようにするには、すべての Web アプリケーションにアクセス制御が必要です。
ただし、アクセス制御の同じ検証機能がインフラストラクチャレベルで実行されなかったり、誤って構成されたりすると、問題が発生する可能性があります。インフラストラクチャーレベルのアクセス制御が完璧な順序でなければ、企業全体がハッカーにさらされ、ハッカーはその脆弱性を不正なスヌーピングや全面攻撃の入り口として利用する可能性があります。
実際、機能アクセス制御の脆弱性が見つからない、または誤って構成されている脆弱性を悪用することは非常に簡単です。攻撃者は過度に熟練している必要すらありません。必要なのは、そのアプリケーションをサポートしているフレームワークの中で、どのコマンドが関数を実行するのかを知ることだけです。もしそうなら、それは試行錯誤の問題です。許可されてはいけないリクエストを継続的に送信する可能性があり、成功するとすぐに、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開される可能性があります。
ミッシング・ファンクション・レベル・アクセス・コントロール・エクスプロイトの仕組み
機能レベルのアクセス制御が組織に浸透する方法はいくつかあります。たとえば、機能レベルのアクセスはアプリケーションに任せて、基盤となるインフラストラクチャでは検証されない場合があります。あるいは、インフラストラクチャーレベルのアクセス制御が誤って設定されている可能性もあります。管理者が、権限のないユーザーにはインフラストラクチャーのリソースへのアクセス方法がわからないと考え、上位レベルのユーザーだけが見ることができるはずの「セキュリティ・バイ・セキュリティー (Security by Obscurity)」モデルを使用することがありますが、これはほとんど機能しません。
あいまいさによるセキュリティの例として、次の URL は攻撃を受けやすい可能性があります。
http://companywebsite.com/app/NormalUserHomepage
認証されたユーザーが強制URLブラウズと呼ばれる手法を使用すると、管理者にのみ表示されるページにアクセスしようとする可能性があります。例としては、次のようなものが考えられます。
http://companywebsite.com/app/AdminPages
サーバー側での検証が行われていない場合は、管理ページが表示され (その名前がリクエストと一致する場合)、管理者が新しいページから行う追加機能にアクセスできるようになります。サーバーが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページに付けられた名前がわかるまで試行を続けることができます。
攻撃者の場合、悪用 機能レベルのアクセス制御がない 同様のプロセスです。権限のないページを閲覧しようとする代わりに、関数リクエストを送信します。たとえば、管理者権限を持つ新しいユーザーを作成しようとするかもしれません。そのため、フレームワークによっては次のようなリクエストになります。
投稿/アクション/ユーザー名作成=ハッカー&pw=パスワード&ロール=管理者
機能レベルのアクセス制御が存在しない場合、上記の例は成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者としてログインし直すと、そのネットワークまたはサーバー上の他の管理者と同じアクセス権と権限を持つことになります。
機能レベルのアクセス制御が欠けている場合の修正
機能レベルのアクセス制御に欠けている脆弱性は、攻撃者が簡単に悪用できるため、脆弱性を発見、修正、防止することが重要です。ありがたいことに、ある程度のノウハウと基本的なインフラストラクチャがあれば、これはそれほど難しくありません。 コードセキュリティトレーニング。
主な保護策は、インフラストラクチャレベルでロールベースの認証を実装することです。アプリケーションがその機能を処理することを決して信頼しないでください。たとえそうであっても、インフラストラクチャー側の承認があれば、見落としがないことが保証されます。認証は、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用される一元的な場所 (AWS IAM、Azure IAM など) から行うのが理想的です。これらの承認プロセスは、フレームワーク自体から行うことも、いくつもの使いやすい外部モジュールから行うこともできます。
最後に、組織は最小権限の概念を採用する必要があります。デフォルトではすべてのアクションと機能を拒否し、承認プロセスを使用して有効なユーザーに必要な操作を行う権限を与える必要があります。ユーザーには、必要な機能を実行するのに十分な権限のみを、必要な期間だけ付与する必要があります。
機能レベルのアクセス制御が欠けていると、壊滅的な打撃を受ける可能性があります。しかしありがたいことに、優れたインフラストラクチャレベルの認証方法を組織に組み込むことで、この問題の発生を簡単に防ぐことができます。
アクセス制御のバグを実際に発見する準備はできていると思いますか？次の Docker コードスニペットを比較してください。1 つは脆弱で、もう 1 つは安全です。
傷つきやすい:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザールート
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
安全:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザーなし
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
詳細を学び、自分自身に挑戦してください
をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥や脆弱性による被害から組織や顧客を保護する方法について、さらに詳しく知るためのブログページをご覧ください。
また、以前に見逃した場合でも、 IaC ゲーミフィケーションセキュリティチャレンジを試してみる Secure Code Warriorプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。
次章をお楽しみに！
次回のInfrastructure as Codeシリーズの記事では、皆さんのような開発者が組織内に安全なインフラストラクチャを導入する際に、まったく新しいレベルのセキュリティ意識へと導きます。
ところで、前回のブログで取り上げたセキュリティ設定ミスの課題にどう対処しましたか？足りない機能レベルのアクセス制御の脆弱性に今すぐ取り組みたいなら、プラットフォームに進んでください。
（上記のリンクからKubernetesチャレンジに移動できますが、プラットフォームにアクセスしたら、ドロップダウンを使用してAnsible、CloudFormation、Terraform、Dockerから選択することもできます。選択はあなた次第です。)
現在導入されているほとんどすべてのアプリケーションには、要求された機能を実行する権限がユーザーに付与されているかどうかを確認する、何らかのアクセス制御メカニズムがあります。これは、アプリケーションを作成するときの機能性だけでなく、優れたセキュリティの基礎でもあります。実際、さまざまな権限を持つユーザーがプログラムを使用できるようにするには、すべての Web アプリケーションにアクセス制御が必要です。
ただし、アクセス制御の同じ検証機能がインフラストラクチャレベルで実行されなかったり、誤って構成されたりすると、問題が発生する可能性があります。インフラストラクチャーレベルのアクセス制御が完璧な順序でなければ、企業全体がハッカーにさらされ、ハッカーはその脆弱性を不正なスヌーピングや全面攻撃の入り口として利用する可能性があります。
実際、機能アクセス制御の脆弱性が見つからない、または誤って構成されている脆弱性を悪用することは非常に簡単です。攻撃者は過度に熟練している必要すらありません。必要なのは、そのアプリケーションをサポートしているフレームワークの中で、どのコマンドが関数を実行するのかを知ることだけです。もしそうなら、それは試行錯誤の問題です。許可されてはいけないリクエストを継続的に送信する可能性があり、成功するとすぐに、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開される可能性があります。
ミッシング・ファンクション・レベル・アクセス・コントロール・エクスプロイトの仕組み
機能レベルのアクセス制御が組織に浸透する方法はいくつかあります。たとえば、機能レベルのアクセスはアプリケーションに任せて、基盤となるインフラストラクチャでは検証されない場合があります。あるいは、インフラストラクチャーレベルのアクセス制御が誤って設定されている可能性もあります。管理者が、権限のないユーザーにはインフラストラクチャーのリソースへのアクセス方法がわからないと考え、上位レベルのユーザーだけが見ることができるはずの「セキュリティ・バイ・セキュリティー (Security by Obscurity)」モデルを使用することがありますが、これはほとんど機能しません。
あいまいさによるセキュリティの例として、次の URL は攻撃を受けやすい可能性があります。
http://companywebsite.com/app/NormalUserHomepage
認証されたユーザーが強制URLブラウズと呼ばれる手法を使用すると、管理者にのみ表示されるページにアクセスしようとする可能性があります。例としては、次のようなものが考えられます。
http://companywebsite.com/app/AdminPages
サーバー側での検証が行われていない場合は、管理ページが表示され (その名前がリクエストと一致する場合)、管理者が新しいページから行う追加機能にアクセスできるようになります。サーバーが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページに付けられた名前がわかるまで試行を続けることができます。
攻撃者の場合、悪用 機能レベルのアクセス制御がない 同様のプロセスです。権限のないページを閲覧しようとする代わりに、関数リクエストを送信します。たとえば、管理者権限を持つ新しいユーザーを作成しようとするかもしれません。そのため、フレームワークによっては次のようなリクエストになります。
投稿/アクション/ユーザー名作成=ハッカー&pw=パスワード&ロール=管理者
機能レベルのアクセス制御が存在しない場合、上記の例は成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者としてログインし直すと、そのネットワークまたはサーバー上の他の管理者と同じアクセス権と権限を持つことになります。
機能レベルのアクセス制御が欠けている場合の修正
機能レベルのアクセス制御に欠けている脆弱性は、攻撃者が簡単に悪用できるため、脆弱性を発見、修正、防止することが重要です。ありがたいことに、ある程度のノウハウと基本的なインフラストラクチャがあれば、これはそれほど難しくありません。 コードセキュリティトレーニング。
主な保護策は、インフラストラクチャレベルでロールベースの認証を実装することです。アプリケーションがその機能を処理することを決して信頼しないでください。たとえそうであっても、インフラストラクチャー側の承認があれば、見落としがないことが保証されます。認証は、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用される一元的な場所 (AWS IAM、Azure IAM など) から行うのが理想的です。これらの承認プロセスは、フレームワーク自体から行うことも、いくつもの使いやすい外部モジュールから行うこともできます。
最後に、組織は最小権限の概念を採用する必要があります。デフォルトではすべてのアクションと機能を拒否し、承認プロセスを使用して有効なユーザーに必要な操作を行う権限を与える必要があります。ユーザーには、必要な機能を実行するのに十分な権限のみを、必要な期間だけ付与する必要があります。
機能レベルのアクセス制御が欠けていると、壊滅的な打撃を受ける可能性があります。しかしありがたいことに、優れたインフラストラクチャレベルの認証方法を組織に組み込むことで、この問題の発生を簡単に防ぐことができます。
アクセス制御のバグを実際に発見する準備はできていると思いますか？次の Docker コードスニペットを比較してください。1 つは脆弱で、もう 1 つは安全です。
傷つきやすい:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザールート
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
安全:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザーなし
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
詳細を学び、自分自身に挑戦してください
をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥や脆弱性による被害から組織や顧客を保護する方法について、さらに詳しく知るためのブログページをご覧ください。
また、以前に見逃した場合でも、 IaC ゲーミフィケーションセキュリティチャレンジを試してみる Secure Code Warriorプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。
次章をお楽しみに！
Klicken Sie auf den folgenden Link, um die PDF-Datei dieser Ressource herunterzuladen.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenデモを予約
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und mehr als 10 Patente angemeldet.Wenn er nicht an seinem Schreibtisch sitzt, unterrichtet Matias Fortgeschrittenenkurse zum Thema Anwendungssicherheit und hält regelmäßig Vorträge auf globalen Konferenzen wie der RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matthias promovierte an der Universität Gent in Informatik und lernte dort Anwendungssicherheit durch Programmverschleierung, um die interne Funktionsweise von Anwendungen zu verbergen.
次回のInfrastructure as Codeシリーズの記事では、皆さんのような開発者が組織内に安全なインフラストラクチャを導入する際に、まったく新しいレベルのセキュリティ意識へと導きます。
ところで、前回のブログで取り上げたセキュリティ設定ミスの課題にどう対処しましたか？足りない機能レベルのアクセス制御の脆弱性に今すぐ取り組みたいなら、プラットフォームに進んでください。
（上記のリンクからKubernetesチャレンジに移動できますが、プラットフォームにアクセスしたら、ドロップダウンを使用してAnsible、CloudFormation、Terraform、Dockerから選択することもできます。選択はあなた次第です。)
現在導入されているほとんどすべてのアプリケーションには、要求された機能を実行する権限がユーザーに付与されているかどうかを確認する、何らかのアクセス制御メカニズムがあります。これは、アプリケーションを作成するときの機能性だけでなく、優れたセキュリティの基礎でもあります。実際、さまざまな権限を持つユーザーがプログラムを使用できるようにするには、すべての Web アプリケーションにアクセス制御が必要です。
ただし、アクセス制御の同じ検証機能がインフラストラクチャレベルで実行されなかったり、誤って構成されたりすると、問題が発生する可能性があります。インフラストラクチャーレベルのアクセス制御が完璧な順序でなければ、企業全体がハッカーにさらされ、ハッカーはその脆弱性を不正なスヌーピングや全面攻撃の入り口として利用する可能性があります。
実際、機能アクセス制御の脆弱性が見つからない、または誤って構成されている脆弱性を悪用することは非常に簡単です。攻撃者は過度に熟練している必要すらありません。必要なのは、そのアプリケーションをサポートしているフレームワークの中で、どのコマンドが関数を実行するのかを知ることだけです。もしそうなら、それは試行錯誤の問題です。許可されてはいけないリクエストを継続的に送信する可能性があり、成功するとすぐに、対象となるWebサイト、アプリケーション、サーバー、さらにはネットワーク全体が公開される可能性があります。
ミッシング・ファンクション・レベル・アクセス・コントロール・エクスプロイトの仕組み
機能レベルのアクセス制御が組織に浸透する方法はいくつかあります。たとえば、機能レベルのアクセスはアプリケーションに任せて、基盤となるインフラストラクチャでは検証されない場合があります。あるいは、インフラストラクチャーレベルのアクセス制御が誤って設定されている可能性もあります。管理者が、権限のないユーザーにはインフラストラクチャーのリソースへのアクセス方法がわからないと考え、上位レベルのユーザーだけが見ることができるはずの「セキュリティ・バイ・セキュリティー (Security by Obscurity)」モデルを使用することがありますが、これはほとんど機能しません。
あいまいさによるセキュリティの例として、次の URL は攻撃を受けやすい可能性があります。
http://companywebsite.com/app/NormalUserHomepage
認証されたユーザーが強制URLブラウズと呼ばれる手法を使用すると、管理者にのみ表示されるページにアクセスしようとする可能性があります。例としては、次のようなものが考えられます。
http://companywebsite.com/app/AdminPages
サーバー側での検証が行われていない場合は、管理ページが表示され (その名前がリクエストと一致する場合)、管理者が新しいページから行う追加機能にアクセスできるようになります。サーバーが攻撃者に「ページが見つかりません」というエラーを返した場合、攻撃者は管理ページに付けられた名前がわかるまで試行を続けることができます。
攻撃者の場合、悪用 機能レベルのアクセス制御がない 同様のプロセスです。権限のないページを閲覧しようとする代わりに、関数リクエストを送信します。たとえば、管理者権限を持つ新しいユーザーを作成しようとするかもしれません。そのため、フレームワークによっては次のようなリクエストになります。
投稿/アクション/ユーザー名作成=ハッカー&pw=パスワード&ロール=管理者
機能レベルのアクセス制御が存在しない場合、上記の例は成功し、新しい管理者アカウントが作成されます。攻撃者が新しい管理者としてログインし直すと、そのネットワークまたはサーバー上の他の管理者と同じアクセス権と権限を持つことになります。
機能レベルのアクセス制御が欠けている場合の修正
機能レベルのアクセス制御に欠けている脆弱性は、攻撃者が簡単に悪用できるため、脆弱性を発見、修正、防止することが重要です。ありがたいことに、ある程度のノウハウと基本的なインフラストラクチャがあれば、これはそれほど難しくありません。 コードセキュリティトレーニング。
主な保護策は、インフラストラクチャレベルでロールベースの認証を実装することです。アプリケーションがその機能を処理することを決して信頼しないでください。たとえそうであっても、インフラストラクチャー側の承認があれば、見落としがないことが保証されます。認証は、組織のルーチンに組み込まれ、すべての新しいアプリケーションに適用される一元的な場所 (AWS IAM、Azure IAM など) から行うのが理想的です。これらの承認プロセスは、フレームワーク自体から行うことも、いくつもの使いやすい外部モジュールから行うこともできます。
最後に、組織は最小権限の概念を採用する必要があります。デフォルトではすべてのアクションと機能を拒否し、承認プロセスを使用して有効なユーザーに必要な操作を行う権限を与える必要があります。ユーザーには、必要な機能を実行するのに十分な権限のみを、必要な期間だけ付与する必要があります。
機能レベルのアクセス制御が欠けていると、壊滅的な打撃を受ける可能性があります。しかしありがたいことに、優れたインフラストラクチャレベルの認証方法を組織に組み込むことで、この問題の発生を簡単に防ぐことができます。
アクセス制御のバグを実際に発見する準備はできていると思いますか？次の Docker コードスニペットを比較してください。1 つは脆弱で、もう 1 つは安全です。
傷つきやすい:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザールート
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
安全:
quay.io/prometheus/busybox から:最新
引数バージョン=0.12.1
ARG ファイル名=mysqld_exporter-$ {VERSION} .linux-amd64
ARG URL= https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$version/$filename.tar.gz &\
tar-xvf $ファイル名.tar.gz &&\
mv $ファイル名/MySQLD_Exporter /bin/mysqld_exporter
.my.cnf /home/.my.cnf をコピー
コピー。/scripts/entrypoint.sh ~/entrypoint.sh
ユーザーなし
9104を公開します
エントリポイント [「sh」, "~/entrypoint.sh"]
CMD [「/bin/mysqld_exporter」]
詳細を学び、自分自身に挑戦してください
をチェックしてください セキュア・コード・ウォリアー この脆弱性や、他のセキュリティ上の欠陥や脆弱性による被害から組織や顧客を保護する方法について、さらに詳しく知るためのブログページをご覧ください。
また、以前に見逃した場合でも、 IaC ゲーミフィケーションセキュリティチャレンジを試してみる Secure Code Warriorプラットフォームで、すべてのサイバーセキュリティスキルを磨き、最新の状態に保ちましょう。
次章をお楽しみに！
目次
Dr. Matias Madu ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit mit Schwerpunkt auf statischen Analyselösungen.Anschließend trat er in die Dienste von Fortify in den USA ein und erkannte, dass es nicht ausreicht, nur Code-Probleme zu erkennen, ohne Entwicklern dabei zu helfen, sicheren Code zu schreiben. Dies war der Auslöser dafür, dass er begann, Entwickler zu unterstützen, die Sicherheitslast zu verringern und Produkte zu entwickeln, die die Erwartungen der Kunden übertreffen. Wenn er nicht als Mitglied von Team Awesome an seinem Schreibtisch sitzt, hält er gerne Präsentationen auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior schützt Ihren Code während des gesamten Softwareentwicklungszyklus und hilft Ihnen dabei, eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie Anwendungs-Sicherheitsmanager, Entwickler, CISO oder Sicherheitsbeauftragter sind – wir helfen Ihnen dabei, die mit unsicherem Code verbundenen Risiken zu minimieren.
デモを予約[ダウンロード]Ressourcen für den Einstieg
Themen und Inhalte der Secure-Code-Schulung
Unsere branchenführenden Inhalte werden unter Berücksichtigung der Aufgaben unserer Kunden ständig weiterentwickelt, um mit der sich ständig verändernden Softwareentwicklungsumgebung Schritt zu halten. Sie decken alle Themen von KI bis hin zu XQuery-Injection ab und sind für verschiedene Aufgabenbereiche konzipiert, von Architekten und Ingenieuren bis hin zu Produktmanagern und Qualitätssicherungsfachleuten. Werfen Sie einen Blick auf die Inhalte unseres Content-Katalogs, sortiert nach Themen und Aufgabenbereichen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
「Cybermon 2025 Beat the Boss」 kann nun das ganze Jahr über bei SCW gespielt werden. Führen Sie anspruchsvolle AI/LLM-Sicherheitsherausforderungen ein, um die sichere AI-Entwicklung in großem Maßstab zu stärken.
Erläuterung des Cyber-Resilience-Gesetzes: Bedeutung für die Entwicklung sicherer Software
Erfahren Sie, was das EU-Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams auf Secure-by-Design-Praktiken, Schwachstellenprävention und die Kompetenzentwicklung von Entwicklern vorbereiten können.
Enabler 1: Definierte und messbare Erfolgskriterien
Enabler 1 ist der erste Teil der zehnteiligen Reihe „Enablers of Success“ und zeigt, wie sichere Programmierung mit geschäftlichen Ergebnissen wie Risikominderung und Geschwindigkeit verknüpft werden kann, um Programme langfristig zu optimieren.
