LANからのみアクセス可能なWebアプリケーションは、一般にアクセス可能なWebサイトと同じセキュリティ基準に準拠する必要がありますか？
多くのセキュリティ対策は、ソフトウェアを悪用したり、アクセス権のないコンテンツにアクセスしたりする悪意のあるユーザーから保護することを目的としています。 CSRF保護、SQLi保護、TLSおよびその他の多くのセキュリティ機能のようなものは、主に悪意のあるユーザーから保護します。しかし、すべてのユーザーが信頼できる場合はどうでしょうか。
会社のイントラネット上でのみ実行され、外部からアクセスできない完全な内部Webアプリケーションがあるとします。すべての内部ユーザーが信頼できると想定し、外部ユーザーは存在せず、アプリケーション内部のデータは攻撃者にとってあまり役に立ちません。つまり、脅威モデルは非常に限定されており、機密データはそれほど多くありません。
これらの詳細を考慮すると、TLSやXSS保護などの一部の対策はそれほど重要ではないようです。結局のところ、攻撃者がトラフィックを傍受するリスクはほとんどなく、ユーザーはXSSペイロードを入力しないと信頼できます。この場合でも、トラフィックの傍受や悪意のあるユーザーに対するセキュリティ対策を実装することは理にかなっていますか？
はい。もちろん。
内部ネットワークに関する想定には問題があります。
- 攻撃者がネットワーク内のデバイスを制御することはないと想定しています。これは悪い仮定です（ http://www.verizonenterprise.com/verizon-insights-lab/dbir/ を参照）。 https://www.fireeye.com/current-threats/annual-threat-report/mtrends.html ）。攻撃者はネットワークの足がかりを得るためにかなりの時間を費やし、特定の企業内の侵害されたホストを購入するための商業市場があります。
- ユーザーだけがアクセス権を持っていると想定しますが、マネージドサービスプロバイダー、請負業者、臨時従業員などのサードパーティについてはどうですか？また、誰かが無線LANに侵入した場合はどうなりますか？または、有線ポートにアクセスします（例： pwnplug ）
より一般的には、どこにでも適用できる単一の標準を持つ方が確かに効率的であるのに、なぜ2セットの実践/標準があるのかという問題もあります。
BeyondCorpに関するGoogleの論文 https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/44860.pdf を読むと便利な場合があります。
Tl; drは、ネットワークの概念では、ユーザーとデバイスについてアサーションを作成しますが、ネットワークについてはアサーションを作成しません。主に、すべてのネットワークが敵対的であると仮定する方が、そうではありません（一部、ネットワークを安全であると誤って分類するコストは非常に高くなる可能性があります）。
そのようなアプローチの1つの考えられる理由は、Snowdenリークにより、ネットワークの安全性に関する以前の仮定が正しくなかったことが明らかになったことです。NSA（暗号化されていない時点で） DC間データフロー。
あなたの質問に対する基本的な答えは、セキュリティの境界/境界ポイントがネットワークのエッジではなく、ネットワーク上のデバイスであるということです。そのため、あるネットワークが別のネットワークよりも「優れている」と考えるのではなく、攻撃/不正行為のカテゴリの防止に焦点を合わせる方が、単純かつ現実的です。内部のDMZのような、外部の場合のような強力な制御は必要ないかもしれませんが、ネットワークが安全であると仮定することは危険な仮定です。
内部ネットワークと外部ネットワークの攻撃面は異なります。つまり、適切なセキュリティ対策が適切です。これは、内部ネットワークの攻撃面が小さくなることを意味するものではありません。一方のユーザーは通常より信頼され、もう一方のサイドには重要なデータがあり、内部からアクセスしやすいことが多いからです。
すべてのユーザーが信頼できる場合でも、システムがマルウェアに感染する可能性があります。 CSRF、SQLiまたはXSSのようなあなたが言及した多くの攻撃は別として、クロスオリジンで実行できます。つまり、内部ユーザーが外部Webサイトにアクセスして、内部ブラウザーをトランポリンとして使用して内部を攻撃するだけで十分です。システム。
つまり、すべてのユーザーを信頼できる場合でも、内部ネットワークにも適切な保護が必要です。これは、同じシステムから内部ネットワークとインターネットの両方にアクセスできる場合に特に当てはまります。これにより、内部システムに対するインターネットからのクロスオリジン攻撃が可能になります。
私はノーと言います、主に指定された元の投稿からのこの引用のため：
外部ユーザーは存在せず、アプリケーション内のデータは攻撃者にとってあまり役に立ちません
主な考慮事項は、内部ネットワークであっても、悪意のあるアクターがシステムを危険にさらして、Webアプリケーションへのアクセスに使用できることです。
あなたの脅威モデルはここでも重要な考慮事項であり、アプリケーションcanが侵入されるという懸念にもかかわらず、保護しているのがJoeの休日のスケジュールとSallyのパーティーへの招待だけである場合、 HSTS、HPKP、XSSフィルタリングなどを実装する価値があります。
ローカルマシンに感染するほとんどのマルウェアは、ネットワークスキャンを実行してイントラネットWebサーバーを見つけるようには設計されていない可能性があります。それらは、おそらく既知のパッケージを探すことになります（ただし、一部は一般的な名前を探し、既知のエクスプロイトで見つけることができるすべてのフォームを破壊します）
これはあいまいさによるセキュリティに似ており、間違いなく悪い習慣です。ただし、実際の懸念事項は、多くのシナリオで理想を上回ります。それでも、少なくとも自己署名証明書とHTTPS/TLSをお勧めします。
このようなシステムはできない標的型攻撃に耐えますが、最も一般的な攻撃対象（パブリックインターネットアクセス）を排除したため、自動悪用の大部分はサイトを検出しません。
優れた回答へのいくつかの追加：
xSSから保護するために行うべき多くのこと（表示時にデータを適切にエンコードすること）は、完全に無害な入力によって引き起こされる可能性のあるさまざまなバグを防ぐためにも必要です（テキストフィールドに間違った場所に
<または&が含まれているという理由だけで壊れている）。同じことがSQLインジェクションにも当てはまります（フィールドに引用符があるので、クエリが正義を壊したくない場合）。ですから、セキュリティのためではなくても、とにかくそうする必要があります。ブラウザーが非TLSサイトについてますます制限する傾向が強くなり、近い将来ブラウザーがまったく使用できなくなる可能性があります（または、少なくともユーザーを驚かせるほど多くの警告が表示される）。
また、内部ネットワークの内部ユーザーのみを対象としていて、ユーザーが完全に信頼されている場合でも（信頼できない理由については他の回答を参照）、将来状況が変わる可能性があります。サイト（の一部）を外部ユーザー（パートナー、サプライヤー、顧客など）に公開する必要がある場合があります。後でセキュリティを改造するよりも、最初の開発を行うときに適切な対策を取る方がはるかに簡単です。
脅威モデルを作成します。保存されているデータと特定した脅威に応じて、さまざまなセキュリティ標準が必要であるか、すべてを考慮すると、実際には重大な違いはないことがわかります。
一般的な言葉で質問に答えることは、あなたが与えられた答えですでに見ることができるように、とられた仮定に応じて、この方法またはそれをすることができます。しかし結局のところ、LANまたはパブリックインターネットはセット内の1つの変数にすぎず、与えられた変数の1つだけではx = y + zを解くことができません。