Webアプリのコードをオープンソース化することは推奨されていませんか？
ウェブサイトが組み込まれているプログラミング言語を見つける方法は？
所有者がデバッグモードをオフにするのを忘れた場合、Djangoアプリケーションはリバースエンジニアリングできますか？
そして、これらのような他のQ ^。
簡単に言うと、少なくともWebアプリの開発に関しては、攻撃者にできるだけ少ない情報を開示したいようです。
- 攻撃者は、Webアプリが実行されているプラットフォームを特定したいのですが、実際のプラットフォームとは異なるプラットフォームであると信じ込ませたいのです。
- 詳細な例外情報がアプリのソースコードの一部（プラットフォームではない）をリークする可能性があるため、デバッグモードをオフにすることをお勧めします。
Webアプリのサーバーコードをオープンソース化する場合は、私がリンクした質問がどのようにhide;そしてそれよりもさらに多くの情報。
したがって、アプリをオープンソース化することは、最後にしたいことの1つに思えます。
これは私にとって驚くべきことです。
- 友好的な目がコードを見て、悪用可能なバグを探し、パッチを提出するため、オープンソースアプリの方が安全だと考える人もいます。
- 前述の問題のためにアプリをオープンソース化しないのは、あいまいさによるセキュリティであり、これは悪いことです。
ただし、 @ Mason Wheelerのこのサイトへのコメント によると：
セキュリティテスターでさえ、サイトに組み込まれている言語がわからない場合は、どのエクスプロイトを試すか誰にもわからないため、サイトの安全性が高まると思います。 （はい、あいまいさによるセキュリティの有効なユースケースが時々あります。）
したがって、Webアプリのサーバー側コードをオープンソース化することは恐ろしい考えであることは同意されていますか？
賛否両論のある考慮すべきいくつかの側面があり、明確な答えがないかもしれないので、それは複雑な問題です。
オープンソースソフトウェアのセキュリティ上の利点は、ウィキペディアが「ライナスの法則」と呼んでいる「法則」に由来するはずです。これは、「十分な眼球があれば、すべてのバグは浅い」と述べています。まず、眼球がいくつあるか自問する必要があります。たとえば、プロジェクトは共有され、フォークされ、多くのユーザーによって広範囲に使用され、大規模なコミュニティによってレビューされますか？または、あなたのソフトウェアはあなたのウェブサイトでのみ使用され、他の誰もそれを気にしないでしょうか？それとも、無料のソフトウェアライセンスが付属していないため、他の誰もそれを再利用できないでしょうか？結局、ホワイトハットの眼球とブラックハットの眼球が存在することになるので、一方では倫理的なハッカーからセキュリティがある程度向上することを受け入れる必要がありますが、他方では攻撃されることになります。黒い帽子で。攻撃者は特にプロジェクトを標的とすることに関心がありますか、それとも非標的型攻撃の対象となるだけですか？これらはすべて考慮すべきことであり、結論を出すのは簡単ではないかもしれません。また、いくつかのオープンソースプロジェクトには、コミュニティの目を見張るものがあるにもかかわらず、長い間セキュリティの脆弱性が存在していたことも覚えておいてください（Wikipediaの Linusの法則 を参照）。
あいまいさによるセキュリティは、誤解されがちなもう1つの概念です。その名前から、何かを秘密に保つことがすべてのように聞こえるためです。そうではありません。あいまいさによるセキュリティは、セキュリティの重要な部分がメソッド（実装）。あいまいさによるセキュリティの例を次に示します。
// Login without password if URL has parameter dev=debug
// I'm a stupid dev, so I believe this is secure because nobody knows about it!
// But this source code can't be published or I'll be hacked at once
if ($login_password === $password || $_POST['dev'] === 'debug') {
login_ok();
}
とにかく、コードが正しく、セキュリティを設計に依存している場合でも、コードの上に難読化のレイヤーを使用することを妨げるものは何もありません。つまり、ソースコードを非公開にしておくと、潜在的な攻撃者の速度が低下するため、役に立ちます。覚えておくべき重要なことは、あいまいな部分は問題なく、優れたデザインの上にあるレイヤーである場合にのみ、優れた資産と見なすことができるということです。
結論として、理由がない限り（たとえば、ソフトウェアを無料/自由にして、プロジェクトの周りにコミュニティを作成したい場合を除いて）、ソースコードを公開しない方がいいと思います。アプリケーションのセキュリティを改善することが唯一の目的である場合、たとえばGitHubで公開するだけでは何も得られません。ソフトウェアに間違いが含まれているのではないかと本当に心配していて、「目玉」を追加して誰かに手伝ってもらいたい場合は、専門のセキュリティ監査にお金を払うことを検討してください。
私が文脈で書いたものを読むことは重要です。
はい、あいまいさによるセキュリティの有効なユースケースが時々あります。
これは、ブラックボックスシステムのペネトレーションテストに関する質問への回答として書かれたもので、ソースが利用可能であるという考えはテーブルにさえありませんでした。このような場合、あいまいさによるセキュリティは、ある程度の有用性を持つことができます。ただし、原則として、これは特に有用ではありません。有用な場合は、それは、より大きな多層防御戦略の単一の部分としてのみ有用です。ターゲットがどこにあるかわからない場合、攻撃することはできませんが、悪者が何を目指しているのかがわかったら、他の防御策も用意するか、攻撃を開始します。ことわざ小川。
また、この質問にもっと当てはまりますするソースコードを開く可能性を考慮します-ソースを非表示にすることで得られる利点は何でも Kerckhoffの原理 を大きく上回っています。「[常に想定している必要があります]敵はシステムを知っています。」言い換えると、敵が完全なソースコードを持っている場合にシステムを安全であると見なすことができない場合、その期間は安全であると見なすことができません。 （これは単なる常識です。ハードウェアストアがそれを非表示にして、人々がそれがどのような種類のロックであるかを見ないようにすることが重要であると言った物理的なロックにどれだけの信頼を置きますか？）
敵対者がシステムを知っているという仮定から始める場合、つまり、現実の世界では、攻撃者は他のハッキング、何らかの形のスパイ活動、またはその他のさまざまな妥協によってこの知識を獲得している可能性があることを意味します。コードは彼に新しいことを教えていません。それが行うことは、善良な人に追いつく機会を与えることです。あなたをハッキングしたり、セキュリティを危険にさらしたりすることのない正直な人々は、今すぐ見て、それがより良い場所を指摘するよう招待されます。
厳密にサイバーセキュリティの観点からすると、ソースを公開することは、あいまいさよりも明らかに勝者です。これを望まない理由は他にもあるかもしれませんが（ビジネス手法やその他の機密情報の保護）、ハッカーの侵入を防ぐのに優れているのはその1つではありません。
あいまいさによるセキュリティは悪いことではなく、信頼できるものではありません。何かを保護するための主な方法または唯一の方法であってはなりません。それは誤解を招くものであり、幻想である可能性があります。しかし、それでも他の方法に加えて、いくつかの価値があります。プラットフォームを知らないと、攻撃者の速度が低下したり、攻撃の可能性を逃したりする可能性があります。特に逆が当てはまるため、一般的な既知の脆弱性を次々と適用する事前に作成されたペンテストツールがあります。それらを公開するリスクがあるのはなぜですか？
多くの人々が実際にLinuxを使用しており、その機能の継続的で改善された機能に関心を持っているため、「友好的な目」のアプローチはLinuxで機能します。 Apacheや他のものと同じです。それはあなたのウェブアプリには当てはまらないでしょう。おそらく、誰もが自分のサイトに組み込む可能性のあるより一般的なフレームワークではなく、自社の特定の用途のためにWebアプリを開発しています。したがって、貢献者から利益を得ることはほとんどありません。
あいまいに！そして、他のすべての適切なものも。
コードの公開と、エクスプロイトによるアクセスからコードを保護しないことには、重要な違いがあります。
コードを公開すると、コードにアクセスできるブラックハット、グレイハット、ホワイトハットができます。ホワイトハットは発見した脆弱性を公開し、グレーハットはバグの報奨金が十分に大きければ公開する可能性があります。 Blackhatsは何があってもあなたをハッキングしようとし、公開されたコードはそれらを助けます。そのため、脆弱性が公開されることによって得られる利益と、攻撃者が脆弱性を発見する危険との間にはトレードオフがあります。しかし、そのトレードオフはしばしば出版を支持します。
コードがエクスプロイトによって発見された場合、そのコードにアクセスできるのは主にブラックハットです。この方法で脆弱性が発見された場合、責任を持って開示される可能性ははるかに低いため、このトレードオフが有利になる可能性はほとんどありません。
Digitalus CMS 2007-2012を含むいくつかのオープンソースプロジェクトを開発しました。 NPMのようなビルドツールができたので、特定のより一般的なモジュールを共有するアプローチを選択します。これは、知的財産権を主張することはほぼ不可能であり、最終的な実装を非公開にします。
このアプローチは、幅広いプロジェクトに簡単に採用でき、コアアプリケーションを保護しながら、コアライブラリに何千もの目を持つという利点があります。