アプリケーションセキュリティの簡単な紹介

Scott Arciszewskiの「アプリケーションセキュリティの優しい紹介」の翻訳。

このメモを読んでいるプログラマーにとって悲しいニュースがあります。 しかし、ご存知のように、銀の裏地はありません。



最初のニュース：あなたがWeb開発者であるか、Web開発を学び始めることを考えているなら、ほとんどの場合、あなたは自分をセキュリティの専門家だとは思わないでしょう。 たとえば、ユーザーデータを検証するときなど、いくつかのセキュリティリスクを考慮する必要があります。 しかし、おそらく、あなたはまだこの分野の専門家ではありません。



2番目のニュース：戦闘サーバーでコードが実行される場合、システム全体、場合によってはネットワーク全体の最前線でコードが実行されます。 したがって、開発中のアプリケーションは安全でなければならないというのは論理的です。



データベースクエリへのユーザーデータの組み込みを誤って処理した結果、誰かがデータベースに保存されているプラ​​イベートデータにアクセスしたり、アプリケーションに損害を与えたりする可能性があるとします。 出力前にデータをスクリーニングするのを忘れたか、適切にスクリーニングしなかった-そして、「突然」アプリケーションがクライアントのユーザーに反して、コンピューターにマルウェアを感染させた。



多くの開発者の理解では、これはすべて、不必要な作業の複雑さのように見えます。 私が聞いた最も一般的な議論：「私たちの顧客はセキュリティにお金を払わない、彼らは「昨日」リリースされた新しい、美しく実装された機能を望んでいます。」



コンピュータセキュリティの専門家になることはお勧めしません。 最終的には、少なくともある程度の教育が必要です。 しかし、私は次の考えを伝えたい： アプリケーションのセキュリティについて考えることは、すべての開発者の責任です 。 これに向けて一歩だけ進んで停止することができます。これは、組織と顧客にとって十分です。 主なことは、正しい最初の一歩を踏み出すことです。



ほとんどの場合、アプリケーションセキュリティの問題を調査する場合、OWASP Top10やSANS Top25など、最も一般的な脅威のリストを読むことをお勧めします。 私の意見では、この勧告は善よりも害をもたらします。 実際、実際にはもっと多くの脆弱性があります。 たとえば、「誰かが11 OWASPの脆弱性を使用して地球をハッキングすることができました。誰も予想していなかったからです」というジョークを使用できます。



攻撃者はチェックリストではなくチャートを使用すると考えています。 彼らは目標を達成するための最も簡単な方法と、システムの外にいて、その中で特権的な地位を獲得するという目標を探しています。



誰かがあなたのデータを盗み、ユーザーのコンピューターに感染し、ネットワークリソースを使用して攻撃を広めることを恐れずにアプリケーションを起動したい場合、チェックリストを念頭に置くことはあまり良い考えではありません。



したがって、セキュリティの脆弱性を少し異なる角度から見ることをお勧めします。 脅威リストと比較して、以下で説明するモデルは、初心者が知覚するのにより適しています。また、マルチレベルのアプリケーション保護の開発に役立つ思考のタイプを開発します。

アプリケーションの脆弱性を記述するための分類モデル

特定のサイズのチェックリスト（OWASP Top10、SANS Top25、Paragon Top50など）を作成してアプリケーションの脆弱性を体系化する代わりに、生物の分類に使用されるものと同じアプローチを使用できます。 生物と同様に、多くの脆弱性には特徴と類似点があります。 共通のシステムで生物の多様性を受け入れるというタスクは達成不可能に思えるかもしれませんが、高度な抽象化を使用して、それらすべてを少数のグループにまとめることができます。 同様のアプローチを脆弱性に適用できます。 実際、これはこの記事で共有したいアイデアです。



以下は、脆弱性を分類する私の方法です。 経験豊富な開発者でなく、それぞれを研究したとしても、特定の分野の保護戦略のみを知っているが、脆弱性の根本的な問題を理解していない人よりも貴重な専門家になることができます。

1.命令からのデータの分離の違反

このカテゴリは、あらゆる種類のハッカーが使用するほとんどの脆弱性を対象としており、次のサブカテゴリが含まれます。

• クロスサイトスクリプティングの脆弱性
  
  Webクライアントを介した影響。 アプリケーションで誤って処理されたデータは、ユーザーのコンピューター上の悪意のあるコードでJavaScriptを起動します。
  
  
  
  
• SQLインジェクション
  
  データベースクエリに影響します。 作成された文字列を特定の方法で送信することにより、攻撃者はSQLクエリのセマンティクスを変更できます。 多くの場合、SQLインジェクションはマルウェアの拡散にも使用できます。
  
  
  
  
• LDAPインジェクション
  
  SQLインジェクションと同様の方法でActive Directoryに影響します。 LDAPインジェクションは、サーバーディレクトリからのデータの任意の読み取り/書き込みを引き起こし、その結果、ネットワーク全体のユーザーアカウントの特権につながる可能性があります。
  
  
  
  
• XPATHインジェクション
  
  XMLドキュメントへのリクエストに影響します。 文書の任意の部分のデータのarbitrary意的な開示につながる可能性があります。
  
  
  
  
• OSコマンドでのインジェクション
  
  OSで任意のコマンドが実行される可能性があります。

これらのすべての場合に共通するのは、エンドユーザー（または他のデバイス）がシステムにデータを入力して、それらを処理する命令のセマンティクスを変更できることです。

2.アプリケーションの論理エラー

多くのコンピューターセキュリティ研究者は、アプリケーションロジックが命令のセマンティクスを変更するよりも面白くないと感じています。 ただし、Webサーバーのハッキングにつながる可能性のある脆弱性を除去するように注意を払うと、論理エラーはしばしば忘れられます。



検証なしでデータが盲目的に受信されたり、一部のステップがスキップされたり、アルゴリズムの新しいステップに移動するときに前のステップの結果がチェックされない場合、ロジックは不良と呼ばれます。



アプリケーションの論理エラーは、例によって最もよく示されています。



Paypalを使用してクレジットカード支払いを処理するeコマースサイトを開発しているとします。 チェックアウト統合の操作を十分に理解していない人の場合、プロセスは次のようになります。

1. ユーザーは商品をバスケットに追加し、支払い方法Paypalを選択して、支払いシステムのサイトに移動します。
2. ある種の魔法が起こります。
3. ユーザーは、バスケットのコンテンツが支払済みとしてマークされているリンクをクリックし（彼に固有ではない）、成功した支払ステータスのページを表示します。

ここで発生する可能性のあるいくつかの論理エラーがありますが、明らかにそれらを防止するために作業しなかった場合に限ります。 ユーザーは次のことができます。

1. 同じ価格で-1の量の別の製品をバスケットに追加し、合計コストを0ドルに減らします。
2. チェックアウトプロセスをスキップし、特別なリンク（ステップ3）を事前に知っていれば、トランザクションは自動的に支払われます。
3. 安い商品をバスケットに追加し、Paypalリンクをクリックして、ストアに戻り、高価な商品のグループをバスケットに追加します。 次に、以前に開いた[Paypal]タブに移動し、少量で購入を完了します。 ただし、完全に支払済みとしてマークされます。

最初の問題は、入力をチェックするだけで修正されます。 他の2つのケースでは、サーバー間のAPI統合のみが正しいでしょう。 チェックアウトプロバイダーは、ユーザーに提供されたリンクをクリックするのではなく（悪意を持って誰も行動しない完璧な世界でも壊れる可能性があります）、購入した製品と転送した金額をサーバーに通知します。



私の例のすべての不正行為は手動制御を使用して検出できますが、残念ながら、大量のトランザクションに対応することはできません。 はい、そしてあなたの顧客のために余分な仕事を作成する理由。 ソフトウェアの利点の1つは、自動化を使用できることです。 ただし、その信頼性はシステムのセキュリティに依存します。

3.アプリケーションの作業環境

アプリケーションが真空内に存在しません。 機能するかどうかは、他の多くのコンポーネントに依存しています。

• サードパーティのライブラリ。
• サーバーOS
• サーバーハードウェア;
• アプリケーションが仮想マシンで実行されている場合は、仮想マシンモニター。
• データセンターの電源。
• 外部世界への内部ネットワーク接続の存在。
• エンドユーザーソフトウェア（Webブラウザー）。

これらのコンポーネントのいずれかの脆弱性は、アプリケーション全体のセキュリティを弱めるか、公然と侵害する可能性があります。 この場合、自分自身を守る唯一の方法は、ソフトウェアを時間通りに更新し、開発者によってサポートされなくなったソフトウェアを使用しないことです。



例は、リソースの非対称性の問題です。 ほとんどのWebサイトは物理的に同じマシンで実行されており、数千のマシンから同時に多数のリクエストを受信した場合、負荷を処理できません。 これはDDoS攻撃と呼ばれます。 これに対処する唯一の効果的な方法は、アプリケーションレベルではなくネットワークレベルです。

4.暗号化の脆弱性

暗号化に関連する脆弱性の多くは、アプリケーションの論理エラーまたはコンポーネントの不適切な動作が原因である可能性がありますが、暗号化には別の考慮が必要です。



たとえば、暗号化を使用せずに2つの文字列を比較することは特別なことではありません。 ただし、暗号化を使用する場合、この操作は異なる回線オプションに対して同じ時間がかかることを確認する必要があります。 そうしないと、アプリケーションはタイミング攻撃（暗号アルゴリズムを使用して実行時間を監視して列挙を最適化するブルートフォース攻撃の一種）に対して脆弱になります。 開発者自身が暗号化を使用してアルゴリズムを記述しようとすると、これは災害につながる可能性があります。



暗号化はそれ自体が複雑なので、専門家に提供してください。 暗号化を試して研究することは有用ですが、そのようなコードを戦闘サーバーに投稿することは絶対に避けてください。また、誰にも暗号化を使用することを推奨しないでください。

さまざまなセキュリティ脆弱性

私が知らないセキュリティ問題がある可能性は非常に高いです。 また、上記で概説したカテゴリのいずれにも当てはまらないセキュリティ問題がある可能性があります。 または、いくつかのカテゴリに起因する脆弱性があります。



カテゴリを拡大してその数を減らすことで全体像をカバーしようとする私の脆弱性の分類は、開発者が特定の年の最も一般的な脆弱性の任意のリストを記憶することを期待するよりも、アプリケーションセキュリティの全体像を得るためのより簡単で明確な方法だと思います。



もちろん、彼女は完璧にはほど遠い。 最終的には、プロフェッショナルコミュニティのみが、どのカテゴリにする必要があるか、境界をどこに設定するか、どのレベルにする必要があるかという質問に答えることができます。



誰もがこのモデルの改善に参加するよう招待されています。



これが最初のステップです。次のルールに従うと、順調に進んで前進できます。

1. 命令が処理するデータによって破壊されることから命令を保護します。
2. アプリケーションのロジックについて完全に理解し、間違いなく入手してください。
3. アプリケーションが最新のシステムのソフトウェアを保持し、サポートされなくなったソフトウェアに依存しないでください。
4. 暗号化アルゴリズムの独立した実装を忘れてください。