Coders Conquer Security:シェア＆ラーンシリーズ - OSコマンドインジェクション
OS コマンドインジェクション攻撃は、アプリケーションがユーザーにシェルへの入力を許可しているにもかかわらず、入力文字列が有効であるかどうかを確認するアクションを取らない場合に発生します。これにより、攻撃者は、アプリケーションをホストしている OS に直接コマンドを投下することができ、その際、侵害されたアプリケーションに設定されているあらゆる許可レベルを使用することができます。
OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。このエピソードでは、次のことを学びます。
仕組み
なぜ彼らは危険なのか
それを阻止するためには、どのような防御策を講じるべきか。
OSコマンドインジェクションはどのように利用されるのか？
OSコマンドインジェクション攻撃を行うために、攻撃者が最初にしなければならないことは、アプリケーション内のユーザー入力を見つけることです。ユーザーが入力するフォームは、良い出発点となる可能性があります。最も巧妙な攻撃者は、ほとんどすべてのアプリケーションやWebサイトで使用されている、クッキーやHTTPヘッダーなども攻撃の起点として使用します。
次に必要なのは、アプリケーションをホストしているOSを把握することです。選択肢が限られているので、この段階では試行錯誤が有効です。ほとんどのアプリケーションサーバは、Windowsベース（Windowsのフレーバーは通常問題ではありません）、何らかのLinuxボックス、またはUnixである可能性があります。
この時、ハッカーは入力を修正して、一見無害に見える入力にOSのコマンドを注入します。これにより、ホスティングOSを騙し、アプリケーションが持つあらゆる許可レベルで意図しないコマンドを実行させることができます。
例えば、次のコマンドは、アプリケーション内の有効なユーザーがファイルの内容を見るために使用することができます（この場合は、月例理事会のメモ）。
exec("cat " + filename")
この例では、次のコマンドを実行して、ユーザーに会議のメモを返します。
$ ./cat MeetingNotes.txt
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
これは、Linuxでディレクトリの内容を一覧表示するときに使われるような、入力の最後に攻撃者が追加のコマンドを追加したときに起こる現象です。このケースでは、会議のメモを表示するという元のコマンドはそのまま実行されます。しかし、悪意のあるユーザーには、ディレクトリ内の他のすべての内容が表示され、OSのコマンドインジェクション攻撃のフォローアップに使用できる他のコマンドも表示されます。彼らは入力します。
$ ./cat MeetingNotes.txt && ls
そして、代わりにこれを手に入れる。
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
このケースでは、ハッカーはディレクトリの内容を見せられただけでなく、ホストOS上で実行できることがわかっている他のコマンドのメニューを渡されました。
OSコマンドインジェクション攻撃はなぜ危険なのか？
ユーザーが対象となるアプリケーションの目的を回避して、オペレーティングシステムのコマンドを実行するために使用できるようにすることは、非常に危険です。攻撃者は、例えば、機密データを盗んだり、サーバーのドライブ全体をフォーマットするなど、壊滅的な行為を簡単に行うことができます。攻撃者が利用できる選択肢は、オペレーティングシステムで許可されているコマンドと、それを使用する際の創造性によってのみ制限されます。
OSのコマンドは、アプリケーションと同じ権限レベルで実行されます。管理者権限で実行されるアプリケーションは、それを侵害したハッカーがOSのあらゆるコマンドを実行できることを意味します。
OS コマンドインジェクションの攻撃パターンはよく知られており、文書化されています。脆弱なアプリケーションは、プロのハッカーと同様に、スクリプトキディの影響を受けやすくなります。ほとんどスキルのない攻撃者は、OS のコマンドをアプリケーションにカット＆ペーストして、何が起こるかを試すことができます。
OSコマンドインジェクションに対するセキュリティOKの取得
OSのコマンドインジェクションを阻止するための優れた技術がいくつかあります。まず、アプリケーションを、その機能を果たすために必要な最小限の権限で実行することです。これによって攻撃を防ぐことはできませんが、万が一侵害が発生した場合には被害を最小限に抑えることができます。
ほとんどのプログラミング言語やフレームワークは、ディレクトリの内容の一覧表示や、ハードディスク上のファイルの作成や読み取りなど、OSの一般的なメソッドのAPIコールを提供しています。OSコマンドインジェクションを環境から排除する完璧な方法は、すべてのアプリケーションがOSコマンドを直接使用する代わりに、これらのAPIコールを使用することです。
これが不可能な場合は、ユーザーの入力を検証してからOSのコマンドで使用する。ホワイトリストを使用すると、信頼できる小さな値のセットのみを使用することができます。技術的にはブラックリストを使っても可能ですが、許可されるコマンドの数が圧倒的に少ないので、ホワイトリストの方が簡単な場合がほとんどです。ホワイトリストには、有効なPOSTとGETのパラメータを含めることを忘れないでください。また、クッキーのような見落とされがちなユーザー入力ベクターも含めてください。
最後に、利用可能なプログラミングAPIがなく、ホワイトリストを使用できない場合は、サニタイズライブラリを使用して、ユーザーの入力に含まれる特殊文字をOSのコマンドで使用する前にエスケープします。
OSコマンドインジェクション攻撃の詳細情報
さらに詳しく知りたい方は、OSコマンドインジェクション攻撃に関するOWASPの記事をご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
OS コマンドインジェクション攻撃は、アプリケーションがユーザーにシェルへの入力を許可しているにもかかわらず、入力文字列が有効であるかどうかを確認するアクションを取らない場合に発生します。これにより、攻撃者は、アプリケーションをホストしている OS に直接コマンドを投下することができ、その際、侵害されたアプリケーションに設定されているあらゆる許可レベルを使用することができます。
OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。このエピソードでは、次のことを学びます。
仕組み
なぜ彼らは危険なのか
それを阻止するためには、どのような防御策を講じるべきか。
OSコマンドインジェクションはどのように利用されるのか？
OSコマンドインジェクション攻撃を行うために、攻撃者が最初にしなければならないことは、アプリケーション内のユーザー入力を見つけることです。ユーザーが入力するフォームは、良い出発点となる可能性があります。最も巧妙な攻撃者は、ほとんどすべてのアプリケーションやWebサイトで使用されている、クッキーやHTTPヘッダーなども攻撃の起点として使用します。
次に必要なのは、アプリケーションをホストしているOSを把握することです。選択肢が限られているので、この段階では試行錯誤が有効です。ほとんどのアプリケーションサーバは、Windowsベース（Windowsのフレーバーは通常問題ではありません）、何らかのLinuxボックス、またはUnixである可能性があります。
この時、ハッカーは入力を修正して、一見無害に見える入力にOSのコマンドを注入します。これにより、ホスティングOSを騙し、アプリケーションが持つあらゆる許可レベルで意図しないコマンドを実行させることができます。
例えば、次のコマンドは、アプリケーション内の有効なユーザーがファイルの内容を見るために使用することができます（この場合は、月例理事会のメモ）。
exec("cat " + filename")
この例では、次のコマンドを実行して、ユーザーに会議のメモを返します。
$ ./cat MeetingNotes.txt
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
これは、Linuxでディレクトリの内容を一覧表示するときに使われるような、入力の最後に攻撃者が追加のコマンドを追加したときに起こる現象です。このケースでは、会議のメモを表示するという元のコマンドはそのまま実行されます。しかし、悪意のあるユーザーには、ディレクトリ内の他のすべての内容が表示され、OSのコマンドインジェクション攻撃のフォローアップに使用できる他のコマンドも表示されます。彼らは入力します。
$ ./cat MeetingNotes.txt && ls
そして、代わりにこれを手に入れる。
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
このケースでは、ハッカーはディレクトリの内容を見せられただけでなく、ホストOS上で実行できることがわかっている他のコマンドのメニューを渡されました。
OSコマンドインジェクション攻撃はなぜ危険なのか？
ユーザーが対象となるアプリケーションの目的を回避して、オペレーティングシステムのコマンドを実行するために使用できるようにすることは、非常に危険です。攻撃者は、例えば、機密データを盗んだり、サーバーのドライブ全体をフォーマットするなど、壊滅的な行為を簡単に行うことができます。攻撃者が利用できる選択肢は、オペレーティングシステムで許可されているコマンドと、それを使用する際の創造性によってのみ制限されます。
OSのコマンドは、アプリケーションと同じ権限レベルで実行されます。管理者権限で実行されるアプリケーションは、それを侵害したハッカーがOSのあらゆるコマンドを実行できることを意味します。
OS コマンドインジェクションの攻撃パターンはよく知られており、文書化されています。脆弱なアプリケーションは、プロのハッカーと同様に、スクリプトキディの影響を受けやすくなります。ほとんどスキルのない攻撃者は、OS のコマンドをアプリケーションにカット＆ペーストして、何が起こるかを試すことができます。
OSコマンドインジェクションに対するセキュリティOKの取得
OSのコマンドインジェクションを阻止するための優れた技術がいくつかあります。まず、アプリケーションを、その機能を果たすために必要な最小限の権限で実行することです。これによって攻撃を防ぐことはできませんが、万が一侵害が発生した場合には被害を最小限に抑えることができます。
ほとんどのプログラミング言語やフレームワークは、ディレクトリの内容の一覧表示や、ハードディスク上のファイルの作成や読み取りなど、OSの一般的なメソッドのAPIコールを提供しています。OSコマンドインジェクションを環境から排除する完璧な方法は、すべてのアプリケーションがOSコマンドを直接使用する代わりに、これらのAPIコールを使用することです。
これが不可能な場合は、ユーザーの入力を検証してからOSのコマンドで使用する。ホワイトリストを使用すると、信頼できる小さな値のセットのみを使用することができます。技術的にはブラックリストを使っても可能ですが、許可されるコマンドの数が圧倒的に少ないので、ホワイトリストの方が簡単な場合がほとんどです。ホワイトリストには、有効なPOSTとGETのパラメータを含めることを忘れないでください。また、クッキーのような見落とされがちなユーザー入力ベクターも含めてください。
最後に、利用可能なプログラミングAPIがなく、ホワイトリストを使用できない場合は、サニタイズライブラリを使用して、ユーザーの入力に含まれる特殊文字をOSのコマンドで使用する前にエスケープします。
OSコマンドインジェクション攻撃の詳細情報
さらに詳しく知りたい方は、OSコマンドインジェクション攻撃に関するOWASPの記事をご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
OS コマンドインジェクション攻撃は、アプリケーションがユーザーにシェルへの入力を許可しているにもかかわらず、入力文字列が有効であるかどうかを確認するアクションを取らない場合に発生します。これにより、攻撃者は、アプリケーションをホストしている OS に直接コマンドを投下することができ、その際、侵害されたアプリケーションに設定されているあらゆる許可レベルを使用することができます。
OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。このエピソードでは、次のことを学びます。
仕組み
なぜ彼らは危険なのか
それを阻止するためには、どのような防御策を講じるべきか。
OSコマンドインジェクションはどのように利用されるのか？
OSコマンドインジェクション攻撃を行うために、攻撃者が最初にしなければならないことは、アプリケーション内のユーザー入力を見つけることです。ユーザーが入力するフォームは、良い出発点となる可能性があります。最も巧妙な攻撃者は、ほとんどすべてのアプリケーションやWebサイトで使用されている、クッキーやHTTPヘッダーなども攻撃の起点として使用します。
次に必要なのは、アプリケーションをホストしているOSを把握することです。選択肢が限られているので、この段階では試行錯誤が有効です。ほとんどのアプリケーションサーバは、Windowsベース（Windowsのフレーバーは通常問題ではありません）、何らかのLinuxボックス、またはUnixである可能性があります。
この時、ハッカーは入力を修正して、一見無害に見える入力にOSのコマンドを注入します。これにより、ホスティングOSを騙し、アプリケーションが持つあらゆる許可レベルで意図しないコマンドを実行させることができます。
例えば、次のコマンドは、アプリケーション内の有効なユーザーがファイルの内容を見るために使用することができます（この場合は、月例理事会のメモ）。
exec("cat " + filename")
この例では、次のコマンドを実行して、ユーザーに会議のメモを返します。
$ ./cat MeetingNotes.txt
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
これは、Linuxでディレクトリの内容を一覧表示するときに使われるような、入力の最後に攻撃者が追加のコマンドを追加したときに起こる現象です。このケースでは、会議のメモを表示するという元のコマンドはそのまま実行されます。しかし、悪意のあるユーザーには、ディレクトリ内の他のすべての内容が表示され、OSのコマンドインジェクション攻撃のフォローアップに使用できる他のコマンドも表示されます。彼らは入力します。
$ ./cat MeetingNotes.txt && ls
そして、代わりにこれを手に入れる。
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
このケースでは、ハッカーはディレクトリの内容を見せられただけでなく、ホストOS上で実行できることがわかっている他のコマンドのメニューを渡されました。
OSコマンドインジェクション攻撃はなぜ危険なのか？
ユーザーが対象となるアプリケーションの目的を回避して、オペレーティングシステムのコマンドを実行するために使用できるようにすることは、非常に危険です。攻撃者は、例えば、機密データを盗んだり、サーバーのドライブ全体をフォーマットするなど、壊滅的な行為を簡単に行うことができます。攻撃者が利用できる選択肢は、オペレーティングシステムで許可されているコマンドと、それを使用する際の創造性によってのみ制限されます。
OSのコマンドは、アプリケーションと同じ権限レベルで実行されます。管理者権限で実行されるアプリケーションは、それを侵害したハッカーがOSのあらゆるコマンドを実行できることを意味します。
OS コマンドインジェクションの攻撃パターンはよく知られており、文書化されています。脆弱なアプリケーションは、プロのハッカーと同様に、スクリプトキディの影響を受けやすくなります。ほとんどスキルのない攻撃者は、OS のコマンドをアプリケーションにカット＆ペーストして、何が起こるかを試すことができます。
OSコマンドインジェクションに対するセキュリティOKの取得
OSのコマンドインジェクションを阻止するための優れた技術がいくつかあります。まず、アプリケーションを、その機能を果たすために必要な最小限の権限で実行することです。これによって攻撃を防ぐことはできませんが、万が一侵害が発生した場合には被害を最小限に抑えることができます。
ほとんどのプログラミング言語やフレームワークは、ディレクトリの内容の一覧表示や、ハードディスク上のファイルの作成や読み取りなど、OSの一般的なメソッドのAPIコールを提供しています。OSコマンドインジェクションを環境から排除する完璧な方法は、すべてのアプリケーションがOSコマンドを直接使用する代わりに、これらのAPIコールを使用することです。
これが不可能な場合は、ユーザーの入力を検証してからOSのコマンドで使用する。ホワイトリストを使用すると、信頼できる小さな値のセットのみを使用することができます。技術的にはブラックリストを使っても可能ですが、許可されるコマンドの数が圧倒的に少ないので、ホワイトリストの方が簡単な場合がほとんどです。ホワイトリストには、有効なPOSTとGETのパラメータを含めることを忘れないでください。また、クッキーのような見落とされがちなユーザー入力ベクターも含めてください。
最後に、利用可能なプログラミングAPIがなく、ホワイトリストを使用できない場合は、サニタイズライブラリを使用して、ユーザーの入力に含まれる特殊文字をOSのコマンドで使用する前にエスケープします。
OSコマンドインジェクション攻撃の詳細情報
さらに詳しく知りたい方は、OSコマンドインジェクション攻撃に関するOWASPの記事をご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
OS コマンドインジェクション攻撃は、アプリケーションがユーザーにシェルへの入力を許可しているにもかかわらず、入力文字列が有効であるかどうかを確認するアクションを取らない場合に発生します。これにより、攻撃者は、アプリケーションをホストしている OS に直接コマンドを投下することができ、その際、侵害されたアプリケーションに設定されているあらゆる許可レベルを使用することができます。
OSコマンドインジェクション攻撃は、エントリーレベルのハッカーやスキルの低いハッカーでも行うことができるため、セキュリティチームが経験する最も一般的な弱点の1つとなっています。ありがたいことに、これらの攻撃を防ぐための非常に効果的な方法がいくつかあります。このエピソードでは、次のことを学びます。
仕組み
なぜ彼らは危険なのか
それを阻止するためには、どのような防御策を講じるべきか。
OSコマンドインジェクションはどのように利用されるのか？
OSコマンドインジェクション攻撃を行うために、攻撃者が最初にしなければならないことは、アプリケーション内のユーザー入力を見つけることです。ユーザーが入力するフォームは、良い出発点となる可能性があります。最も巧妙な攻撃者は、ほとんどすべてのアプリケーションやWebサイトで使用されている、クッキーやHTTPヘッダーなども攻撃の起点として使用します。
次に必要なのは、アプリケーションをホストしているOSを把握することです。選択肢が限られているので、この段階では試行錯誤が有効です。ほとんどのアプリケーションサーバは、Windowsベース（Windowsのフレーバーは通常問題ではありません）、何らかのLinuxボックス、またはUnixである可能性があります。
この時、ハッカーは入力を修正して、一見無害に見える入力にOSのコマンドを注入します。これにより、ホスティングOSを騙し、アプリケーションが持つあらゆる許可レベルで意図しないコマンドを実行させることができます。
例えば、次のコマンドは、アプリケーション内の有効なユーザーがファイルの内容を見るために使用することができます（この場合は、月例理事会のメモ）。
exec("cat " + filename")
この例では、次のコマンドを実行して、ユーザーに会議のメモを返します。
$ ./cat MeetingNotes.txt
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
これは、Linuxでディレクトリの内容を一覧表示するときに使われるような、入力の最後に攻撃者が追加のコマンドを追加したときに起こる現象です。このケースでは、会議のメモを表示するという元のコマンドはそのまま実行されます。しかし、悪意のあるユーザーには、ディレクトリ内の他のすべての内容が表示され、OSのコマンドインジェクション攻撃のフォローアップに使用できる他のコマンドも表示されます。彼らは入力します。
$ ./cat MeetingNotes.txt && ls
そして、代わりにこれを手に入れる。
7月のミーティングには、3人の実行委員が出席しました。新予算プロジェクトについて議論されましたが、アクションや投票は行われませんでした。
MeetingNotes.txt
JuneMeetingNotes.txt
MayMeetingNotes.txt
format.c
misnull.c
notefault.c
trunc.c
writewhatwhere.c
このケースでは、ハッカーはディレクトリの内容を見せられただけでなく、ホストOS上で実行できることがわかっている他のコマンドのメニューを渡されました。
OSコマンドインジェクション攻撃はなぜ危険なのか？
ユーザーが対象となるアプリケーションの目的を回避して、オペレーティングシステムのコマンドを実行するために使用できるようにすることは、非常に危険です。攻撃者は、例えば、機密データを盗んだり、サーバーのドライブ全体をフォーマットするなど、壊滅的な行為を簡単に行うことができます。攻撃者が利用できる選択肢は、オペレーティングシステムで許可されているコマンドと、それを使用する際の創造性によってのみ制限されます。
OSのコマンドは、アプリケーションと同じ権限レベルで実行されます。管理者権限で実行されるアプリケーションは、それを侵害したハッカーがOSのあらゆるコマンドを実行できることを意味します。
OS コマンドインジェクションの攻撃パターンはよく知られており、文書化されています。脆弱なアプリケーションは、プロのハッカーと同様に、スクリプトキディの影響を受けやすくなります。ほとんどスキルのない攻撃者は、OS のコマンドをアプリケーションにカット＆ペーストして、何が起こるかを試すことができます。
OSコマンドインジェクションに対するセキュリティOKの取得
OSのコマンドインジェクションを阻止するための優れた技術がいくつかあります。まず、アプリケーションを、その機能を果たすために必要な最小限の権限で実行することです。これによって攻撃を防ぐことはできませんが、万が一侵害が発生した場合には被害を最小限に抑えることができます。
ほとんどのプログラミング言語やフレームワークは、ディレクトリの内容の一覧表示や、ハードディスク上のファイルの作成や読み取りなど、OSの一般的なメソッドのAPIコールを提供しています。OSコマンドインジェクションを環境から排除する完璧な方法は、すべてのアプリケーションがOSコマンドを直接使用する代わりに、これらのAPIコールを使用することです。
これが不可能な場合は、ユーザーの入力を検証してからOSのコマンドで使用する。ホワイトリストを使用すると、信頼できる小さな値のセットのみを使用することができます。技術的にはブラックリストを使っても可能ですが、許可されるコマンドの数が圧倒的に少ないので、ホワイトリストの方が簡単な場合がほとんどです。ホワイトリストには、有効なPOSTとGETのパラメータを含めることを忘れないでください。また、クッキーのような見落とされがちなユーザー入力ベクターも含めてください。
最後に、利用可能なプログラミングAPIがなく、ホワイトリストを使用できない場合は、サニタイズライブラリを使用して、ユーザーの入力に含まれる特殊文字をOSのコマンドで使用する前にエスケープします。
OSコマンドインジェクション攻撃の詳細情報
さらに詳しく知りたい方は、OSコマンドインジェクション攻撃に関するOWASPの記事をご参照ください。また、サイバーセキュリティチームを究極のサイバー戦士に育成するSecure Code Warrior プラットフォームの無料デモで、新たに得た防御知識を試すこともできます。この脆弱性やその他の脅威への対策についての詳細は、Secure Code Warrior ブログをご覧ください。
始めるためのリソース
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.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
