ホームページ >ウェブフロントエンド >jsチュートリアル >JavaScript の一般的なセキュリティ脆弱性と自動検出技術_JavaScript スキル
はしがき
Web2.0 の発展と Ajax フレームワークの普及により、リッチ クライアント Web アプリケーション (リッチ インターネット アプリケーション、RIA) は日々増加しており、ますます多くのロジックがサーバー側からサーバー側に転送され始めています。これらのロジックは通常、すべて JavaScript 言語を使用して記述されます。しかし、残念なことに、開発者は一般に JavaScript コードのセキュリティにあまり注意を払っていません。 IBM X-Force 2011 中期傾向レポートによると、フォーチュン 500 の Web サイトおよび一般的に知られている Web サイトの 40% に JavaScript のセキュリティ脆弱性があります。この記事では、読者が日常のコーディング作業でこれらのセキュリティ脆弱性を回避できるようにすることを目的として、一般的な JavaScript セキュリティ脆弱性をコードと組み合わせて読者に示します。さらに、クライアント側の JavaScript のセキュリティ脆弱性の原則は、サーバー側のセキュリティの脆弱性の原則とは若干異なります。現時点では、JavsScript のセキュリティ脆弱性を自動的に検出することには大きな技術的困難があります。 IBM Rational AppScan Standard Edition V8.0 の新機能 (JavaScript Security Analyzer (JSA) テクノロジーは、JavaScript セキュリティーの脆弱性を自動的に検出します。
JavaScript の一般的なセキュリティ脆弱性
2010 年 12 月、IBM は Web アプリケーションにおけるクライアント側の JavaScript セキュリティーの脆弱性に関するホワイトペーパーを発表し、IBM セキュリティー研究所が実施した JavaScript セキュリティー状況調査を紹介しました。サンプル データには、フォーチュン 500 企業の Web サイトを含む 675 の Web サイトと、IT 企業、Web アプリケーション セキュリティ サービス会社、ソーシャル ネットワーキング サイトなどのその他の 175 の有名な Web サイトが含まれています。これらの Web サイトの通常の動作に影響を与えないようにするため、研究者らは、ログインなしでアクセスできるページのサブセット (サイトあたり 200 ページ以下) のみをスキャンする非侵入型のクローラーを使用しました。これらのページは保存され、研究者らは IBM の JavaScript セキュリティ分析テクノロジーを使用してこれらのページをオフラインで分析し、DOM ベースのクロスサイト スクリプティングとリダイレクトの脆弱性に焦点を当てました。
これらの有名な Web サイトの 14% には、JavaScript のセキュリティに関する重大な問題があり、ハッカーはこれらの脆弱性を利用して、不正なソフトウェアを埋め込んだり、フィッシング サイトを埋め込んだり、ユーザー セッションをハイジャックしたりする可能性があります。さらに驚くべきことは、IBM の JavaScript セキュリティ分析テクノロジーの成熟により、2011 年半ばの X-Force レポートでは、IBM が上記の有名な Web サイトを再テストし、さらに多くのセキュリティ脆弱性を発見したことを示しており、Web サイトの約 40% に JavaScript セキュリティが備わっていることです。脆弱性。
Java エンタープライズ レベルのユニバーサル パーミッション セキュリティ フレームワーク ソース コード SpringMVC mybatis または Hibernate ehcache hiro druid bootstrap HTML5
次の記事では、これらの一般的な JavaScript セキュリティ脆弱性をコードと組み合わせて読者に示し、読者が実際のコーディング プロセス中にこれらのセキュリティ問題に気づき、できるだけ早くリスクを回避できるようにします。
DOM ベースのクロスサイト スクリプティング
XSS (クロスサイト スクリプト、クロスサイト スクリプティング攻撃とも呼ばれる) については誰もが聞いたことがあるでしょう。これは、攻撃者が悪意のあるスクリプト コード (通常は HTML コードと JavaScript) を正規の Web ページ コードに挿入し、リクエストをサーバーに送信すると、サーバーの応答ページに攻撃者の悪意のあるスクリプト コードが埋め込まれ、攻撃者はこれらの悪意のあるスクリプト コードを使用してセッション ハイジャックなどの攻撃を実行する可能性があります。クロスサイト スクリプティングは通常、リフレクティブ タイプと永続タイプに分類されます。リフレクティブ クロスサイト スクリプティングは、リクエスト データがエンコードもフィルタリングもされずにサーバー応答ページにレンダリングされるときに発生します。永続的とは、悪意のあるコードを含むリクエスト データがサーバーに保存されることを指します。 Web アプリケーション。ユーザーが特定のページにアクセスするたびに、悪意のあるコードが自動的に実行されます。この種の攻撃は、Web2.0 タイプのソーシャル ネットワーキング サイトで特に一般的であり、その脅威も大きくなります。クロスサイト スクリプティングに対処するには、主に 2 つの方法があります。1 つは、ユーザー入力を一切信頼せず、ホワイトリスト テクノロジを使用して入力パラメーターを検証することです。2 つ目は、出力時にユーザーが提供したコンテンツをエスケープすることです。
しかし、3 番目のタイプのクロスサイト スクリプティングの脆弱性があることはほとんど知られていません。 2005 年に、Amit Klein は、DOM ベースのクロスサイト スクリプティングを明らかにしたホワイト ペーパー「DOM ベースのクロスサイト スクリプティングまたは第 3 種の XSS」(「DOM ベースのクロスサイト スクリプティングまたは第 3 種の XSS」) を発表しました。一部の HTML ページで document.location、document.URL、document.referer などの DOM 要素の属性が使用されている場合、攻撃者はこれらの属性を使用して、DOM を実装する悪意のあるスクリプトを埋め込むことができます。ベースのサイト スクリプティング攻撃。
以下では、非常に単純な HTML ページを通じて DOM ベースのクロスサイト スクリプティングの原理を示します。ユーザーのログイン成功を歓迎するメッセージを表示する静的 HTML ページがあるとします (リスト 1 を参照)。
リスト 1. DOM ベースの XSS を使用した HTML コード
<HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to our system … </HTML>
按照该页面 JavaScript 代码逻辑,它会接受 URL 中传入的 name 参数并展示欢迎信息,如清单 2 所示:
清单 2. 正常情况下的访问 URL
http://www.vulnerable.site/welcome.html?name=Jeremy
但如果恶意攻击者输入类似如下的脚本,见清单 3,该页面则会执行被注入的 JavaScript 脚本。
清单 3. 访问 URL 中注入脚本
很明显,受害者的浏览器访问以上 URL 的时候,服务器端会跟正常情况下一样返回清单 1 中所示 HTML 页面,然后浏览器会继续将这个 HTML 解析成 DOM,DOM 中包含的 document 对象的 URL 属性将包含清单 3 中注入的脚本内容,当浏览器解析到 JavaScript 的时候会执行这段被注入的脚本,跨站点脚本编制攻击即成功实现。
值得关注的是,通过以上示例可以看出,恶意代码不需要嵌入服务器的响应中,基于 DOM 的跨站点脚本编制攻击也能成功。可能某些读者会认为:目前主流浏览器会自动转义 URL 中的 '0b0d3c1d0eac9ad57b06cc87ca4baf9e' 符号,转义后的注入脚本就不会被执行了,基于 DOM 的跨站点脚本编制也就不再有什么威胁了。这句话前半段是对的,但后半段就不准确了。我们要意识到攻击者可以很轻松地绕过浏览器对 URL 的转义,譬如攻击者可以利用锚点 '#' 来欺骗浏览器,如清单 4 所示。浏览器会认为 '#' 后面的都是片段信息,将不会做任何处理。
清单 4. 访问 URL 中结合锚点注入脚本
通过 URL 重定向钓鱼
网络钓鱼是一个通称,代表试图欺骗用户交出私人信息,以便电子欺骗身份。通过 URL 重定向钓鱼指的是 Web 页面会采用 HTTP 参数来保存 URL 值,且 Web 页面的脚本会将请求重定向到该保存的 URL 上,攻击者可以将 HTTP 参数里的 URL 值改为指向恶意站点,从而顺利启用网络钓鱼欺骗当前用户并窃取用户凭证。清单 5 给出了较为常见的含有通过 URL 重定向钓鱼漏洞的代码片段。
清单 5. 执行重定向的 JavaScript 代码片段
<SCRIPT> … var sData = document.location.search.substring(1); var sPos = sData.indexOf("url=") + 4; var ePos = sData.indexOf("&", sPos); var newURL; if (ePos< 0) { newURL = sData.substring(sPos); } else { newURL = sData.substring(sPos, ePos); } window.location.href = newURL; … </SCRIPT>
これらの JavaScript スクリプトがリダイレクトの実行を担当しており、ユーザー入力に示されているように、新しいアドレスが document.location、document.URL、または document.referer などの DOM 要素の属性値からインターセプトされることがわかります。リスト 6.
リスト 6. リダイレクトを実行する URL
http://www.vulnerable.site/redirect.html?url=http://www.phishing.site
ユーザーがリスト 6 に示す URL を実行すると、フィッシング Web サイトにリダイレクトされるようです。この脆弱性の原理はシンプルで、サーバー側のリダイレクトの脆弱性よりも理解しやすいです。ただし、URL リダイレクトによるフィッシングの場合、フィッシング サイトの URL はサーバーによって傍受およびフィルタリングされないため、この脆弱性はサーバー側のリダイレクトの脆弱性よりも隠蔽されることがよくあります。
クライアント JavaScript Cookie リファレンス
Cookie は通常、Web サーバーによって作成され、クライアントのブラウザーに保存され、ユーザーの ID、セッション情報、さらにはクライアント上の認証情報を保存するために使用されます。クライアント側の JavaScript コードは Cookie データを操作できます。サイトの Cookie を作成または変更するためにクライアント側で JavaScript が使用されている場合、攻撃者はコードを表示し、コードを読んでロジックを理解し、さらにはその知識を使用して Cookie を変更することができます。 Cookie に権限情報などの重要な情報が含まれると、攻撃者はこれらの脆弱性を簡単に悪用して権限昇格やその他の攻撃を実行できます。
JavaScript ハイジャック
多くの Web アプリケーションは、Ajax のデータ転送メカニズムとして JSON を利用しています。これは通常、JavaScript ハイジャック攻撃に対して脆弱ですが、従来の Web アプリケーションはそれほど脆弱ではありません。 JSON は実際には JavaScript の一部であり、通常は配列形式です。攻撃者は、悪意のあるサイトのページ内の <script> タグを介して攻撃対象サイトの JSON 動的データ インターフェイスを呼び出し、JavaScript 関数フックなどのテクノロジを通じて JSON データを取得します。ユーザーが攻撃された Web サイトにログインし (ID 認証情報がセッション Cookie に基づいて保存されていると仮定します)、攻撃者によって悪意のあるサイトのページにアクセスするように誘導された場合、<SCRIPT src="> ; このタグを含むリクエストには Cookie 情報が含まれ、悪意のあるサイトは攻撃されたサイトに JSON データ取得リクエストを送信し、攻撃されたサイト サーバーは現在のリクエストを正当なものとみなして、現在のユーザーの関連する JSON データを返します。このプロセスは、オフサイトのクロスサイト リクエスト フォージェリ CSRF 攻撃 </script>
に相当します。Ajax のさらなる推進と HTML5 の段階的な適用により、クライアント側のセキュリティの脆弱性がさらに多くなるでしょう。現時点では、JavaScript に関するセキュリティ研究はあまり行われていません。新しくリリースされた HTML5 クライアント側ストレージ、クロスドメイン通信、その他の新機能もセキュリティに密接に関連しています。興味のある読者はさらに読んでください。著者の知識が限られているため、JavaScript 関連のセキュリティ脆弱性についてはあまり説明しません。次に、JavaScript のセキュリティ脆弱性の検出技術について説明します。
JavaScript のセキュリティ脆弱性の自動検出
ご存知のとおり、コードのセキュリティの脆弱性を検出するには、一般にホワイト ボックス インスペクションとブラック ボックス インスペクションがあります。ホワイト ボックス検査は、手動コード レビューまたは自動コード分析ツールによるコードの分析に焦点を当てています。ブラック ボックス インスペクションは主に侵入テストのためにハッカー攻撃をシミュレートします。一般に、ブラックボックス検査は精度が高くなりますが、コード カバレッジは小さくなりますが、ホワイトボックス インスペクションはコード カバレッジが高くなりますが、誤検知率が高くなります。 2 つの方法を組み合わせることで互いの欠点を補うことができ、ハイブリッド検査方法が将来のトレンドになるでしょう。
JavaScript コードに関しては、ブラウザー間の互換性や Ajax 機能要件の向上などの理由から、Dojo、JQuery などのサードパーティの JavaScript コード ライブラリに依存する Web アプリケーションがますます増えています。ファイル サイズを減らすために、これらのコード ライブラリはコードを圧縮することが多く、その結果可読性が非常に悪くなるため、手動でコードをレビューすることはほとんど不可能です。さらに、ページには JavaScript 呼び出しのエントリ ポイントが多数あるため、手動侵入テストは非常に労力がかかり、困難になります。したがって、JavaScript のセキュリティ脆弱性を検出するには自動テスト ツールの使用を推奨する必要があります。
Rational AppScan JSA の原則の簡単な紹介
JSA は、Rational AppScan Standard V8.0 の新しくリリースされた AppScan 拡張機能であり、静的 JavaScript 分析を実行して一般的なクライアント セキュリティの脆弱性を検出するために使用されます。 JSA は、JavaScript の静的汚染分析テクノロジーと Web サイトの動的クローラー テクノロジーを組み合わせたものです。つまり、AppScan は、クローラーによって探索されたすべての URL の完全な HTTP 応答を保存し、JSA はこれらの応答ページの JavaScript コードを 1 つずつ分析します。 JSA は、各ページを分析するときに、データ フロー分析と文字列分析という 2 つの段階を適用します。まず、JSA は、サニタイザーを通過していないソースからシンクまでのトレースを探します。このトレースが見つかった場合、JSA は文字列プレフィックス分析 (SPA) と呼ばれる文字列分析の変種を使用して 2 番目のステップでそれを検証します。 JSA テクノロジーは、完全に解析された HTML ページおよび DOM 環境のセキュリティ脆弱性を分析するため、純粋な JavaScript コードの静的分析テクノロジーと比較して、より高度かつ正確です。
今日の Web2.0 Web サイトや Ajax アプリケーションでは、HTML ページでは、ブラウザーがサーバー応答内の HTML および JavaScript コードに基づいて動的に解析して、完全な HTML および DOM を形成する必要があります。これは純粋に JavaScript コードに基づいています。静的汚染分析には明らかな欠陥があります。テストする JavaScript コードと実行環境は必ずしも完全ではないため、テストの正確性と包括性は保証できません。 JSA は上記の欠点を克服し、ホワイトボックス検出とブラックボックス検出の利点を組み合わせ、IBM の文字列分析テクノロジーを導入しているため、JSA はより優れた精度と包括性を備えています。
AppScan を使用して JavaScript のセキュリティー脆弱性を検出します
Altoro Mutual は、IBM が提供する Web セキュリティー脆弱性デモンストレーション Web サイトです。以下では、著者が AppScan JSA を使用してこの Web サイト内の JavaScript セキュリティー脆弱性を検出する方法を読者に示します。
AppScan を開始し、メニュー「スキャン - スキャン構成」をクリックしてスキャン構成ダイアログ・ボックスを開き、開始 URL を「http://demo.testfire.net」に設定します。
図 1. 開始 URL の設定
スキャン設定ダイアログの左側で [ログイン管理] をクリックし、右側の [記録...] ボタンをクリックしてログイン プロセスを記録し、セッション中に検出がアクティブであることを確認します。
図 2. ログイン方法の設定
スキャン設定ダイアログボックスの左側で、「テスト戦略」をクリックしてテスト戦略の設定を確認します。デフォルトのテスト戦略は「デフォルト」である必要があります。これには、一般的な JavaScript テストがすでに含まれています。「有効/無効」をクリックすると、現在デフォルトで有効になっているテスト戦略を表示できます。
図 3. テスト戦略の確認
スキャン設定ダイアログ ボックスを閉じ、[スキャン -- 探索のみ] メニューをクリックするか、ショートカット ボタン (図 4 を参照) をクリックして探索を開始します。この記事では、JavaScript のセキュリティ脆弱性を検出する方法のみを説明するため、クライアント側の JavaScript 分析テスト方法として「探索のみ」を選択してください。
図 4. 探索の開始
メニュー「ツール – 拡張機能 – JavaScript Security Analyzer」またはショートカット ボタン (図 5 を参照) をクリックして、「JavaScript の分析」を開きます。ポップアップの JavaScript Security Analyzer ダイアログ ボックスで、[今すぐ分析] をクリックします。
図 5. JavaScript の分析
JavaScript Security Analyzer のスキャンが完了すると、見つかったクライアント側の JavaScript セキュリティの脆弱性が結果リストにリストされます。下図に示すように、Altoro Mutual サイトには「DOM ベースのクロスサイト スクリプティング」および「オープン リダイレクト」の脆弱性が存在します。これらの脆弱性の詳細は以下のとおりです。
図 6. スキャン結果の表示
結果リストで「DOM ベースのクロスサイト スクリプティング」を展開し、最初の「JavaScript」質問をクリックすると、その詳細が下の質問情報に表示されます。 AppScan が JavaScript の問題コードの分析結果を保存し、黄色のマークでソース (Source) とシンク (Sink) を特定するため、開発者が脆弱性を迅速に修正できることがわかります。
図 7. DOM ベースのクロスサイト スクリプティングの問題情報
同様に、「Open Redirect」問題を展開して表示すると、この脆弱性のコード解析結果が問題情報列に表示されます。
図 8. リダイレクトの問題に関する情報を開く
注:
JavaScript のセキュリティ脆弱性を検出する方法を簡単に説明するために、この記事では「探索のみ」のクライアント側 JavaScript 分析テスト方法を選択します。実際の作業では、通常どおりにスキャンするだけでよいことをお勧めします (つまり、手動探索とサイトの自動探索を組み合わせて、テスト プロセス中に AppScan がデフォルトで JavaScript Security Analyzer を自動的に実行します)。
Rational AppScan Standard は既知の一般的な JavaScript セキュリティ脆弱性を検出できますが、Altoro Mutual は DOM ベースのクロスサイト スクリプティングとリダイレクトの脆弱性のみを示すため、このケースの結果リストには上記 2 つのセキュリティ脆弱性のみが含まれます。
結論
Java エンタープライズ レベルのユニバーサル パーミッション セキュリティ フレームワーク ソース コード SpringMVC mybatis または Hibernate ehcache hiro druid bootstrap HTML5
この記事では、JavaScript の一般的なセキュリティ脆弱性を紹介し、JavaScript コードを手動で検出する際の技術的な問題を分析します。 IBM Rational AppScan V8.x は、クライアント側の JavaScript セキュリティ検出ソリューションを提供する業界初の JSA 拡張コンポーネントを新たにリリースしました。この記事では、JSA の基本原則と技術的な利点を読者と共有し、事例を使用して IBM Rational AppScan JSA を使用してクライアント側の JavaScript セキュリティをテストする方法を読者に示します。
この記事には問題と限界がありますので、批判は歓迎です。私たちは一緒に学び、進歩することができます。