アプリケーションのセキュリティ：それはほとんど簡単です

「私のプログラムは安全だというメモをください。」



-問題ありません！ あなたはこれのために何をしましたか？



-ええと...まあ...これは...何もない...



「なぜ彼女は無事だと思う？」



-さて、あなたは確認します！



-問題ありません！ すべての喜びはX0000ドルかかります。



-?!

記事について

この記事では、安全なソフトウェアを作成するためのいくつかのプラクティスについて説明します。



最初の部分は、安全なプログラミングに専念します。



一方では、安全なプログラミング技術が知られています。 それらの使用の経験が蓄積されており、多くの文献が書かれています。



一方、それらはあまり使用されません。 多くのプログラマーやプロジェクトマネージャーにとって、彼らは異国情緒があまり明確ではありません。



もちろん、この記事はこの問題を完全にカバーするふりをしているわけではありません。 しかし、それは正しい方向への小さな一歩にしましょう。 そして、あなたが、あなたが安全なプログラミングに異常なものは何もないことが分かると思います。



2番目の部分では、アプリケーションセキュリティのあまり知られていない側面について説明します。 しかし、ある意味では、これらの側面は安全なプログラミング技術を使用するよりもさらに重要です。



注意！ 記事は大きく、注意深く読む必要があります。

パートI.安全なプログラミング

技術を知る

各テクノロジーには2つの側面があります。 1つはユーザーにとって便利なプロパティです。製品で使用します。 第二の側面は、クラッカーが使用できる特性、技術の弱点です。 技術は非常に弱いため、どのような状況でもその使用を正当化できない場合があります。 たとえば、Cプログラムのgets関数はほとんどの場合悪です。 保護に必要な対策を講じることにより、他のテクノロジーを使用できます。 そのため、SQLサーバーを使用すると、SQLインジェクションの機会が開かれる可能性があります。 しかし、私たちはこれに対処する方法を知っており、必要な保護対策を講じる必要があります。



技術の両面を知る必要があります。 有用なプログラムを作成する方法は、プログラマーの主要な知識です。この知識のおかげで、私たちはお金を稼ぎます。 したがって、この側面を研究することに主な時間を費やしていることは非常に明確です。



しかし、優れた専門家は第2の側面を理解しています。 攻撃者がどのように攻撃するかを知る必要はありません。特定の脆弱性に対するエクスプロイトを作成できる必要はありません。 しかし、私たちの行動が脆弱性につながる可能性があるものと、これを回避する方法を理解する必要があります。



現在、このトピックに特化したいくつかの優れたリソースがインターネット上にあります。



そのようなリソースの1つは、Open Web Application Security Projectです。 名前が示すように、このプロジェクトはWebアプリケーションのセキュリティ専用ですが、他の分野でプログラミングする場合にも同じ情報を適用できます。 このサイトは現在人気のあるウィキペディアの形式で作成されており、個別の記事で構成されています。 さまざまな原則に従ってグループ化されたこれらの記事のリストがあります。 技術別にグループ化された記事へのポインタは、次のアドレスにあります 。



OWASPを繰り返し参照し続けます。 このプロジェクトは、アプリケーションセキュリティの専門家にとって非常に貴重なリソースです。



非常に優れた情報源は、 Common Weakness Enumeration Webサイトです。 このサイトには、ソフトウェアの脆弱性の原因をリストしたカタログの形式で、当社にとって関心のある情報が含まれています。 OWASPよりも知覚することは困難ですが、たとえば、チェックリストを作成する場合はより便利です。



これらのサイトを定期的に確認してください。 テクノロジーの安全性に関する情報は常に更新されています。これは見た目と同じように、所定の位置にとどまるために、できるだけ早く実行する必要があります。

ライブラリを使用する

車輪を再発明しないでください！ もちろん、私たちは皆、自分の何かをすることに非常に興味を持っています。 しかし、安全性において、発明は非常に不快な結果をもたらすため、実績のある手段を使用してください。



現在、多種多様なライブラリがあります。 ほとんどすべてのタスクに対応する既製のソリューションを見つけることができ、有料ライブラリとオープンソースライブラリの両方を見つけることができます。



たとえば、暗号化方式の実装にはopensslが推奨される場合があります。 ライブラリはよく知られており、私たちのほとんどにとって十分な程度に検証され、無料ライセンスの下で配布されています。



Java EEを使用するWebプログラマーはESAPIを好むかもしれません。 このライブラリは、ここですでに説明したOWASPプロジェクトのフレームワーク内で作成されたもので、安全なWebアプリケーションを作成するために必要な多くのメソッドを実装しています。 ライブラリには、入力データのフィルタリング、ユーザーの認証、アクセス権の確認などの機能が含まれています。 コードは、非常に広範囲に使用できるBSDライセンスの下でライセンスされています。



残念ながら、ESAPIは現在開発されていません。 それにもかかわらず、それは定評のあるライブラリであり、そのサポートが更新されることを期待する理由があります。



おそらく、JAVAの別のライブラリであるCoverity Security Libraryに注意を払うことは理にかなっています。 このライブラリは昨年末にリリースされましたが、これまでにあまり多くのレビューはありません。 それでも、アプリケーションセキュリティの分野で有名な会社によって作成されたものであり、できれば彼らが何をしているのかを理解していることを願っています。



これらは可能性のほんの一部です。 私はそれらを単に例として言及しました;ライブラリのリストはそれらだけに制限されることからほど遠いです。 さらに、多くの最新のフレームワークには必要な機能も含まれています。 このライブラリを誰が開発したか、どれだけうまくテストおよびテストされているかに注意してください。



プロジェクトで外部ライブラリを使用できない場合があります。 極端な場合（非常に、非常に極端です！）独自に作成し、慎重に確認してテストし、専門家に確認してテストしてもらい、もう一度慎重に自分でチェックしてテストしてください。 コードでこのライブラリの関数を使用し、必要なたびに新しいメソッドを作成しないでください。



一般的に、これは安全です。バイクが少ないほど良いソリューションです。

自己診断を行う

私たちは皆急いでいます。 現在作成中のコードは昨日提出する必要があったため、必要なのはコンパイルすることだけでした。 まあ、彼はまだ何か有用なことをしなければならず、いくつかのテストに合格しなければなりません。



やめて コードを書いたばかりのときは、コンパイルする前であっても、少し休憩を取り、リラックスして、コードを忘れてください。 休憩の後、さまざまな角度から書かれた内容を見てください。構文、コードの企業標準への準拠を確認してください。 コードのロジックを確認してください。 安全要件への準拠を確認してください（「技術を知る」、覚えていますか？）。



多くの時間を節約できます。 時間が無駄になっているように見えますが、アプリケーションのデバッグが大幅に削減されるため、時間は戻ります。



セルフテストは、高品質のソフトウェアを作成するための認識された慣行です。 そのため、 PSP （Personal Software Process）に含まれています。これは、厳しい時間と財政的制約に直面して高品質の製品を作成するために特別に設計されたプロセスです。



注意：虚栄心は品質だけでなく、スピードの敵でもあります。

コード検証ユーティリティを使用する

愚かな間違いをするのは人間の本性です。 同時に、すべてのプログラマーは、それを検出するのが最も難しいのは馬鹿げたエラーであることを知っています。



人がすべてを一度に覚えるのは難しいです。 脆弱性には多くの理由があります。 問題を回避するには、それらをすべて覚えておく必要があります。プログラムの存在を確認する必要があります。 さらに、クラッカーは静止していません。昨日安全であると考えられていたものは、今日すでに脆弱である可能性があります。



自動分析ユーティリティは、愚かなエラーや急速に変化する世界の問題を部分的に減らすことができます。 これらのプログラムはコードをスキャンし、その中に潜在的なセキュリティ問題の兆候を探します。 自動化されたユーティリティは、人間の介入をほとんど必要とせずに多くの種類の脆弱性を迅速に検出できるため、プログラマが他の問題にもっと注意を払うことができるため、優れています。 多くの場合、これらのユーティリティはかなり複雑な分析を行うことができますが、これは人にとっては時間がかかります。 これらの機能の一部はすでに最新のコンパイラに組み込まれているため、それらを有効にする方法を知っている必要があります。



自動分析に頼りすぎないでください。 そのようなプログラムによって生成された情報は、コンパイラの警告に関連するものとほぼ同じ方法で処理する必要があります。 警告がないことは、エラーがないことを意味しないことは誰もが知っています。 このようなスキャナーは、既知のタイプの脆弱性であっても、すべての脆弱性からはほど遠いものです。 一方、警告の存在はまだ問題の証拠ではなく、すべての警告を取り除くという思いやりのない欲求は、より深刻な脆弱性につながる場合があります。



自動化により、もっと面白いことのために時間を節約できます。 あなたの仕事の一部をコンピューターに委ねることができるなら、どうしてそれをしないのですか？

テスト

安全のために、プログラムは特定の動作を示さなければなりません。 たとえば、長すぎる行を入力しようとすると、プログラムはそれを拒否するか、トリムする必要があります。 特殊文字を入力する場合、データを拒否するか、文字を特別にエンコードする必要があります。



この動作はテストできます。 そして、プログラムの自動テストのすべての利点を享受できます。ほとんど人間の介入なしで、頻繁に実行できます。



ここではリンクを提供しません。 従来の機能テストと比較して、安全な動作をテストする特別な機能はありません。 TDD、継続的インテグレーションなど、私よりもよく知っているすべてのベストプラクティスを使用できます。 もちろん、安全な動作を記述できる必要があります（ここでも、「テクノロジを知る」）。



すべてを効果的にテストできるわけではありません。 たとえば、gets（）関数を使用すると、ほとんど常にバッファーオーバーフローが発生します。 この問題はテスト中に検出できます。 ただし、自動コードスキャンで検出する方が効率的です。単純なgrepでこれを簡単に処理できます。 もちろん、この例は非常に誇張されていますが、セキュリティテストの可能性を検討するための良い出発点になる可能性があります。



テストではすべてのセキュリティ問題を解決できるわけではありません。 しかし、自動的にテストできるものがあれば、それを使用してみませんか？

コードレビューを行う

コード修正は、エラーを検出する最も効果的な方法です。 さらに、検出された欠陥の数の観点と、検出のコスト（時間）の観点の両方で最も効果的です。 そのため、スティーブマッコネルの著書「Perfect Code」は、コードの修正に1時間を費やすことで、テストとトラブルシューティングの時間を最大100時間節約できるというIBMの研究へのリンクを提供しています。 数100に達することはめったにないと思いますが、それでもこれは非常に良い理由です。



コードの改訂はさまざまな方法で編成できます。 ペアプログラミング、仲間のプログラマによる非公式のコードレビュー、および安全なプログラミングの専門家が関与する非常に正式な検査がこの役割を果たすことができます。 目標に大きく依存します。プログラムにより高い要件が課せられるほど、より多くの人が監査に関与する必要があり、より正式に実行される必要があります。



監査の構成は、プログラマーの資格にも依存します。 明らかに、彼ら自身が安全なプログラミングの原則に十分に精通している場合、第三者の専門家を雇うことは意味がなく、非公式の手順で十分かもしれません。 一方で、高度に形式化されたコード検査に第三者の専門家を従事させることは、プログラマーをトレーニングするためのプログラムの重要な部分になる可能性があります。



そして再び、OWASP。 もちろん、このプロジェクトはそのような重要な方法論を迂回することはできませんでした。 したがって、プロジェクトのコードを監査する場合（まだこれを行うことを納得させていませんか？）、このサイトの対応するページは良い出発点です。



あなたはまだコードレビューを行っていませんか？ あなたに許しはありません!!!

複合体のすべてのメジャーを使用する

ええと...ここに何かを書く必要がありますか？

パートII セキュリティエンジニアリング

動機付けのアナロジー

今のところセキュリティから脱出しましょう。 プログラマーにとって最も一般的なタスクの1つは、既存のプログラムを変更することです。 プログラムを「ゼロから」作成する必要はあまりありませんが、既存のプログラムを変更（「維持」）する必要があります。



したがって、既存のプログラムを変更する必要があります。 そして、それが「重要な」変化であることを意味します。それは、それが意味しないように、各プログラマーが自分で簡単に状況を考えることができることを意味します。



1つの問題があります。 初期開発中のプログラムは変更することを意図していませんでした。 理由がわからない：彼らが考えなかったか、急いでいたかどうかは関係ない、結果がある。 このプログラムは、相互に大きく依存する多数のモジュールで構成されています。 1つのモジュールに小さな変更を加えると、他のモジュールは破壊されます。 おなじみですか？



これは深刻な問題ですか？



100行のプログラムがあるとします。 多かれ少なかれ資格のあるプログラマーは、その中に、非常に「重要な」変更さえ簡単に加えると思います。 そして、1日ではないにしても、2、3を超えない場合、ここで「変化」について議論するのはばかげています。



プログラムは1万行です。 タスクは簡単ではありませんが、試してみれば解決できます。



プログラムは100万行です。 ここではすべてが非常に複雑です。一生懸命プッシュして問題を解決できますが、すべてのコードを破棄して再度記述する方が高速で安価になることがあります。



もちろん、プログラムのサイズを「天井から」取りました。 すべてが変化の「重要性」と問題の軽視の程度に依存することは明らかです。 しかし、私たちは皆同じようなものに出くわし、誰もがプログラムの変更の複雑さがそのサイズとともに急速に大きくなることを想像しています。



したがって、私たちは皆、SOLID、そしておそらく他の同様の原則について知っています。 これらの原則を考慮してプログラムが最初から設計および開発された場合、プログラムの保守がはるかに容易になります。 非常に大規模なプログラムの場合、さらなるサポートを考慮して設計することが、一般的にその可能性の必要条件になります。



さて、セキュリティに戻りましょう。

安全なアーキテクチャと設計の原則

安全性には「堅実」があります。 私はこの声明があなたを驚かせるとは思わない：誰も（またはほとんどすべて）がこれらの原則の存在を知っており、このサイトの議論で定期的に言及されている。



これらの原則を思い出させてください。

• メカニズムのシンプルさ（メカニズムの経済）;
  
  
• フェイルセーフのデフォルト
  
  
• 保護の完全な浸透（完全な調停）;
  
  
• オープンデザイン
  
  
• 特権の分離;
  
  
• 最低特権
  
  
• リソース共有の最小化（最も一般的でないメカニズム）;
  
  
• 心理的受容性。
  
  

これらの原則は、約40年前の記事「 コンピューターシステムにおける情報の保護 」で策定されました。 今、彼らは彼らにさらにいくつかのルールを追加したい（ 例 ）が、事実はこれらの原則が長い間知られており、今日まで真実のままであるという事実である。 これらの原則に従って構築された成功したソリューションの例があります。



健康のために、安全のために人々のために自分でデザインするように思えます。



しかし、原則だけでは十分ではありません。 セキュリティの一般原則のみを知っている安全なシステムを構築することが可能です。 しかし、これは幾何学の問題の解決に似ており、その公理のみに依存します。 設計を効果的にするために、典型的なアプローチ、既製のソリューションを知ることは非常に役立ちます。



パターンを使用する必要があります。

安全なアーキテクチャと設計テンプレート

私たちの仕事では、繰り返しタスクが常に発生します。 各システム、各プログラムは、他の多くのものと多少似ています。 また、標準タスクには、標準ソリューション-テンプレートがあります。



テンプレートはその証明に適しています。 各テンプレートは経験から生まれたものであり、試行錯誤、改善、発見された問題の排除の結果です。 テンプレートを使用して、これがどのような結果をもたらすか、それがどのような利益をもたらすか、どの問題を戦わなければならないかを正確に予測できます。



プログラミングでは、設計パターンはよく知られています。 これらは、プログラムの設計で発生する問題のテンプレートソリューションです。 それらを使用することで私たちの生活は大幅に簡素化されます。私たちの前にタスクを標準のものにし、既存の明らかに動作するソリューションを適用する必要があります。 したがって、「4人組」の本は、プログラマーにとってほぼ必須の読み物です。



デザインはパターンに限定されません。パターンはすべてのレベルに存在します。 アーキテクチャテンプレート（少なくともMVCを思い出してください）、コードを記述するためのテンプレート、ユーザーインターフェイステンプレート、およびプログラムの動作用のテンプレートがあります。 ほとんどすべての新しいタスクには、独自のテンプレートソリューションがあります。



セキュリティには独自のテンプレートもあります。 テンプレートソリューションは、情報システムを構築するすべてのレベルに対応しています。 組織のセキュリティ対策を含む、企業全体のセキュリティテンプレートがあります。 純粋に技術的なエンティティとして情報システムを構築するためのパターンがあります。 安全なアプリケーションテンプレートがあります。



もちろん、アプリケーションのセキュリティパターンに関心があります。 ここでは、さまざまなレベルについて話すこともできます。安全な動作のパターンと、安全なプログラムの構造のパターンがあります。



プログラムのセキュリティは、多くの場合、その安全な動作に正確に関連付けられています。 たとえば、ユーザー認証、アクセス権の検証、入力データのフィルタリングが含まれます。 動作は、簡単に表示、テストできるものです。 そのため、マーケティング担当者は通常、セキュリティ機能のみを「販売」しています。



しかし、安全なプログラムの構造に読者の注意を引きたいと思います。 はい、それは影にあります。それは実証するのが難しく、販売するのが難しいです。



しかし、セキュリティは、プログラムの動作よりもプログラムの構造に依存しています。 エラーが発生する確率は、プログラムの構造によって異なります。 プログラムの構造によって、このエラーが脆弱性になるかどうかが決まります。 プログラムの構造により、この脆弱性の深刻度が決まります。 たとえば、重要なデータにアクセスするコードで、またはそのようなアクセス権を持たないコードで、どのエラーがより深刻な結果につながるかを考えてください。



あなたと私の説明なしで、プログラムのアーキテクチャとデザインの重要性を理解していると思います。 したがって、安全なプログラムの構造パターンに関する2つの出版物をお勧めします。



最初の出版物はSecurity Design Patterns（ pdf ）です。 私の意見では、これは安全なプログラムの構造パターンに関する最高品質の出版物の一つです。 ほぼ10年前、2004年にOpen Groupコンソーシアムによって公開されました。 この出版物には、テンプレートを使用してセキュリティを設計するための方法論と、それらの多くの説明の両方があります。



たとえば、保護されたシステムテンプレートの説明は非常に興味深いものです。 他の情報源では、「参照モニター」と呼ばれ、文献で頻繁に参照されています。 しかし、ほとんどの場合、言及されています。他のほとんどの出版物では、半ページの力で彼に捧げられています。 Open Groupの作業では、保護されたシステムテンプレートの使用が、使用可能なオプションを含め、非常に詳細に分析されます。



2番目の出版物は、「Secure Design Patterns」（ pdf ）です。 これは最近の情報であり、 Software Engineering Instituteで行われ、米国国防総省が後援した作業に関するレポートです。



SEIレポートは、公開時点で知られているセキュリティパターンのカタログです。 さらに、アーキテクチャテンプレート、デザインテンプレート、実装テンプレートの3つの異なるレベルのテンプレートが表示されます。 したがって、このトピックに関する非常に優れた情報源として作品を使用できます。



他の文献があります。 しかし、私の意見では、少なくとも最初は、言及された2つの情報源で十分です。 それらで利用可能な情報を把握したので、すでに非常に安全なプログラムを作成できます。



読んで、考えて、適用してください。

おわりに

単純なプログラムを安全にすることは非常に簡単です。 これを行うには、多くのことを考えたり計画したりする必要はありません。セキュリティに注意を払い、この記事の最初の部分で説明した安全なプログラミング手法を適用するだけです。



中複雑なプログラムの設計を考えると、時間とお金を大幅に節約でき、おそらくあなたの評判を維持できます。



高品質のアーキテクチャと複雑なプログラムの設計は、それを安全にする唯一の方法です。



次に新しいプログラムを計画するとき、または既存のプログラムをリファクタリングするときに考えてください。



PS記事は大きいことが判明しました。 私はそれを部分に分割し始めませんでした、私は本当にその完全性を維持したかったです。 おもしろいことを願っていますし、あまり負荷をかけなかったと思います。



ちょっとしたボーナスとして、この記事のトピックに関する文献のマイクロレビューを追加します。