AJAXは根本的に安全ではありませんか？
重複の可能性：
Ajaxを安全に行う方法は？
私の職場では、多くの人がAJAXは根本的に安全ではないと信じています。AJAXは他のページの読み込みとまったく同じように安全であると感じています。呼び出し/ページのコーディング方法。
AJAXに根本的なセキュリティ欠陥はありますか？ AJAXクラス（XMLまたはJSONに関係なく））の攻撃面は、標準の同期Webアプリケーションとどのように異なりますか？
短い答え：正解です。ページのコーディング方法によって異なります。
少し長い答え：
AJAXには本質的に安全でないものはありません。ほとんどの場合、AJAXは通常のWebページと同じ脅威や攻撃のほとんどに対して脆弱です。
ただし、AJAX固有の攻撃もいくつかありますが、これもコーディング方法によって異なります。しかし、それだけではありません"fundamentally insecure"。
ただし、多くの場合、別の微妙な問題が発生します。（ほとんどの）プログラマーは最終的に、Webページやブラウザーとサーバー間の通信で「隠された」ものはユーザーから保護されていない（ただし、グロッキングが主流になるには長すぎる）、それでもAJAX呼び出しは何らかの形で「特別」であるという一般的な概念です。したがって、これらはしばしば誤用されます...たとえば、私はまだすべての通常のページにSSLを備えた多くのサイトが表示されますが、実際の機密データは、暗号化されていないHTTPを介してAJAXを介して自由に流れます。
要するに、ある程度、あなたの騎士団の意見もここで部分的に誤りです-AJAXが何らかの形で「特別」であると期待しています）。
答えは、保護しようとしている資産と脅威モデルによって異なります。
ユーザーがWebページのコンテンツを攻撃していることとAJAXのコードを見つけて何かを発見することを心配している場合ユーザーに知られたくないページの場合、AJAXは安全ではありません。ユーザーがWebページが実行されている環境に物理的にアクセスできるためです。この例は、トーマスが他の回答の1つで説明しているゲームの例です。ページにゲームインターフェースが実装されており、他のプレーヤーの場所に関する情報が含まれている場合、ユーザーはそのすべてを把握し、「壁越しに見る」ことができます。
一方、ユーザーがサーバーを攻撃することを心配している場合、ユーザーがWebページおよび関連するコードのすべてを変更できると想定している場合、他の人が指摘しているように、適切な予防策を講じて、そのような状況下でユーザーが実行できることからサーバーを保護しますAJAXは、他の優れたプログラミング手法と同じくらい安全であり、 Update：しかし、そうするのは難しい場合があり、@ iivelが指摘しているように、OWASPページはさまざまなことを説明しています次の点に注意してください： AJAX脆弱性（OWASP-AJ-001） のテスト
これはすべて、FlashまたはJavaアプレットまたはSilverlightなど）のような他のクライアント側の手法に適用されます。実際、それはWordまたはPDF-そこに含まれているコンテンツ（ソフトウェアの作成者または所有者に関するメタ情報、またはデジタルホワイトアウトでオーバーレイすることによって「消去」されたコンテンツなど）は、人々に表示されないと思われるか、覚えていなかったそれが自動的に含まれるようになると、知識のあるユーザーがビットを見るときに悲しいことに失望するでしょう。
脅威モデルと、ツールが対応するかどうかについて慎重に検討することは非常に重要です。
AJAXは、「コードが含まれているWebページ-つまり私はそれを意味します」を意味します。 AJAXと「通常の」ページには明確な区別はありません。通常のページにもスクリプト要素が含まれている可能性があるためです。AJAXは、アプリケーションの一部をクライアントブラウザにプッシュするつもりです。
Webベースのアプリケーションは、サーバーとクライアントの結合で実行されます。次の理由により、クライアントにサーバーから送信されたページを表示するだけではなく、もう少し多くのことを実行させるのは魅力的です。
- インターフェイスの反応性が向上します（ユーザーエクスペリエンスが向上します）。
- ネットワークの負荷が軽減される場合があります（サーバーと通信せずに、クライアントで多くのGUIベースの操作を実行できます）。
- コンピューティングの負荷が軽減される場合があります（クライアントマシンの作業が増え、サーバーの作業が減ります）。
たとえば、オンラインゲームで類推できます。 FPSゲームで。数人のユーザーが互いに撃ち合います。サーバーは、誰がどこにいて誰が誰を殺したかを追跡します。このようなゲームでは、インターフェースの反応性が最も重要です。したがって、サーバーがすべてを計算し、フレームを送信してクライアントに表示することはまったく想像できません。代わりに、クライアントは重い3Dレンダリング作業を行う必要があり、サーバーはレベルマップとプレーヤーの位置の更新を送信するだけです。
この時点で、基本的なルールにより、セキュリティが機能します。
- サーバーの観点からは、クライアントは悪役です。
ゲームの類推では、これはサーバーがクライアントコードを信頼する必要があることを意味します。3Dレンダリングの場合、クライアントはレベルマップと他のすべてのプレーヤーの位置を知っている必要があります。変更されたクライアントにとって、プレーヤーにマップを表示し、他のプレーヤーを特定するのは簡単です。実際、そこには多くの詐欺師がおり、ゲームエンジンは高度なコード難読化手法を使用して、大多数の詐欺師を阻止しようとします（詐欺師は楽しみを殺し、プレイヤーが残した楽しみなしに）。
これは、AJAXセキュリティについてのことを示しています。これはクライアント側で実行されるコードであるため、ユーザーが正当に認証されていても（サーバーが信頼していない場合でも）、whoは、それを自動的に正当化しません。これは通常、GUI関連のインタラクションの問題ではありません-ゲームのアナロジーでの「レベルマップ表示」機能など、GUIに関するセキュリティの問題がない限り。 Webベースのアプリケーションのセキュリティを分析する適切な方法は、サーバーが発行するすべての1バイトがクライアントであると認識され、クライアントからのすべてのバイトが潜在的に悪意があると想定することです。
大まかな例として、SQLインジェクションを考えてみましょう。 SQLインジェクション攻撃を回避する1つの方法は、リクエストにプラグインするデータ要素にエスケープされていない特殊文字がないことを確認することです。この検証手順[〜＃〜] must [〜＃〜]はサーバーで実行する必要があります。 AJAXが行うことはすべてクライアントによってバイパスされる可能性があるため、AJAXで安全に行うことはできません。
OWASPには、この問題に関する優れた記事があります。 AJAXはより広い攻撃対象であり、AJAXアプリケーション（JSONハッキング、またはクライアントイベントハッキング）でのみ現実的に可能な攻撃）の主な問題。
AJAX脆弱性（OWASP-AJ-001）） のテスト
http://directwebremoting.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html
アプリケーションの非同期の性質、したがって必要なサービスによって、より多くの領域が攻撃を受けやすくなります。データ構造とイベントメソッド自体も、通常、ポストからのラウンドトリップよりも攻撃されやすい傾向があります。