ブラウザがOSに似ているため、HTML5 / JavaScriptはFlash / Javaよりも安全ですか？
これをここに投稿するように依頼されました：
次の2つの異なるシナリオで、エンドユーザーのセキュリティに焦点を当てたいと思います。
1）アプリケーションなどがFlash経由でブラウザサンドボックスの外部のプラグインにあり、Javaインストールおよび有効化されている。
2）HTML 5とアプリケーションをブラウザのサンドボックスに移動して投稿することで、このデータとアプリケーションにアクセスするためにブラウザ環境に違反する必要がなくなり、HTMLを介してブラウザに直接渡されるカメラなどのシステムハードウェアにフックするブラウザーに組み込まれたJSアクセス可能なフックはそれ自体です。
サーバー側のセキュリティについて話しているのではありません。ブラウザー環境を実行するコアOSもありません。私はユーザーデータについて言及しています。ユーザーが攻撃から安全であることを重視している限り、ブラウザーはOSになります。
FLASHは安全ではない（そして安全ではない）とHTML 5のほうが安全である（しかし、それはそのままか？）すべてのデータとアプリケーションをブラウザに移動し、フックを追加して、WebページにJavaスクリプトと同じようにハードウェアを制御するFlashとJavaまたは、これらの機能を追加すると、同様のデータがブラウザに保存され、ブラウザに保存されているアプリケーションの制御が失われ、OSセットアップとしてブラウザがリモートでハッキングされる可能性がありますか？
これらの違反は理論的にはブラウザレベルに限定される可能性がありますが、ブラウザは事実上エンドユーザーにとってOSのようになるため、平均的なエンドユーザーはこれらの攻撃をFlashやJavaで見られるものと区別できますか？それとも、平均的なエンドユーザーと同じように認識されるのでしょうか？
あなたの質問は幅広いので、私はそれの一部に答えようとします。私の意見では、Webへの移行、Flashの無効化、およびJavaなどは、システム全体の安全性を向上させません。脆弱性と悪用を他の種類の攻撃にシフトするだけです。 OSレベルおよびアプリケーションレベル（バッファオーバーフローなど）での攻撃の場合、将来的にはクロスプラットフォームになる可能性のあるロジックおよび設計の問題がさらに発生します。
Webの現在のデザインは、デフォルトでは安全ではありません。 Webブラウザーのセキュリティコンテキストが統合されると、ブラウザーをトランポリンとして使用して、外部または類似のサイト（CSRF、DNS再バインドなど）から内部サイトを攻撃することが可能になります。 WebSockets、WebRTC、CORSなどの新しい機能はセキュリティを考慮して設計されていますが、基本設計の不安定さはそのまま残り、新しい機能は実際に攻撃面を攻撃する可能性があります。
データの転送（HSTS、HPKP）または特定の攻撃ベクトル（CSPによるXSS保護、またはブラウザーでのいくつかのアンチXSSヒューリスティック）に重点を置いて設計を強化しようとする試みであり、ほとんどの場合、Webアプリケーションが特に必要とするアドオンサーバー側でこの保護を有効にします。コンテンツセキュリティポリシー（CSP）は実際にはこの戦略の良い例です。サーバー側で明示的に追加する必要があり、アプリケーションを調整する必要があるためです。ただし、最終的には、CSPは、根本的な設計の問題に取り組む代わりに、データとコードのマージ（つまり、HTML内のJavaScriptインライン）の問題にセキュリティを追加しようとします。また、デフォルトではアプリケーションは安全でないため、CSRFのような攻撃も、CSRFトークンなどを使用してアプリケーションで明示的に説明する必要があります。
私の予想では、この設計上の不安は将来、この種の問題をより多くもたらすと思います。 CSRF、XSS、SQLインジェクション...は、この安全でない設計を利用するアプリケーション層攻撃とクロスアプリケーション攻撃です。そして、根本的な問題に取り組んでいない限り、より多くの問題が発生しますが、代わりにすべての開発者がこれらの問題を認識し、安全でない基本設計に基づいてアプリケーションを明示的に設計することを期待します。今日では、安全でないアプリケーションを書くことは簡単で、安全なアプリケーションを書くことは非常に困難です。通常何が得られるかは簡単に予測できます。
CP/M、DOS、Windows 3.1などでは、各アプリケーションに非常に広い権限があり、他のアプリケーションや基盤となるハードウェアに害を及ぼす可能性のある、以前はこのような安全でない設計がありました。これは、プロセスの分離、さまざまな権限を持つユーザーアカウント、DEP、およびその他の多くの手法を追加することで修正されました。これらは基礎となる設計への変更であり、OS内のすべてのアプリケーションのセキュリティを向上させました。 「ブラウザOS」では、現在、DOSまたはWindows 3.1と同じセキュリティレベルにあります。私たちが持っているWebアプリケーション間の唯一の種類の（弱い）分離は、同一生成元ポリシーであり、この種類の保護はXSSでバイパスすることにより簡単に行うことができます。残念ながら、今日の「ブラウザOS」は、Windows 3.1よりも危険な環境（インターネット）にさらされています。あまり壊さずにWebのデザインにセキュリティを組み込むのは難しい方法ですが、他に選択肢はないので、この方法を早く実行する必要があります。
私はOPからの反対投票、そしておそらくフラグを期待していることを言及することからこの投稿を開始したいと思います。なぜなら、この質問は実際には元々私の投稿をもたらした議論であった精巧なストローマンの一部であるからです this 質問。ここに入る必要はありません。しかし、私は確かに質問に答えます。 Steffenがかなり情報提供の答えを提供してくれたことにも注目したい。しかし、いくつかのことを明確にするために、それに追加したいと思います。
1）アプリケーションなどがFlash経由でブラウザサンドボックスの外部のプラグインにあり、Javaインストールおよび有効化されている。
上記の質問へのリンクで提供されている優れた回答を表示することで、少なくともいくつかの事前コンパイルを必要とするFlashなどのテクノロジーと比較して、HTML/JavaScriptなどのインタープリター型言語を使用することの全体的なエンドユーザーセキュリティの利点を明確に見ることができます。それは私にもたらします：
2）HTML 5とアプリケーションをブラウザのサンドボックスに移動して投稿することで、このデータとアプリケーションにアクセスするためにブラウザ環境に違反する必要がなくなり、HTMLを介してブラウザに直接渡されるカメラなどのシステムハードウェアにフックするブラウザーに組み込まれたJSアクセス可能なフックはそれ自体です。
ここで強調したいのは、JavaおよびFlashを介して検出および利用される脆弱性は、アクセスできる実際の機能やシステムリソースとはほとんど関係がないということです。コンパイルと実行の間にコードを変更する可能性に関しては、さらに多くのことを行います。また、最新のJavaScriptサンドボックス実装は優れており、継続的に改善されていることを指摘したいと思います。Node.jsは、ドキュメントにメソッドを提供し、完全に活用することもできますJavaScriptサンドボックスの個別のコンテキスト。すべて単一のマスタースクリプトで完全に制御可能です。私はそれを自分で使用しました。ドキュメントは here であり、独自の安全なサンドボックスを簡単に作成できることを証明しています（少なくともHTML/JSベースのアプリ）。
さて、これらのサンドボックスは克服できないとは決して言いません。サンドボックス内のアプリとやり取りするソフトウェアは、実行中のすべてのジョブに対して信頼される必要があり、チェーンタイプの最も弱いリンクのようなものです。ただし、近未来のWebOS向けのアプリは、最近のブラウザープラグインやアドオンと同じように機能すると思います。彼らは通常、通常のウェブページよりもはるかに多くのシステムへのアクセス権を与えられますが、同じように解釈された言語ベースのテクノロジーで機能します（Javaなどの「ネイティブ」と見なされない限り）またはFlash。この場合、コンピュータへのアクセスが大幅に増加します）。
サーバー側のセキュリティについて話しているのではありません。ブラウザー環境を実行するコアOSもありません。私はユーザーデータについて言及しています。ユーザーが攻撃から安全であることを重視している限り、ブラウザーはOSになります。
Java/Flashのエクスプロイトは、ファイルが実行される前にプリコンパイルされたコードを変更することでクラッシュを引き起こす方法が非常に多いため、一般的です。クラッシュは、アプリケーション内で不正なメモリが参照されるか、正当なメモリが実行されたが、破損しているか、実行可能形式ではない場合に発生します。非公式のコンパイラは、これを偶然に発生させることさえあります。このタイプの欠陥を利用してエクスプロイトを生成することは、通常、スキルと時間の問題のみです。その終わりまでに、アプリはクラッシュする必要さえありません。
逆に、コンパイルと実行の段階の間でJavaScriptコードを変更することは絶対に不可能です。これにより、Flashで利用されているエクスプロイトやJavaをJavaScriptで再現することは本質的に不可能になります。JavaScriptファイルのバイナリを悪意を持って変更して、解釈方法を利用することは不可能になり、不規則性がコンパイラによって構文エラーとして検出されるという事実に対応します。ファイルの内容全体は、言語自体の構文に基づく厳密な規則に従う必要があります。そうでない場合、1行では実行されません。 Java/Flashに関連付けられているファイルなど、事前にコンパイルされたファイルやバイナリファイルは、開発者のマシンのコンパイラによって代わりにチェックされるため、チェックは実行できません。クライアント（エンドユーザー）には、そのような保護はありません。
ただし、コンパイルされた言語は、インタープリター型言語と同じタイプのセキュリティ欠陥のすべてに悩まされていることに注意することが重要です。そうは言っても、未承諾のWebサイトがシステム上で任意にコードを実行できるようにするソフトウェアには、本質的にリスクが伴うことも明確にしたいと思います。セキュリティコンテキストでは、ルール1は、必要な機能に影響を与えずにリスクをできるだけ最小限に抑えることです。システムで任意のコードを実行させる脆弱性がFlashに見つかった場合は、システムの侵害と考えられます。 Flashの脆弱性の多くはこのカテゴリに該当します。これは、先に説明したように、プリコンパイルされたコードが抱える固有のセキュリティ上の欠陥です。将来のWebベースのOSでは、任意のコード実行よりもXSSおよびCSRFの脆弱性（システムの侵害とは必ずしも見なされない）について心配することになるので、（もしあれば）はい、HTML5と言っても安全だと思います/ JavaScriptはより安全になります。
免責事項：Webベースのオペレーティングシステムが実際に有効になった場合、現在と将来の間に外部の力が答えを複雑にする可能性があります。これは、完全に解釈された言語と完全に解釈されていない言語の背後にある固有のセキュリティモデルに関する私の現在の知識に関してのみ述べています。エンドユーザーのセキュリティに関して互いに比較し、それが質問されました。これには、Webベースのオペレーティングシステムを使用するようになった場合に、技術的に言えばほとんど変化しないという仮定に基づく理論的な見解が含まれています。