このリストのほとんどの脆弱性は、APIにかなり特化したものですが、セキュリティ機能の無効化／デバッグ機能の有効化／不適切なパーミッションの問題は、どこでも起こりうる問題です。APIではやや多いと思われますが、攻撃者は、パッチが適用されていない欠陥や保護されていないファイルやディレクトリをネットワーク上のどこかで見つけようとすることがよくあります。デバッグが有効になっていたり、セキュリティ機能が無効になっていたりするAPIに出くわすと、彼らの悪事が少しだけ楽になります。さらに悪いことに、セキュリティの設定ミスを検出して悪用するための自動化されたツールが用意されているため、あなたの環境にそれらがあれば、悪用される可能性が高く、それがこの脆弱性がOWASPの危険なAPI欠陥リストに入った理由です。

お楽しみの前に、このデバッグの課題を解決できるかどうか見てみましょう。

セキュリティ機能の無効化/デバッグ機能の有効化/不適切なパーミッションの欠陥は、どのようにしてAPIに忍び込むのでしょうか？

この多次元的なAPIの欠陥がどのようにしてネットワークに追加されていくのかを知るためには、その構成要素に分解する必要があります。まず、デバッグ機能の有効化の問題から始めましょう。デバッグは、アプリケーションが正しく動作しなかったり、エラーが発生したりする原因を開発者が把握するのに役立つ便利なツールです。デバッグ機能を有効にすると、エラーや例外発生時に詳細なエラーページが生成されるため、開発者は何が悪かったのかを確認し、問題を修正することができます。アプリケーションがまだ開発中の場合は、この機能を有効にしても問題ありません。

しかし、ほとんどのフレームワークでは、本番環境でのデバッグモードの実行に関する警告が表示されるのには理由があり、おそらくデバッグを有効にするコードの中に表示されています。例えば、以下のようなものです。

# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください
DEBUG = True

この例では、デバッグを有効にしています。Django アプリケーションは、例外が発生すると詳細なエラーページを生成します。これが本番環境で行われた場合、敵対者はこのエラーページにアクセスすることができ、その中には環境に関するメタデータ情報が含まれています。ほとんどのフレームワークでは、デフォルトでデバッグ機能がオフになっていますが、長い開発期間中に有効になっていると、元に戻すのを忘れてしまいがちです。その後、アプリケーションが本番環境に移行すると、アプリケーション、あるいはサーバやネットワーク全体を危険にさらす方法について、攻撃者に多くの情報を提供してしまいます。

デバッグモードを有効にすることは、ほとんどが単独の問題ですが、不適切なパーミッションと無効なセキュリティ機能の脆弱性は、しばしば連動します。例えば、OWASP が提供している実際のシナリオでは、攻撃者が検索エンジンを使用して、誤ってインターネットに接続されているデータベースを見つけました。人気のあるデータベース管理システムは、デフォルトの設定を使用していたため、認証が無効になっていました。このように、不適切なパーミッションと無効化されたセキュリティ機能の脆弱性を組み合わせることで、攻撃者はPII、個人の好み、認証データを含む数百万件の記録にアクセスすることができました。

無効化されたセキュリティ機能/デバッグ機能の有効化/不適切なパーミッションの脆弱性の解消

この脆弱性を排除するためには、おそらく2つのアプローチが必要です。問題のうち、デバッグが有効になっている部分を取り除くには、APIやアプリケーションを本番環境に移行する前に、デバッグが無効になっていることを確認するためのチェック機能を開発プロセスに追加するだけです。今回の例から、そのための適切なコマンドは次のようになります。

# セキュリティ上の警告: 本番ではデバッグをオンにして実行しないでください。
DEBUG = False

現在、Django アプリケーションのデバッグ機能は、DEBUG フラグを False に設定すると無効になります。エラーに対応したエラーページは生成されません。もし敵がエラーページにアクセスできたとしても、有用なメタデータは含まれておらず、アプリケーションにリスクをもたらすことはありません。

無効化されたセキュリティ機能や不適切なパーミッションの脆弱性を排除することは、広範囲の特定の脆弱性を包含することができるため、少し困難です。これらを阻止する最善の方法は、ロックダウンされた資産を本番環境に迅速かつ容易に展開できるよう、標準的で反復可能なプロセスを開発することです。

その場合でも、オーケストレーション・ファイル、APIコンポーネント、Amazon S3バケットのパーミッションのようなクラウド・サービスが常にレビューされ、更新されるプロセスを作成する必要があります。このレビューでは、組織が常にAPIセキュリティを改善していることを確認するために、環境全体のセキュリティ設定の全体的な有効性を長期的に評価する必要があります。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

大量割り当ての脆弱性が生まれたのは、最近のフレームワークの多くが、クライアントからの入力をコードの変数や内部のオブジェクトに自動的に束縛する関数の使用を開発者に推奨しているからです。これは、コードを単純化し、操作を高速化するために行われます。

攻撃者は、この手法を用いて、クライアントが決して更新してはならないオブジェクトのプロパティを強制的に変更することができます。通常、これは、ウェブサイトをダウンさせたり、企業秘密を盗んだりするのではなく、ユーザが自分自身に管理者権限を追加するような、ビジネス特有の問題につながります。また、攻撃者は、オブジェクト間の関係や、悪用しようとするアプリケーションのビジネスロジックについてもある程度把握していなければなりません。

しかし、いずれの場合も、巧妙で悪意のあるユーザーの手にかかれば、大量割り当ての脆弱性の危険性は低くなりません。

その前に、ゲーム性を持たせた課題をプレイしてみてはいかがでしょうか。

攻撃者はどのようにして大量割り当ての脆弱性を利用するのでしょうか？

OWASP が提示したシナリオ（私たちは少し修正しました）では、ライドシェアのアプリケーションを想定しています。このアプリケーショ ンには、大量割り当てを使用してコード内のオブジェクトにバインドされたさまざまなプロパティが含まれています。これらには、ユーザが変更できる許可関連のプロパティと、アプリケーションが内部でのみ設定すべきプロセス依存のプロパティがあります。どちらもオブジェクトにプロパティをバインドするために大量割り当てを使用しています。

このシナリオでは、多くのユーザー向けアプリケーションで一般的に行われているように、ライドシェアアプリケーションがユーザーにプロフィールの更新を許可しています。これは、PUTに送られたAPIコールを使用して行われ、次のJSONオブジェクトが返されます。

{"user_name":"SneakySnake", "age":17, "is_admin":false}

攻撃者（この場合はSneakySnake氏）は、プロパティとオブジェクトの関係を把握しているので、自分のプロフィールを更新する最初のリクエストを以下の文字列で再送信することができます。

{"user_name":"SneakySnake","age":24,, "is_admin":true}

エンドポイントは大量割り当てに対して脆弱なため、新しい入力を有効なものとして受け入れます。このハッカーは、自分のプロフィールに数年分を追加しただけでなく、自分に管理者権限を割り当てました。

マスアサインメントの脆弱性の解消

一部のフレームワークでは大量の代入機能が使えて便利かもしれませんが、APIの安全性を保ちたいのであれば、そのようなことは避けるべきです。代わりに、リクエストの値をオブジェクトに直接バインドするのではなく、パースします。また、縮小されたデータ転送オブジェクトを使用することで、オブジェクト自体に直接バインドするのとほぼ同じ利便性を得ることができますが、関連するリスクはありません。

さらなる予防策として、上記の例にある管理者権限のような機密性の高いプロパティを拒否して、APIコールでサーバーに受け入れられないようにすることもできます。さらに、すべてのプロパティをデフォルトで拒否し、ユーザーに更新や変更をさせたい特定の非センシティブなプロパティを許可するという方法もある。これらのいずれかを行うことで、APIをロックし、環境から大量割り当ての脆弱性を排除することができます。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

新しいGitHub Actionにより、業界標準のSARIFファイルに開発者中心のトレーニングを追加し、GitHubのコードスキャンワークフローに直接追加することができます。

9月30日、GitHubは「GitHubコードスキャン」の一般提供を正式に発表しました。GitHubコードスキャンは、開発者を優先し、GitHubネイティブなアプローチで、セキュリティ上の脆弱性が本番環境に到達する前に簡単に発見することができます。

コードスキャンは、GitHub Actionsや既存のCI/CD環境と統合することで、開発チームの柔軟性を最大限に高めます。コードが作成されると同時にコードをスキャンし、プルリクエスト内で実行可能なセキュリティレビューを表示し、GitHubのワークフローの一部としてセキュリティを自動化します。

開発者のためのセキュリティへのシームレスなアプローチ。

オープンなSARIF（Static Analysis Results Interchange Format）標準をベースに構築されたコードスキャンは、増え続ける組織のニーズに合わせて設計されており、オープンソースや商用の静的アプリケーションセキュリティテスト（SAST）ソリューションなどを同じGitHubネイティブ体験内に含めることができます。

サードパーティのコードスキャンツールは、プルリクエストなどのGitHub内のイベントに基づいて、GitHubアクションまたはGitHubアプリで起動することができます。結果はSARIFとしてフォーマットされ、GitHub Security Alertsタブにアップロードされます。アラートはツールごとに集約され、GitHubは重複するアラートを追跡して抑制することができる。これにより、開発者はGitHub上のすべてのプロジェクトで好きなツールを使うことができ、すべてGitHubのネイティブなエクスペリエンスで利用できるようになる。簡単に言うと、これは従来のセキュリティに対するいくつかのアプローチの混乱を断ち切り、開発者のワークフローを尊重するものである。

昨日、Secure Code Warrior は、GitHubのブログ記事「Third-Party Code Scanning Tools」の中で、唯一の開発者中心のトレーニングプロバイダーとして紹介されました。Static Analysis & Developer Security Training」で、Synk、Checkmarx、Fortify On Demand、Synopsis、Veracodeと並んで紹介されました。

多くのSCA/SASTソリューションは、発見された各脆弱性の詳細や、公開されているアドバイザリや関連するCWEへの参照を数多く提供していますが、すべての開発者がセキュリティの専門家ではありませんし、それを期待すべきでもありません。実用的で使いやすいアドバイスやツールこそが、実行可能な認識への鍵となります。

コンテクスト・マイクロ・ラーニング

開発者が脆弱性についての理解を深めれば深めるほど、リスクを理解し、最も差し迫った問題の修正を優先し、最終的には脆弱性の発生を未然に防ぐことができます。そこでSecure Code Warrior の出番です。私たちの使命は、楽しく、魅力的で、フレームワークに特化したトレーニングを通じて、開発者が最初から安全なコードを書けるようにすることです。また、開発者がセキュリティマインドセットを持って考え、コードを書くことで、セキュリティコンプライアンス、一貫性、品質、開発スピードの迅速な向上を実現できるよう支援します。

GitHubコードスキャンの統合

Secure Code Warrior は、GitHubのコードスキャンにコンテクスト学習をもたらすGitHubアクションを構築しました。つまり、開発者はSnyk Container Actionのようなサードパーティのアクションを使って脆弱性を発見し、CWEに特化した、関連性の高い学習によって出力を増強することができます。

Secure Code Warrior GitHub Actionは、業界標準のSARIFファイルを処理し、SARIFルールオブジェクトのCWE参照に基づくコンテキスト学習を追加します。これにより、開発チームとセキュリティチームは、脆弱性を発見するだけでなく、脆弱性の再発防止に役立つ実用的な知識でサポートされるSASTツールのレポートを充実させることができます。

自分で試してみる準備はできていますか？

このアクションは、GitHub Marketplaceから直接無料で入手できます。
Secure Code Warrior GitHub Action について詳しくは、こちらをご覧ください。

このシリーズのブログでは、アプリケーション・プログラミング・インターフェース（API）に関連する最悪の脆弱性に焦点を当てます。これらの脆弱性は、Open Web Application Security Project(OWASP)のトップAPI脆弱性リストに掲載されるほどのものです。APIが現代のコンピューティングインフラにとっていかに重要であるかを考えると、これらはアプリケーションやプログラムから絶対に排除しなければならない重大な問題です。

関数レベルのアクセス制御ができない脆弱性は、制限すべき機能をユーザに実行させたり、保護すべきリソースにアクセスさせたりします。通常、機能やリソースは、コード内または構成設定によって直接保護されますが、正しく行うことは必ずしも容易ではありません。最近のアプリケーションには、多くの種類のロールやグループが含まれていることが多く、さらに複雑なユーザ階層があるため、適切なチェックを実施することは困難です。

しかしその前に、ゲーム化されたチャレンジをプレイして、このトリッキーなクラスのバグを乗り越えるための自分のレベルを確認してみませんか？

さらに詳しく見ていきましょう。

APIは高度に構造化されているため、特にこの欠陥の影響を受けやすい。コードを理解している攻撃者は、制限されるべきコマンドをどのように実装するかについて、経験に基づいた推測を行うことができます。これが、関数/リソースレベルのアクセス制御の脆弱性がOWASPのトップ10に入った主な理由の一つです。

機能レベルのアクセス制御の脆弱性を攻撃者はどのように利用するのでしょうか？

機能やリソースが適切に保護されていないことを疑う攻撃者は、まず攻撃したいシステムにアクセスする必要があります。この脆弱性を利用するためには、エンドポイントに正当なAPIコールを送信する許可を得なければなりません。おそらく、アプリケーションの機能の一部として、低レベルのゲストアクセス機能や、匿名で参加できる何らかの方法があるのでしょう。このようなアクセスが確立されると、正当なAPIコールの中のコマンドを変更することができます。例えば、GETをPUTに置き換えたり、URLのUSERSの文字列をADMINSに変更したりすることができる。繰り返しになるが、APIは構造化されているので、どのコマンドが許可されているか、文字列のどこに入れればいいかは簡単に推測することができる。

OWASP は、この脆弱性の例として、新規ユーザーがウェブサイトに参加できるように設定された登録プロセスを挙げています。おそらく、以下のような API の GET 呼び出しを使用することになるでしょう。

GET /api/invites/{invite_guid}を取得します。

悪意のあるユーザーは、ユーザーの役割や電子メールなど、招待に関する詳細が記載されたJSONを返します。その後、GETをPOSTに変更し、さらに以下のAPIコールを使用して、招待をユーザーから管理者に昇格させることができます。

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

POSTコマンドを送信できるのは管理者のみであるべきですが、適切に保護されていない場合、APIはそのコマンドを正当なものとして受け入れ、攻撃者が望むものを実行してしまいます。この場合、悪意のあるユーザーは、新しい管理者としてシステムに招待されることになります。その後、彼らは正当な管理者ができることを何でも見たりやったりできるようになりますが、これは良いことではありません。

機能レベルのアクセスコントロールの脆弱性の解消

このAPIの脆弱性を防ぐことは特に重要です。攻撃者にとって、構造化されたAPI内で保護されていない関数を見つけることは難しいことではありません。攻撃者は、APIにある程度アクセスすることができれば、コードの構造をマッピングして、最終的に追跡されるような呼び出しを作成し始めることができます。

そのため、すべてのビジネスレベルの機能は、ロールベースの認証方法を使用して保護する必要があります。ほとんどのフレームワークは、それを実現するための一元化されたルーチンを提供しています。もし、あなたが選んだフレームワークが提供していない場合や、提供されているルーチンを実装するのが難しい場合は、簡単に使用できるように特別に作られた多くの外部モジュールがあります。最終的にどのような方法を選択するにせよ、認証は必ずサーバ上で行うようにしてください。クライアント側で機能を保護しようとしないでください。

機能レベルやリソースレベルのパーミッションを作成する際には、ユーザーには必要なことを行うためのパーミッションのみを与え、それ以上は与えないようにすることを念頭に置いてください。APIのコーディングでも何でも、常にそうであるように、最小特権の方法論を実践してください。

この脆弱性に関する詳しい情報は、以下のブログをご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き上げ、最新の状態に保つことができます。

全米サイバーセキュリティ意識向上月間は、サイバーセキュリティ専門家にとって年に一度の最も華やかな機会であり、多くの企業が組織全体のセキュリティ意識の高揚を振り返り、評価するために活用しています。また、2018年だけでも62％の企業がフィッシング攻撃やソーシャルエンジニアリング攻撃を経験しており、セキュリティの役割を担っているかどうかにかかわらず、企業内のすべての個人が適切なサイバーセキュリティ意識向上トレーニングを受けられるようにすることの重要性は、いくら強調してもし過ぎることはありません。

この月は、ますますグローバル化するイベントとして、ベストプラクティスを議論するためのキャッチボールの場となっており、その取り組みは意図的に表面的なものとなっています。しかし、強固なセキュリティプログラムを持ち、社内に専門家がいる組織であっても、この期間を利用して、より技術的なチームがそれぞれの役割に応じてセキュリティ意識を高めるために必要なことを評価することができます。

AppSecのスペシャリスト、開発チームのリーダー、そしてよりセキュリティに精通したエンジニア集団にとっては、卵の吸い方を教わっているような気分になるかもしれません。しかし、企業内のチャンピオンこそが、セキュリティと安全性を全社的に新たな高みへと押し上げることができるのです。

Cybersecurity Awareness Monthを盛り上げるには

これは、セキュリティチームが開発チームにオリーブの枝を差し伸べる絶好の機会である。おそらく、チーム間の活動やプログラムの形で、開発者が自分たちの仕事の中でセキュリティについて前向きに考えることができるようにするのであろう。

キックオフのアイデアとしては、以下のようなものがあります。

1. 開発者が安全なコーディングを学ぶために必要なサポートを受けることができます。仕事に適したツールを持っていないことは、タスクを「難しすぎるバスケット」に入れてしまうことを正当化しているように感じられます。
   
   今月は、開発技術スタックに何が欠けているのか、どのマネージャーが協力してコミュニケーションを改善し、セキュリティの可視性を高めることができるのか、そして誰が今後もセキュリティを擁護し続けることができるのかを理解するための月です。
   
2. ランチ＆ラーン」というイベントを開催する。一般的に、サイバーセキュリティや開発のコミュニティには、自分の専門知識を喜んで共有してくれる非常に寛大な人々が溢れています。カンファレンスの講演者や他社の技術者仲間、あるいは地元のOWASP支部に連絡を取り、チームに来ておしゃべりしたり、組織の誰かとウェビナーを録画したりできる人を探してみましょう。比較的短期間で成果を上げることができますし、新進気鋭の開発者にとっては、さまざまなセキュリティのキャリアパスを目の当たりにすることで、大きなメリットを得ることができます。
   
3. 集まって切磋琢磨しましょう。少し変わった特別なことをすれば、セキュリティについての学習はもっと楽しくなります。セキュアコーディングtournaments は、開発者が自分のセキュアコーディングのスキルを試したり、ゲーム性のある環境で仲間と競い合ったりするのに最適な方法です。仮装をテーマにして、チームごとに工夫を凝らしてみましょう（開発者対マネージャーなんてどうでしょう）。ピザや飲み物を注文して、エネルギッシュな音楽を流せば、組織全体にとって忘れられないイベントになるでしょう。

コミュニティへの還元Secure Code Bootcamp アプリを無料でダウンロード

私自身も開発者ですが、昔から無料で共有・利用できるものを探すのが常でした。他の人の役に立つようなフリーウェアを作ることは誇りであり、今月は私たちのルーツを振り返り、コミュニティに何を提供できるかを考える良い機会です。

そのために、新しい無料アプリSecure Code Bootcamp を発表します。これは、いつでもどこでもセキュリティ意識を高めながら、自分自身に挑戦したいコーダーのためのポケット・セキュア・コーディング・コンパニオンです。

iOSとAndroid用のアプリを今すぐダウンロードして、Node.JS、Python:Django、Java:Spring、C# .NETにおけるOWASPの脆弱性を見つけ、特定する方法を学びましょう。MVCです。

リソースの不足とレートの制限により、APIの脆弱性は、タイトルで説明されていることとほぼ同じように振る舞います。すべてのAPIは、その環境に応じて利用可能なリソースとコンピューティングパワーが制限されています。また、多くのAPIは、ユーザーや他のプログラムからの要求に応じて、必要な機能を実行する必要があります。この脆弱性は、あまりにも多くのリクエストが同時に来て、APIがそれらのリクエストを処理するための十分なコンピューティングリソースを持っていない場合に発生します。その結果、APIは新たな要求に対応できなくなり、利用できなくなります。

APIは、レートやリソースの制限が正しく設定されていなかったり、コード内で制限が定義されていなかったりすると、この問題の影響を受けやすくなります。例えば、ビジネスが特に忙しい時期になると、APIが過負荷になる可能性があります。しかし、これはセキュリティ上の脆弱性でもあります。なぜなら、脅威となるアクターは、サービス拒否（DDoS）攻撃を行うために、保護されていないAPIに意図的にリクエストを過負荷にすることができるからです。  

ところで、これまでのAPIゲーミフィケーションのチャレンジはいかがでしたか？もしあなたが、今すぐレート制限のある脆弱性を扱うスキルを試したいなら、アリーナに足を踏み入れてください。

さて、もう少し踏み込んでみましょう。

リソースの不足やレートの制限によるAPIの脆弱性の例を教えてください。

この脆弱性がAPIに潜り込む方法は2つあります。1つ目は、コーダーがAPIのスロットルレートを単純に定義していない場合です。インフラのどこかにスロットルレートのデフォルト設定があるかもしれませんが、それに頼るのは良いポリシーとは言えません。そうではなく、それぞれのAPIに個別にレートを設定する必要があります。特に、APIは機能や利用可能なリソースが大きく異なる場合があるからです。

例えば、数人のユーザーにしかサービスを提供しないように設計された内部APIであれば、非常に低いスロットルレートでも問題なく動作します。しかし、ライブの E コマースサイトの一部である一般向けの API では、同時ユーザー数の急増の可能性を補うために、特別に高いレートを定義する必要があるでしょう。いずれの場合も、予想されるニーズ、潜在的なユーザー数、利用可能なコンピューティングパワーに基づいて、スロットルレートを定義する必要がある。

特にトラフィックの多い API では、パフォーマンスを最大化するために、レートを無制限に設定したくなるかもしれません。これは、簡単なコードで実現できます（例として、Python Django REST フレームワークを使用します）。

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

この例では、匿名のユーザーも、システムに知られているユーザーも、時間経過によるリクエスト数を気にすることなく、無制限にAPIにアクセスすることができます。なぜなら、APIがどれだけ多くのコンピューティングリソースを持っていても、攻撃者はボットネットなどを配備して、最終的にはAPIの動作を遅くしたり、場合によっては完全にオフラインにしたりすることができるからである。そうなると、有効なユーザーはアクセスを拒否され、攻撃が成功することになります。

リソース不足やレート制限の問題を解消するために

組織がデプロイするすべてのAPIは、そのコードの中でスロットルレートを定義する必要があります。これには、実行タイムアウト、最大許容メモリ、ユーザーに返すことのできる1ページあたりのレコード数、定義された時間枠内で許可されるプロセス数などが含まれます。

上記の例では、スロットリング率を大きく開放するのではなく、匿名ユーザーと既知のユーザーで異なる率を設定するなど、厳密に定義することができます。

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

今回の例では、匿名のユーザーが1時間にリクエストできる回数を200回に制限しています。すでにシステムで審査されている既知のユーザーは、1時間あたり5,000リクエストと、より大きな余裕が与えられます。しかし、これらの制限は、ピーク時の偶発的な過負荷を防ぐためや、ユーザーアカウントが漏洩してサービス妨害攻撃に使用された場合の補償のためのものである。

最後に考慮すべきグッドプラクティスとして、ユーザーがスロットリングの限界に達したときには、その限界がいつリセットされるかについての説明とともに、ユーザーに通知を表示することをお勧めします。これにより、有効なユーザーは、アプリケーションがリクエストを拒否する理由を知ることができます。また、承認されたタスクを実行している有効なユーザーがAPIへのアクセスを拒否された場合にも、スロットリングを増加させる必要があることをオペレーション担当者に知らせることができるため、この方法は役に立つ。

をご覧ください。 Secure Code Warriorブログページでは、この脆弱性に関するより詳しい情報や、他のセキュリティ上の欠陥の被害から組織や顧客を守るための方法を紹介しています。また、Secure Code Warrior トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

過剰なデータ露出の脆弱性は、OWASP のリストに掲載されている他の API 問題とは異なり、非常に特殊な種類のデータが関係している点が特徴です。この脆弱性の背後にある実際の仕組みは他の問題と似ていますが、この場合の「過度のデータ露出」は、法的に保護されたデータや非常にセンシティブなデータを含むと定義されています。これには、よくPIIと呼ばれる、個人を特定できる情報が含まれます。また、PCI（Payment Card Industry）情報が含まれる場合もあります。さらに、欧州の一般データ保護規則（GDPR）や米国の医療保険の相互運用性と説明責任に関する法律（HIPAA）などのプライバシー法の対象となる情報も、過剰なデータ露出に含まれます。

ご想像のとおり、これは大きな懸念材料であり、精通した開発者は可能な限りこれらのバグをつぶす方法を学ぶ必要があります。もし、あなたがデータ漏洩対策に取り組む準備ができているなら、ゲーム化されたチャレンジに参加してみてください。

あなたのスコアは何点でしたか？読んでみてください。

過剰なデータ露出の例としてはどのようなものがありますか？

過剰なデータ公開が発生する主な理由の一つは、開発者やコーダーがアプリケーションで使用するデータの種類を十分に把握していないことです。そのため、開発者は、すべてのオブジェクトのプロパティがエンドユーザーに公開されるような汎用的な処理を行う傾向があります。

また、開発者は、フロントエンドコンポーネントがユーザーに情報を表示する前にデータのフィルタリングを行うことを想定していることがあります。一般的なデータであれば、これが問題になることはほとんどありません。しかし、例えば、セッションIDの一部として法的に保護されたデータや機密データをユーザに公開すると、セキュリティと法的な観点から大きな問題になります。

OWASPレポートでは、機密データが誤って共有されやすい例として、警備員が施設内の特定のIoTベースのカメラへのアクセス権を与えられた場合を想定しています。おそらく、それらのカメラは密閉された安全なエリアを監視しており、一方で、人を映し出す他のカメラは、より高い権限を持つ警備員や監督者に制限されているはずです。

警備員に許可されたカメラへのアクセス権を与えるために、開発者は以下のようなAPIコールを使用することができます。

/api/sites/111/cameras

それを受けて、アプリは警備員が見ることのできるカメラの詳細を以下の形式で送信します。

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

表面的には問題なく機能しているように見えます。アプリのグラフィカル・ユーザー・インターフェースを使用している警備員は、自分が見ることを許可されたカメラのフィードだけを見ることができます。問題は、一般的なコードを使用しているため、実際のAPIレスポンスには、施設内のすべてのカメラの全リストが含まれていることです。ネットワークを盗聴してそのデータを取得したり、警備員のアカウントを侵害したりすると、ネットワーク上のすべてのカメラの位置と名称を知ることができます。そして、そのデータに制限なくアクセスすることができるのです。

過剰なデータ露出をなくす

データの過剰な露出を防ぐ最大の鍵は、データとそれを取り巻く保護機能を理解することです。汎用的なAPIを作成し、ユーザーに表示する前にデータを選別することをクライアントに任せることは、多くの予防可能なセキュリティ侵害につながる危険な選択です。

関連するデータ保護を理解することに加えて、汎用APIを使ってユーザーにすべてを送信するプロセスを止めることも重要です。例えば、to_json()やto_string()のようなコードは避けなければなりません。代わりに、コードは許可されたユーザーに返す必要のあるプロパティを特に選び、その情報だけを送信するべきです。

保護されたデータが誤って過剰に共有されていないことを確認する方法として、組織は、セキュリティの追加レイヤーとして、スキーマベースのレスポンス検証メカニズムの実装を検討する必要があります。スキーマベースのレスポンス検証メカニズムでは、エラー報告のルールを含め、すべてのAPIメソッドから返されるデータを定義し、強制する必要があります。

最後に、PIIやPCIを含むと分類されるデータや、GDPRやHIPAAなどの規制で保護されている情報は、強力な暗号化を用いて保護する必要があります。これにより、過剰なデータ露出の脆弱性の一部としてデータの場所が漏れることがあっても、悪意のあるユーザーや脅威のあるアクターの手に渡ったとしても、データを保護するための優れた二次的な防御策が用意されています。

以下のブログページをご覧ください。 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 トレーニングプラットフォームのデモをお試しいただくことで、サイバーセキュリティに関するすべてのスキルを磨き、最新の状態に保つことができます。

技術系スタートアップ企業で働くことの醍醐味の一つは、その過程で出会った面白くて賢い人々とのコラボレーションです。クールなアイデアから本格的な市場競争力を持つ企業へと成長させるには、自分だけのアベンジャーズ（あるいはジャスティス・リーグ）チームを編成する必要があります。

そこで今回は、当社のエキスパートであるオスカー・キンタスにスポットライトを当ててみたいと思います。彼はプロダクトコンテンツチームに所属し、シニアセキュリティリサーチャーとして活躍しています。彼はInfrastructure as Code（IaC）に関する専属の魔術師でもあります。彼は、178回にも及ぶIaCプラットフォームのチャレンジを支え、この新鮮でホットなトピックに関するあらゆる質問に答えてくれます。

私たちは彼を特別な存在だと思っていますので、ぜひ知っていただきたいと思います。ここでは、今話題のInfrastructure as Codeのセキュリティ、彼の役割、そしてクラウドのインフラとエンジニアをより良く準備するために組織ができることについて、彼の洞察を紹介します。

Q:Secure Code Warrior でのあなたの役割について教えてください。一日の流れを教えてください。

A: 私はプロダクト・コンテンツ・チームの一員として、シニア・セキュリティ・リサーチャーとして働いています。典型的な仕事は、さまざまな言語（Python、Java、Golangなど）で書かれた課題のコードをレビューし、コードの品質基準が満たされているか、またセキュリティのベストプラクティスが実装されているかを確認することです。また、新しいIaCコンテンツの開発も行っています。

Q: あなたは、Infrastructure as Codeプラットフォームのすべてのチャレンジを支える天才です。どのようなプロセスを経ているのでしょうか？

A: リサーチと、様々なスキルレベルのユーザーに関連性の高いコンテンツを提供するための努力の組み合わせだと思います。私は通常、インフラを導入する際にユーザーが直面する最も一般的な問題を調べることから始め、その情報をもとに、それぞれのケースに応じたセキュリティのベストプラクティスを示す有用な課題を作成します。

私は常に、戦士たちに良い学習体験を提供し、それが仕事に関連した、継続的な利益をもたらす有益な訓練であるようにしています。

Q: IaCのセキュリティは、現在、非常に人気のあるテーマです。クラウドのセキュリティ対策について、企業が直面している主な問題は何でしょうか？
A: Infrastructure as Codeとは、コードを使ってインフラのリソースを管理することです。そのコードを数行書くだけで、何百ものクラウドリソース（ネットワーク、ファイアウォールルール、仮想マシン、コンテナなど）を展開することができますが、これらは適切に設定されていないとセキュリティバグを含む可能性があります。そのため、安全なアプリケーションの展開に適用されるのと同じ原則がIaCにも適用され、これらのリスクとその修正方法をSDLCに関わるすべてのチームが理解する必要があります。

この認識と行動は、IaCセキュリティの適切なトレーニングと、クラウドエンジニアの安全なコーディングスキルを優先させることから始まります。クラウドエンジニアは強力な防御層となり得ますが、アプリケーションをホストするインフラを構築している場合は特に重要です。

Q:Kubernetesについては、業界でも関心が高く、広く使われているようです。しかし、我々のプラットフォームのデータでは、Terraformが圧倒的に人気のある言語であり、高いエンゲージメントを誇っています。
A:Terraformは、シンプルな構文でマルチクラウド環境（AWS、GCP、Azureなど）にインフラリソースを展開できるため、IaCでは事実上の言語となっています 。コードを使ってインフラを定義することができ、クラウドAPIと透過的に相互作用してリソースのデプロイメントを管理します。

この言語は非常に汎用性が高く、ソースコントロールリポジトリに追加できるため、DevOps / DevSecOpsの原則をインフラのデプロイメントにも適用することができます。しかし、これによって対処しなければならない新たな脅威も出てくるため、Terraformを使ったセキュアコーディングの包括的なトレーニングが必須となります。

Q:あなたはIaCのセキュリティエキスパートですね。
A:IaCはまだ始まったばかりなので、頻繁に新しいものがリリースされています。このような新しい技術についていくのは少し大変ですが、同時にやりがいもあります。新しいことを学んだり、新しいサービスのセキュリティ・ベスト・プラクティスをテストしたりするのがとても好きです。

あなたのIaCセキュリティを次のレベルに引き上げます。

クラウド開発者にInfrastructure as Codeに関するセキュリティ・スキルを磨いてもらいたいなら、IaC Top 8にチャレンジしてみましょう。各章では、IaCのセキュリティに関する8つの一般的なバグについて、新しい知識を試すためのインタラクティブな課題も含めて、完全に説明しています。

あなたのスコアを教えてください、そしてオスカーを誇りに思ってください。