［さらに気になる］JSONの守り方：教科書に載らないWebアプリケーションセキュリティ（5）（1/3 ページ）
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部）
次は、JSONにおけるセキュリティ対策
皆さんこんにちは、はせがわようすけです。第4回「［気になる］JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。
JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。
まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
では、JSONにはどのような注意点があり、どう対策すればいいのかを見ていきましょう。
JSON内の機密情報
JSONは、そのままではクロスドメインでのデータの受け渡しができません。そのため、JSONを加工してクロスドメインでも扱えるようにしたものが「JSONP」であるというのは前回説明したとおりです。
クロスドメインでのアクセスができないのであれば、JSONに機密情報を含めても問題なし……と考えたいところですが、攻撃者はあらゆるクロスドメイン制約を打ち破ることを常に考えています。実際に、JSONのクロスドメイン制約についても回避する方法がいくつか考えられています。
JSONのクロスドメイン制約を回避する攻撃方法としては、例えば__defineSetter__を使う方法や、UTF-7を使う方法などが知られています。具体的な攻撃方法の詳細は省略しますが、いずれの方法でも、JSONを攻撃者サイト上で<script>要素を使ってJavaScriptソースとして読み込むことで、Same Origin Policyを回避し、攻撃者の用意したJavaScriptから、JSON内のデータへのアクセスを可能にしています。
XMLHttpRequestを使って、正規のWebアプリケーションのみJSONを読み込めるようにし、攻撃者サイトからの<script>によるJavaScriptソースとしての読み込みを防ぐためにはいくつかの方法があります。その場合、POSTのみに対応し、GETでのリクエストではJSONを返さないという対策をお勧めします。これは、ほかの方法に比べ副作用が小さく、後に示すJSONによるXSSへの対策にもなるからです。
それ以外の対策としては、XMLHttpRequestからのリクエストを明示するヘッダを付与するという方法もあります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
XMLHttpRequestによる正規のアプリケーションからの要求では、X-Request-Sourceリクエストヘッダが付与されますが、<script>などによる読み込みではヘッダが付与されません。サーバ側でリクエストヘッダの有無を確認し、正規の要求の場合のみJSONを返すようにします。
JSONによるXSS
前回解説したJSONPの場合と同様に、JSONデータ内にHTML断片が含まれる場合、JSONに直接ブラウザでアクセスしたときにXSSが発生する可能性があります。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このようなJSONをInternet Explorer（以下、IE）で直接開いた場合には、その内容からHTMLと判断され、攻撃者の仕組んだJavaScriptが動作する可能性があります（この例ではalertが表示されます）。
【Content-Typeに関する参考】
教科書に載らないWebアプリケーションセキュリティ（2）
［無視できない］IEのContent-Type無視
http://www.atmarkit.co.jp/fcoding/articles/webapp/02/webapp02a.html
対策としても前回同様、文字列を生成する場合には、半角英数字（a-zA-Z0-9）以外の文字はすべて\uXXXXの形式でエスケープし、文字列以外のtrue／false／null／数値を生成する場合には指定された値および数値などに合致しているか確認すればよいでしょう。
また、前述のようにPOSTのみに対応し、GETでのリクエストではJSONを返さないようにしておくことで、万が一エスケープ漏れがあった場合でもXSSを防ぐことができます。
Copyright © ITmedia, Inc. All Rights Reserved.