今日こそわかる、安全なWebアプリの作り方2010

[S3]今日こそわかる、
安全なWebアプリの作り方2010

HASHコンサルティング株式会社
徳丸浩
Twitter id: @ockeghem

Copyright © 2008-2010 HASH Consulting Corp. 1

アジェンダ
• 本日の構成
– 脆弱性の分類
– Webアプリの構造と脆弱性の原因箇所
– 「入力」では何をすればよいのか
– SQLインジェクション対策の考え方と実際
• 原理の話（グローバル）
• 文字コードの話（グローバル&ローカル）
– ケータイWebアプリのセキュリティ（ローカル）
• 議論の焦点
– Webアプリケーションのセキュリティ施策の考え方
– グローバル v.s. ローカル
– 対策の歴史とあるべき姿


徳丸浩の自己紹介
• 経歴
– 1985年京セラ株式会社入社
– 1995年京セラコミュニケーションシステム株式会社(KCCS)に出向・転籍
– 2008年 KCCS退職、HASHコンサルティング株式会社設立
• 経験したこと
– 京セラ入社当時はCAD、計算幾何学、数値シミュレーションなどを担当
– その後、企業向けパッケージソフトの企画・開発・事業化を担当
– 1999年から、携帯電話向けインフラ、プラットフォームの企画・開発を担当
Webアプリケーションのセキュリティ問題に直面、研究、社内展開、寄稿などを開始
– 2004年にKCCS社内ベンチャーとしてWebアプリケーションセキュリティ事業を立ち上げ
• その他
– 1990年にPascalコンパイラをCabezonを開発、オープンソースで公開
「大学時代のPascal演習がCabezonでした」という方にお目にかかることも
• 現在
– HASHコンサルティング株式会社代表 http://www.hash-c.co.jp/
– 京セラコミュニケーションシステム株式会社技術顧問 http://www.kccs.co.jp/security/
– 独立行政法人情報処理推進機構非常勤研究員 http://www.ipa.go.jp/security/

Copyright © 2010 HASH Consulting Corp. 3

脆弱性の分類

• 元々セキュリティと無関係なバグが脆弱性となるもの
– SQLインジェクション
– クロスサイト･スクリプティング
– OSコマンドインジェクション
– HTTPヘッダインジェクション
• セキュリティの考慮不足
– ディレクトリ・トラバーサル（アクセス制御不足）
– クロスサイト・リクエストフォージェリ（画面遷移のチェック洩れ）
– 認証の不備
– 認可の不備
• 狭義の脆弱性ではないもの
– HTTPSを使っていない
– ファイアウォールがない
– パスワードをデータベース上で暗号化していない


Webアプリの構造と脆弱性の原因箇所


対策の考え方の変遷

• 第1段階：攻撃手法に着目し、攻撃の手段を封じるアプローチ
– キーワード：サニタイジング
– メタ文字「<」や「’」、「;」に着目
– 「危険な文字」として、入力から削除してしまう
• 第2段階：脆弱性が生まれる根本原因に注目し、原因をつぶす
– キーワード：サニタイズ言うなキャンペーン
– メタ文字はエスケープするアプローチ
– メタ文字に頼らない記述ができればベスト
• Prepared Statement、DOM、シェルを通さない外部コマンド起動
– 「安全なウェブサイトの作り方」にまとめられる
• 第3段階：ミドルウェアの組み合わせを考慮した現実的な書き方
– キーワード：安全なSQLの呼び出し方
– バインド機構を使っていてもSQLインジェクション脆弱性が混入する…
– →なぜ脆弱性が混入するのか、どうすれば安全なのか


入力値検証ではなにをすべきか?

• 入力値検証はセキュリティのためにするのではない
• 入力値検証は「要件」に従うかどうかのチェック
– 電話番号例:099-9999-9999
– メールアドレス例： foo@eaxmple.jp
– 氏名例：鈴木一朗
• 文字種と文字数のチェックが一般的
• 入力値検証ではSQLインジェクションなどの対策はできない
– 「‘ union select a,b,c 」などを常にエラーにできるわけではない
– 現実問題「 O‘reilly」、「O’brien」など、アポストロフィつきの名前は珍しくな
い
• 入力値検証は「保険的対策」としては有効
– 本質的な対策が洩れた場合のセーフティネットとして（運が良ければ）
– 制御文字（メタ文字ではない）による攻撃への防御
– 文字コードの問題への対策（但し入力値検証だけでは不十分）


入力値検証の正規表現の具体例

チェック内容正規表現
数字1文字以上，8文字以下 /¥A[0-9]{1,8}¥z/
英字0文字以上，10文字以下 /¥A[a-z]{0,10}¥z/i
「F」または「M」 /¥A（F|M）¥z/
制御文字以外100文字以下 /¥A¥P{Cc}{0,100}¥z/
制御文字以外100文字以下
/¥A[¥t¥r¥n¥P{Cc}]{0,100}¥z/
ただし，改行とタブは認める

• 「制御文字以外」という正規表現は¥P{Cc}と書ける
• PHPのmb_eregの場合は [[:^cntrl:]]
• 文字列の先頭末尾は ¥A と ¥z で指定すること。^と$は「行」の先頭・末尾
• $は行末の改行にマッチするので、特に注意
• M文字以上、N文字以下は、{M,N}で指定（量指定子）


入力値検査をしなかった場合の問題

• アプリケーションの処理が進んだ後でエラーになると、データベー
スの不整合などを起こしやすい
– 例：数値であるべき項目に、英字や記号が入っているケース
• 制御文字による攻撃
– ヌルバイト攻撃（ヌル文字）
– メールヘッダインジェクション（改行）
– HTTPヘッダインジェクション（改行）
– 入力値で対策するのはおかしいが、保険的にやっておくとよい
• 壊れた文字コードによる攻撃
– 半端な先行バイトによる攻撃
– UTF-8の非最短形式
– 文字コードの不正は、処理を継続するべきでないので、入力検証で対策す
る合理性がある


制御文字による攻撃例（ヌルバイト攻撃）

XSS脆弱なサンプル

攻撃例:p=1%00<script>alert(document.cookie)</script>


インジェクション系脆弱性対策は出力時のエスケープ

• SQLインジェクション
– Prepared Statement（メタ文字を不要にする）
– Quoteメソッドにエスケープ
• クロスサイト･スクリプティング(XSS)
– HTMLメタ文字のエスケープ
– JavaScriptの動的生成を避ける
• OSコマンド・インジェクション
– 外部コマンドの呼び出しを避ける
– シェル経由で外部コマンドを呼び出さない
• HTTPヘッダインジェクション
– HTTPヘッダ生成に高レベルのAPIを使う
– 改行文字のチェックを行う
• メールヘッダインジェクション
– メール生成にsendmailコマンドを呼ばず高水準のAPIを使う
– 改行文字のチェックを行う

正しくないSQLインジェクション対策の今昔


正しくない例1(2001年)

正しい

これは余計

でもこれは
2001年の記事だから…
実践! セキュアなWebプログラミング日経オープンシステム2001年5月号から引用



???

これは無意
味

Billy Hoffman、Bryan Sullivan著、GIJOE監訳、渡邉了介訳「Ajaxセキュリティ」、毎日コミュニケーションズ、2008年、P113より引用

• このような方法では効果が薄いだけではなく、ケースバイケーズで正しい方
法を考えなければならない点が問題
• 脆弱性対策は、もっと機械的に適用できるものでないと実用的でない


【前提1】
・Webアプリケーションは文字列を入力として受理できるパーセントエンコー
・リレーショナル・データベース管理システムと連携ドをデコードしてか
らでないと無意味
【入力の例】
DECLARE%20@S%20NVARCHAR(4000)SET%20@S=hogehoge EXEC(@S)
・文字列として入力
・特殊文字を文字として扱うために「¥」を挿入むやみに「¥」を
・「;」は削除セミコロンを勝手挿入しても…
【入力値チェックの結果】に削除しないで!
DECLARE¥%20@S¥%20NVARCHAR¥(4000¥)SET¥%20@S¥=hogehoge EXEC¥(@S¥)

【前提2】
・SQLクエリーはアプリケーションで生成
・SQL構文に用いるような文字列はユーザーの入力としてはありえない意味不明
【入力の例(入力値チェックの結果)】
DECLARE¥%20@S¥%20NVARCHAR¥(4000¥)SET¥%20@S¥=hogehoge EXEC¥(@S¥)
・SQL構文に用いられる代表的な文字列をフィルタリングして削除
・アットマーク(@)はデータベース上で変数の識別子やスクリプト
の実行に用いられることがあるため削除
サニタイズ!!
【サニタイジングの例】
¥%20S¥%20¥(4000¥) ¥%20S¥=hogehoge ¥(S¥)

被害が続くSQLインジェクション攻撃，もう一度対策を見直そうより引用
http://itpro.nikkeibp.co.jp/article/COLUMN/20080514/301660/

なぜ誤った解説がなくならないのか

• 攻撃方法からの発想
– 攻撃に使用する文字・文字列を削除・改変するアプローチ
– いわゆる「サニタイズ」
– 脆弱性が混入する根本原因からのアプローチではない
• 実はアプリケーションなんか書いた人が説明している?
– セキュリティのプロが全員アプリケーションを書けるとは限らない
• そのサンプルコード、動かしてみた?
– でもテスト環境構築するだけでも大変だしぃ
• コピペの悪弊
– 昔の間違った解説が延命されられる

みんな攻撃が大好きだww


処理系のバグ（不適切な仕様）を避ける目的も…（過去の話題）
問題は、このプログラムではユーザ入力データをそのままSQL文の中に入れていることだ。
ここで例えば下記のようなデータをフォームに入力したとしよう。

|shell("cmd /c echo aaa > c:¥test.txt")| (注: "|" は縦棒文字)

このプログラムは以下のSQL文をJetデータベースエンジンに投げる。

select * from Customers where City='|shell("cmd /c echo aaa > c:¥test.txt")|‘

Jetは縦棒文字(|)で囲まれた部分をVBAスクリプトだと解釈するので、VBA Shell()関数を
呼び出す。すなわち、サーバ上で cmd /c echo aaa > c:¥test.txt が実行されることになる。
このサンプルプログラムでは単純に City=‘word’ という検索条件だが、City like ‘%word%’
というような検索条件であったとしても、入力文字列を巧妙に工夫することによりJetに
Shell関数を呼び出させることは可能である。

セキュリティ勧告 - NTサーバ上におけるJetセキュリティ問題
http://www.trusnet.com/advisories/jetshell/jetshell.txt より引用

• 昔のJetデータベースエンジンでは、文字列リテラル中のパイプ記号「|」に
VBAスクリプトを呼び出す機能があった
• しかも、パイプ記号をエスケープする手段が提供されていなかった
• 不適切な仕様だが、現在では改修されている

【参考】なぜセミコロン「;」を削除したがるのか?

• 実はセミコロンの削除には実効的な意味はあまりない
• セミコロン削除の意図は、複文実行の防止と思われる
– SELECT * FROM XXX WERE ID=’’;UPDATE XXX SET …
• SQLインジェクションの文脈で複文が実行できるのは、MS SQL
とPostgreSQL
• 現実にMS SQLは、複文を使った改ざん事件が多発
• しかし、MS SQLは、セミコロンなしでも複文が書ける
– SELECT * FROM XXX WERE ID=’’UPDATE XXX SET … でもよい
• すなわち、セミコロンの削除で保険的にせよ意味があるのは、
PostgreSQLの場合だけ

続きはWebで http://www.tokumaru.org/d/20080502.html
http://www.tokumaru.org/d/20080627.html


SQLインジェクション対策の考え方


そもそもなぜSQLインジェクションが発生するのか?

• 原因は、リテラルとして指定したパラメータが、リテラルの枠をは
み出し、SQLの一部として解釈されること
• 文字列リテラルの場合
– シングルクォートで囲まれた(クォートされた)範囲をはみ出す
SELECT * FROM XXX WHERE A=’’OR’A’=A’
• 数値リテラルの場合はみ出した部分
– 数値でない文字(空白、英字、記号など)を使う
SELECT * FROM XXX WHERE A=1OR TRUE


エスケープは檻にしっかり入れるイメージ
• 檻に入っている分には、中身の「危険性」を気にする必要なはい
• 危険性がなくても、檻から出てしまうのはバグ

select * from animals whre kind=' '

「危険な文字・文字列」 ; | ' @ declare
union xp_cmdshell @ ...


SQLインジェクションは檻から逃げるイメージ
• パラメタがリテラルからはみ出し、SQL文の命令として解釈される
状態

select * from animals whre kind=' '

「危険な文字・文字列」 ; | ' @ declare
union xp_cmdshell @ ...


SQLインジェクション対策の実際


SQLの呼び出し方

SQLに動的な変数を埋め込む方法には2種類ある
(1)文字列連結によるSQL文組み立て

$name = ...;
$sql = "SELECT * FROM employee WHERE name='" . $name . "'";

※ $nameをエスケープしていないのでSQLインジェクション脆弱性あり

(2)プレースホルダによるSQL文組み立て

PreparedStatement prep = onn.prepareStatement(
"SELECT * FROM employee WHERE name=?");
prep.setString(1, “山田”);

※ プレースホルダには2種類ある（静的・動的）


静的プレースホルダ

安全なSQLの呼び出し方より引用 http://www.ipa.go.jp/security/vuln/websecurity.html

•SQLとパラメータは別々にサーバーに送られる SQLインジェクション脆弱性の可
•パラメータ抜きでSQLは構文解析される能性が原理的になくなる
•パラメータは後から割り当てられる


動的プレースホルダ

安全なSQLの呼び出し方より引用 http://www.ipa.go.jp/security/vuln/websecurity.html

• SQLとパラメータは呼び出し側で、エスケープ、ライブラリにバグがなければ、
連結される SQLインジェクション脆弱性は発
• データベースサーバー側は、組み立てられた生しない
文字列をSQLとして実行するだけ

SQLの組み立て方とSQLインジェクションの可能性の関係

• 文字列連結による組み立ては、アプリケーション開発者の無知や
不注意によりSQLインジェクション脆弱性の可能性がある
• 動的プレースホルダは、ライブラリのバグによりSQLインジェクシ
ョン脆弱性の可能性がある（詳細はデモで）
• 静的プレースホルダは原理的にSQLインジェクション脆弱性の可
能性がない


文字列連結によるSQL組み立てを安全に行うには

• 文字列連結によるSQL組み立て時のパラメータの要件
– 文字列リテラルに対しては、エスケープすべき文字をエスケープすること
– 数値リテラルに対しては、数値以外の文字を混入させないこと
• 意外に面倒
– データベースによってエスケープすべきメタ文字が異なる
– オプションによってもエスケープすべきメタ文字が異なる
• Perl、PHP等ではquoteメソッドが便利
– Perl DBI
– PHP Pear::MDB2、PDO
• quoteメソッドはデータベースの種類や設定に応じたエスケープを
してくれる…はず
• 例外（バグ?、仕様?）もある


【参考】商用RDBMSの文字列リテラルの定義
• Oracle:cは、データベース・キャラクタ・セットの任意の要素です。リテラル内の
一重引用符（‘）の前には、エスケープ文字を付ける必要があります。リテラル
内で一重引用符を表すには、一重引用符を2つ使用します。
http://otndnld.oracle.co.jp/document/products/oracle10g/102/doc_cd/server.102/B19201-02/sql_elements.html#41297

• DB2:ストリング区切り文字で始まりストリング区切り文字で終わる文字のシー
ケンス。この場合のストリング区切り文字はアポストロフィ (‘) です。【中略】文
字ストリング内で 1 つのストリング区切り文字を表したいときは、ストリング区
切り文字を 2 つ連続して使用します。
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.sql.ref.doc/doc/r0000731.html

• MS SQL:単一引用符で囲まれた文字列に単一引用符を埋め込む場合は、単
一引用符を 2 つ続けて並べることで 1 つの単一引用符を表します。
http://technet.microsoft.com/ja-jp/library/ms179899.aspx


【参考】 MySQLの文字列リテラルの定義
8.1.1. 文字列
一部のシーケンスは、個々の文字列内で特別な意味を持ちます。これらのシーケンスは、いず
れも、エスケープ文字として知られるバックスラッシュ（‘¥’）で始まります。MySQLでは、次のエ
スケープシーケンスが認識されます。

文字列に引用符を含める方法は、いくつかあります。
•‘’’で囲んだ文字列内で、‘’’を使用する場合、‘’‘’と記述することができます。【後略】

「MySQL :: MySQL 5.1 リファレンスマニュアル :: 8.1.1 文字列」から引用
http://dev.mysql.com/doc/refman/5.1/ja/string-syntax.html

【参考】 PostgreSQLの文字列リテラルの定義
4.1.2.1. 文字列定数
SQLにおける文字列定数は、単一引用符（‘）で括られた任意の文字の並びです。
例えば、’This is a string‘です。文字列定数内の単一引用符の記述方法は、2つ
続けて単一引用符を記述することです。
【中略】
エスケープ文字列の中では、バックスラッシュ文字（¥）によりC言語のようなバック
スラッシュシーケンスが始まります。バックスラッシュと続く文字の組み合わせが
特別なバイト値を表現します。 ¥bは後退（バックスペース）を、¥fは改頁を、¥nは
改行を、¥rは復帰（キャリッジリターン）を、¥tはタブを表します。また、¥digitsという
形式もサポートし、digitsは8進数バイト値を表します。 ¥xhexdigitsという形式で
は、hexdigitsは16進数バイト値を表します。（作成するバイトの並びがサーバの
文字セット符号化方式として有効かどうかはコード作成者の責任です。）ここに示
した以外のバックスラッシュの後の文字はそのまま解釈されます。したがって、バ
ックスラッシュ文字を含めるには、2つのバックスラッシュ（¥¥）を記述してください。
また、通常の''という方法以外に、¥'と記述することで単一引用符をエスケープ文
字列に含めることができます。

http://www.postgresql.jp/document/current/html/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS

文字列リテラルのエスケープ
• どの文字をエスケープするのか?
– SQL製品の文字列リテラルのルールに従う
– ISO標準では、「'」→「''」
– MySQLとPostgreSQLは「'」→「''」「¥」→「¥¥」
• NO_BACKSLASH_ESCAPES=onの場合は、ISO標準と同じ方法になる
– PostgreSQLの場合は、standard_conforming_stringsおよび
backslash_quoteの影響を受ける
• standard_conforming_strings=onの場合は、ISO標準と同じ方法になる
• backslash_quoteの場合は、「'」→「¥'」というエスケープがエラーになる

元の文字エスケープ後
Oracle
MS SQL ’ ’’
IBM DB2
MySQL ’ ’’ または ¥’ (’’を推奨)
PostgreSQL ¥ ¥¥

MySQLとPostgreSQLで「¥」のエスケープが必要な理由
SELECT * FROM XXX WHERE ID='$id'

$id として ¥'or 1=1# が入力されると

¥'or 1=1#
↓ エスケープ(「¥」のエスケープをしない場合)
¥''or 1=1#

元のSQLに適用すると、

SELECT * FROM XXX WHERE ID='¥'' or 1=1#'

すなわち、SQLの構文が改変された(「¥’」で「’」一文字と見なされる)


数値型パラメータの対処

• 一部で、数値パラメータについても、エスケープしてクォートする
（引用符で囲む）ことを推奨しているが…
例: select * from employee wehre age > '27'
• SQLは「型付けの強い言語」であり、数値をクォートすると副作用
が大きい
– 文字列から数値への「暗黙の型変換」が発生
– 文字列から数値の変換は処理系依存であり、予期しない結果を生む
• 暗黙の型変換の奇妙な結果の例(MySQL)
create table dtest (d0 decimal(20, 0));
insert into dtest values(12345678901234567890);
insert into dtest values(12345678901234570000);
select * from dtest where d0 = '12345678901234567890';
+-----------------------+
| d0 |
+-----------------------+
| 123456789012345670000 |
+-----------------------+

数値型パラメータの対処（続き）

• なぜ、奇妙な結果になるか?
select * from dtest where d0 = '12345678901234567890‘;
• 数値例d0と文字列リテラル‘12345678901234567890’の比較に
際して、文字列→浮動小数点型への変換が発生する
次のルールは、比較の演算に対してどのように変換が行われるかを示しています :
* 【中略】
* 他のすべてのケースでは、引数は浮動少数点 ( 実 ) 数として比較されます。
「MySQL 5.1 リファレンスマニュアル :: 11 関数と演算子 :: 11.1 演算子 :: 11.1.2 式評価でのタイプ変換」より引用
http://dev.mysql.com/doc/refman/5.1/ja/type-conversion.html

mysql> select '12345678901234567890'+0;
+--------------------------+
| '12345678901234567890'+0 |
+--------------------------+
| 1.23456789012346e+019 | 浮動小数点数に変換されている
+--------------------------+

• 数値は数値のまま扱うこと
35
Copyright © 2008-2010 HASH Consulting Corp.

quoteメソッドの詳細
PHPのPear::MDB2におけるquoteの呼び出し
require_once ‘MDB2.php’; //ライブラリのロード
// DBへの接続（PostgreSQLの場合）
$db = MDB2::connect('pgsql://dbuser:password@hostname/dbname?charset=utf8');

// 文字列型を指定して、文字列リテラルのクォート済み文字列を得る
（略）$db->quote($s, 'text') （略）

// 数値型を指定して、数値リテラルの文字列を得る
（略）$db->quote($n, 'decimal') （略）

データ型指定戻り値
abc 'text' 'abc' （PHPの文字列型の値、クォートを含む）
O'Reilly 'text' O''Reilly' （PHPの文字列型の値、クォートを含む）
-123 'decimal' -123 （PHPの文字列型の値）
123abc 'decimal' 123 （PHPの文字列型の値）
-123 'integer' -123 （PHPの整数型の値）
123abc 'integer' 123 （PHPの整数型の値）


quoteメソッドの数値データの処理結果
Perl DBI/DBD、PHPのPDO, Pear::MDB2でquoteの処理内容を調査

1a¥’ をINTEGER型を指定してquoteすると、どうなるか?

サンプルスクリプト:

DBI: $dbh->quote("1a¥¥'", SQL_INTEGER)
PDO: $dbh->quote("1a¥¥'", PDO::PARAM_INT)
MDB2: $dbh->quote("1a¥¥'", 'integer')

モジュール名結果
DBI(DBD::mysql) 1a¥' なにもしていない！（脆弱性）
DBI(DBD::PgPP) '1a¥¥¥''
PDO '1a¥¥¥''
MDB2 1 (int型) 正しい結果
• quoteメソッドに期待したが、現状SQLの仕様通り動作するのはMDB2のみ
• プレースホルダの利用を推奨


【文字コードの問題1】 5C問題によるSQLインジェクション

• 5C問題とは
– Shift_JIS文字の2バイト目に0x5Cが来る文字に起因する問題
ソ、表、能、欺、申、暴、十 … など出現頻度の高い文字が多い
– 0x5CがASCIIではバックスラッシュであり、ISO-8859-1など1バイト文字と
解釈された場合、日本語の1バイトがバックスラッシュとして取り扱われる
– 一貫して1バイト文字として取り扱われれば脆弱性にならないが、1バイト
文字として取り扱われる場合と、Shift_JISとして取り扱われる場合が混在
すると脆弱性が発生する


ソースコード（要点のみ）

<?php
header('Content-Type: text/html; charset=Shift_JIS');
$key = @$_GET['name'];
if (! mb_check_encoding($key, 'Shift_JIS')) {
die('文字エンコーディングが不正です');
}
// MySQLに接続(PDO)
$dbh = new PDO('mysql:host=localhost;dbname=books', 'phpcon', 'pass1');
// Shift_JISを指定
$dbh->query("SET NAMES sjis");
// プレースホルダによるSQLインジェクション対策
$sth = $dbh->prepare("SELECT * FROM books WHERE author=?");
$sth->setFetchMode(PDO::FETCH_NUM);
// バインドとクエリ実行
$sth->execute(array($key));
?>


5C問題によるSQLインジェクションの説明


対策

• 文字エンコーディング指定のできるデータベース接続ライブ
ラリを選定し、文字エンコーディングを正しく指定する
$dbh = new PDO('mysql:host=xxxx;dbname=xxxx;charset=cp932',
'user', 'pass', array(
PDO::MYSQL_ATTR_READ_DEFAULT_FILE => '/etc/mysql/my.cnf',
PDO::MYSQL_ATTR_READ_DEFAULT_GROUP => 'client', ));
# http://gist.github.com/459499 より引用（by id:nihen）

• 静的プレースホルダを使うよう指定する、
あるいはプログラミングする
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,
false);

• 詳しくは「安全なSQLの呼び出し方」を参照
http://www.ipa.go.jp/security/vuln/websecurity.html


【文字コードの問題2】 U+00A5によるSQLインジェクション

Class.forName("com.mysql.jdbc.Driver");
Connection con = DriverManager.getConnection(
"jdbc:mysql://localhost/books?user=phpcon&passw
ord=pass1");
String sql = "SELECT * FROM books where
author=?";
// プレースホルダ利用によるSQLインジェクション対策
PreparedStatement stmt =
con.prepareStatement(sql);
// ? の場所に値を埋め込む（バインド）
stmt.setString(1, key);
ResultSet rs = stmt.executeQuery(); // クエリの実行


U+00A5によるSQLインジェクションの原理

IPA:安全なSQLの呼び出し方（http://www.ipa.go.jp/security/vuln/websecurity.html）より引用

U+00A5によるSQLインジェクションの条件と対策

• 脆弱性が発生する条件
– JDBCとしてMySQL Connector/J 5.1.7以前を使用
– MySQLとの接続にShift_JISあるいはEUC-JPを使用
– 静的プレースホルダを使わず、エスケープあるいは動的プレースホルダ
（クライアントサイドのバインド機構）を利用している
• 対策（どれか一つで対策になるがすべて実施を推奨）
– MySQL Connector/Jの最新版を利用する
– MySQLとの接続に使用する文字エンコーディングとしてUnicode(UTF-8)
を指定する
（接続文字列にcharacterEncoding=utf8を指定する）
– 静的プレースホルダを使用する
（接続文字列にuseServerPrepStmts=trueを指定する）


簡単にできるテスト

• 以下の文字を入力・登録して、どのように表示されるかを調べる
– ¥ (U+00A5) バックスラッシュに変換されないか
– 骶 (U+9AB6) JIS X 0208にない文字
– (U+20BB7) BMP外の文字 UTF-8では4バイトになる
• 尾骶骨テストや「つちよし」テストで、Unicodeがきちんと通るか確
認しよう


SQLインジェクション対策
• 入力値
– 文字エンコーディングの検証 and/or 文字エンコーディングの変換
– 要件に従った入力値の検証（制御文字のチェックは必須）
• SQL呼び出し
– ともかくプレースホルダを使うこと
– 静的プレースホルダの利用が「原理的に」安全
– 「安全なSQLの呼び出し方」をよく読む
• 文字コードの選定
– アプリケーションを通してUnicodeを使う
• HTTPメッセージはUTF-8
• アプリケーションの内部はUTF-8かUTF-16
– ケータイ向けサイトはHTTPメッセージの文字エンコーディングをShift_JISに
するが、内部はUTF-8とする
• EUC-JPという選択もあり得るが、使える言語が少ない
• 円記号U-00A5 → バックスラッシュ(5C) の変換に注意
– 尾骶骨テストのすすめ

ケータイサイトのセキュリティ


ケータイWebアプリの構成

キャリア基地局
ゲートウェイコンテンツ提供事業者
iモード
EZweb Webサーバ DBサーバ
Yahoo! ケータイ
ワイヤレス網

インターネット

端末
DB
(Hand Set)
言語変換
認証
SSL暗号化
Cookie保持
・・・

ケータイWebアプリの特徴
• 基本的には、PCサイトと同じようなWebアプリケーションである
– HTMLまたは類する言語で記述され、HTTPを通じてインターネット・アクセスされる．
– 昔：ＣｏｍｐａｃｔＨＴＭＬ、ＨＤＭＬ、ＭＭＬ → 今：HTML/XHTML
• PCブラウザとの違い
– 大半の端末でＪａｖａＳｃｒｉｐｔが使えない
– Ｃｏｏｋｉｅが使えない・・・ことがある
– キャリアごとに、端末固有ID(uid、EZ番号)がある
– HTMLソースが読めない
• キャリアのゲートウェイ(Proxy)経由でアクセスされる
– キャリアのゲートウェイ経由でアクセスされる
– IPアドレスはゲートウェイが持つ
– ゲートウェイには、コンテンツ変換機能、認証・課金機能がある
• SSLが利用できる(最初期以外)
– しかし、端末の「世代」により動作が少し異なる


ケータイWebアプリの脆弱性とは


Ｃｏｏｋｉｅが使えない・・・ことがある

• iモードでは伝統的にCookieが使えなかった
• EZweb、Yahoo! ケータイではCookieが利用できる(ものもある)
が
– RFCに忠実に実装されているわけではない
– Expiresの解釈・実装がRFC(PCブラウザ)とは異なる場合がある
– Yahoo! ケータイのガイドラインには、「一部の3GC型端末では、期限が指
定されていないCookieを一時型として扱わないので注意すること」とある!?
• 結局、ケータイコンテンツを作成する際には、Cookieを使わない
で実装することが多い
– URLにセッションIDを埋め込む
– 端末固有IDをセッション識別に利用する
– 着メロなどでは、セッション管理機能を利用しないで全部引き回す場合
も・・・
• Cookieを使わないで、ケータイ固有のセッション管理手法を用い
ることから、脆弱性が生まれる

【参考】EzwebのCookieの挙動

•SSL時には端末、非SSL時にはゲートウェイにCookie格納と明記されている
•SSLと非SSL共存のサイトは特に注意
http://www.au.kddi.com/ezfactory/tec/spec/cookie.html から引用


【参考】ソフトバンクのSSL挙動

•ソフトバンクのSSLは、原則としてゲートウェイ経由になる
SSLの場合でも、端末固有ID付与や絵文字変換を行っている
•しかし、リンクを経由せずダイレクトに接続した場合は、End to EndのSSLになる
•このため、SSLの場合と、非SSLの場合にドメインが異なることになり、セッションID
が共有できないという問題
•secure.softbank.ne.jp経由のSSLは廃止の方向とのこと
産総研の高木浩光氏とソフトバンク宮川潤一CTOがtwitter上で会話され、
廃止の方向性が決定される
http://creation.mb.softbank.jp/web/web_ssl.htmlから引用


http://mb.softbank.jp/mb/information/details/101015.html より引用

基本的には、PCサイトと同じようなWebアプリケーションである

• 一般的なWebアプリケーション脆弱性パターンは、ケータイWeb
アプリケーションでも同じように成立する
– ディレクトリ・トラバーサル
– OSコマンドインジェクション
– HTTPヘッダ・インジェクション
– メールヘッダ・インジェクション
– ・・・
– 他者権限の利用
– CSRF
– セッションフィクセーション


大半の端末でＪａｖａＳｃｒｉｐｔが使えない

• ケータイブラウザではJavaScriptがサポートされていない
– ドコモの2009年夏モデルからはJavaScriptサポート
– ソフトバンクの2010年夏モデルから一部でJavaScript正式サポート
– 狭義のCross-Site Scripting(XSS)攻撃は成立しなかったことになるが・・・
• XSSを広義(タグのエスケープ漏れ)にとらえると、ケータイブラウ
ザ上でも「悪いこと」できる可能性がある
– 画面の改ざん
– フィッシングへの悪用
– その他の特殊なタグ・・・
• マイナーなタグの挙動は、キャリア、世代、機種によって微妙に
異なる
– ある端末で「悪いこと」が起こらなくても、安心はできない
• 今後ドコモ、ソフトバンクの新機種はJavaScript対応になるので、
JavaScriptを前提にしたセキュリティ施策が必要


キャリアのゲートウェイ(Proxy)経由でアクセスされる

• 一般に、ケータイWebアプリは、「ゲートウェイがあるから安全」と
言われることが多いが・・・
• 現実には、ゲートウェイとWebサーバー間はインターネットで接続
されるので、必ずしも安全ではない
• 安全な例(PCからアクセスできない)
– キャリアとWebサーバー間を専用線で接続する(最近はあまり聞かない)
– ファイヤーウォールなどで、ゲートウェイ以外からのアクセスを拒絶する
• 安全でない例(PCからアクセスできる)
– アクセス制限をしていない
– User-Agentによりアクセス制限をしている・・・PCで簡単に偽装できる
• いずれにせよ、ケータイ実機を使った不正アクセスに対しては、
ゲートウェイは無力
• Wi-Fi経由の利用が多いスマートフォンが普及すると、今後は、
IPアドレス制限が掛けにくくなる可能性


ケータイ固有の脆弱性問題


「かんたんログイン」とは

端末固有IDのみを
キーとして認証する

端末固有IDあれこれ

キャリア名称 HTTPヘッダ
NTTドコモ FOMA端末識別番号 User-Agent
iモードＩＤ X-DCMGUID
Au EZ番号 X-UP-SUBNO
ソフトバンク端末シリアル番号 User-Agent
ユーザーＩＤ X-JPHONE-UID


かんたんログイン画面の例(1)


「かんたんログイン」がなりたつための条件

• 端末固有IDは、同一端末であれば、すべてのサイトに同じ値が
送出される。すなわち、端末固有IDは秘密情報ではない
• 秘密情報でない、固定のIDで認証するためには、端末固有IDは
書き換えができないという前提が必要
• 端末固有IDはHTTPヘッダに乗ってくる値なので、通常は任意に
書き換えができる。携帯電話を使っている時は変更できないと考
えられているが…

• まとめると、かんたんログインはケータイの以下の条件によって
支えられている
– ケータイWebが閉じたネットワークで利用される
– ケータイ端末の機能が低く、HTTPヘッダを書き換える機能がない


かんたんログイン脆弱性報告の例

65

かんたんログイン脆弱性および事故の例

http://www.kuronekoyamato.co.jp/info/info_101025.html 66

iモードブラウザ2.0の登場

2009年5月19日づけNTTドコモ社の報道発表より

http://www.nttdocomo.co.jp/info/news_release/page/090519_00.html より引用


ケータイJavaScriptで端末固有ＩＤを書き換える条件

• 以下の三条件がそろえば、端末固有IDの書き換え、すなわち「か
んたんログイン」なりすましができるが・・
a. 携帯電話のJavaScriptでXMLHttpRequestオブジェクトが利用できる
b. XMLHttpRequestにてsetRequestHeaderメソッドが利用できる
c. setRequestHeaderメソッドにてUserAgentなどのリクエストヘッダが書き
換えできる
• 10月末のJavaScript再有効化の際に、 setRequestHeaderメソ
ッドが無効化された模様。すなわち、上記b、cが成立しなくなった。
• 元々のNTTドコモのサイトではJavaスクリプトの仕様書に
setRequestHeaderもちゃんと載っていたのだが…現時点では削
除されている
• XMLHttpRequest自体にも制限が加わり、JavaScriptが置かれ
たコンテンツのディレクトリかサブディレクトリのみがアクセス可能

参照: http://www.tokumaru.org/d/20090805.html#p01

DNS Rebindingによるなりすまし攻撃
www.hash-c.co.jp evil.example.jp
115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 192.0.2.2

攻撃者はワナを準備
して誘導


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 192.0.2.2

ユーザが
ワナを閲覧


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

攻撃者は
DNSを操作


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

ケータイJavaScript
10秒後に
evil.example.jp
を閲覧開始


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

evil.example.jpの
IPアドレスを要求


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

115.146.17.185
を返す


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

iモードIDが送出
X-DCMGUID:xxxXXX9

http://evil.example.jp/
userinfo.php?guid=ON
にアクセス


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

個人情報を返す
氏名、メールアドレス、
住所、電話番号


115.146.17.185 192.0.2.2
攻撃対象ワナ

example.jpのDNS

evil 115.146.17.185

個人情報をワナのサ
ーバーに返す


DNSリバインディング対策はケータイ事業者側ではできない

• 本来はケータイブラウザあるいはゲートウェイで対策するべきも
のではあるが…
• ケータイブラウザはゲートウェイ（PROXY）経由のアクセスなので、
ブラウザでは名前解決をしていない。すなわち、ブラウザでは対
策（DNS Pinning）できない
• ゲートウェイはマルチユーザが対象なので、文脈を意識した
Pinningは不可能で、いつかはIPアドレスを切り替えなければな
らない


• キャリアのDNSが最低1時間DNSキャッシュする想定では、以下
のような攻撃が可能となる
• 攻撃者はワナサイトを用意する
• 攻撃者は自ら携帯電話でワナサイトをアクセスする
• ワナサイトのIPアドレスをターゲットサイトのIPに切り替えておく
• 58分後に、ワナサイトのURLをまいて誘導する
• 被害者がワナサイトを閲覧した直後に、DNSサーバーのキャッシ
ュ保持が無効となる
• 被害者のブラウザ上でDNSリバインディングを悪用したリクエスト
が発行されるが、既に標的サイトのIPアドレスが有効となり、攻撃
が成立する


ゲートウェイIPの変遷


Webサイト側でのDNSリバインディング対策

• iモードブラウザ2.0のXMLHttpRequestでは、
setRequestHeaderメソッドが無効化されているので、リクエスト
ヘッダのHostフィールドはワナサイトのドメインになっている
• したがって、かんたんログインの際に、Hostフィールドをチェック
すればよい
• 簡単に実装するには、名前ベースのバーチャルホストにすれば
よい


twtr.jpの事例

http://www.tokumaru.org/d/20100222.html#p01


http://takagi-hiromitsu.jp/diary/20100228.html#p01 より引用

ソフトバンクでもJavaScriptに対応

http://k-tai.impress.co.jp/docs/news/20100518_367787.html より引用

本当に2010年夏モデルからなのか?

• 実はかなり以前からソフトバンク端末の一部のモデルで
JavaScriptに対応していた
• ノキア 702NK(2004年12月発売)では簡単なJavaScriptに対応
– XMLHttpRequestやIFRAME、DOMには対応していない
• 804SS(2006年3月)、910T(2006年10月)、910SH(2006年11
月)では、NetFront 3.3によるJavaScript対応
– XMLHttpRequestには対応していない
– IFRAME、DOMに対応…攻撃に利用できる可能性*1
• 922SH(2008年3月)では、NetFront 3.4にてAjaxに対応
– XMLHttpRequestのサポート
– setRequetHeaderのサポート (!)
• 独自調査の結果、以下5機種は、デフォルトでAjaxが有効
– 820N, 821N, 831N, 830CA, 940SC


Ajax有効な機種のサマリ

•ただし、SHARPの最新機種943SHのみは、Refererが送出されるが、改変はできない
•△はデフォルトでAjax無効、オプションにより有効化可能（SHARP端末は多いので抜粋）
•上記以外のPanasonic、Toshiba等はAjax無効

「かんたんログイン」は、ギリギリの瀬戸際に立たされている

• かんたんログインに対して、ケータイ JavaScriptによる攻略手
法がわかってきた
• かんたんログインに際しての必須対策
– キャリアゲートウェイのIPアドレスとのみ通信を制限する
– キャリアの判定にもIPアドレスを用いる
– Hostヘッダのチェック（あるいは名前ベースのバーチャルホスト）
– ソフトバンク端末については、Ajax規制あるいはスクリプトの禁止
– SSLでは、かんたんログインは行わない
– ・・・
• これで完璧かどうかは誰にも分からない
– とくに、ソフトバンク端末のように機種依存性が多いと、全ての端末につい
て検証しないと確かなことは言えない
• それでも、まだ、かんたんログイン続けますか？


能動的攻撃の可能性


ケータイJavaScriptによる能動的攻撃の可能性

• iモードブラウザ2.0はsetRequestHeader()が無効化されている
ので、User-AgentやX-DCM-GUIDの変更は不可能と思われる
• ソフトバンク端末では、 setRequestHeader()関数自体は無効化
されていないが、User-AgentやX-JPHONE-UIDの変更は禁止さ
れている
• ・・・
• 抜け道はないのか？


2種類のトリックによる端末固有IDの改変が可能

• トリック１：End-EndのSSLを使う
– キャリアゲートウェイのチェックをすり抜ける
– ソフトバンクにはゲートウェイ型のSSLもあるが、こちらはゲートウェイのチ
ェックが有効（2011年2月廃止予定）
• トリック２：ハイフン「-」の代わりにアンダースコア「_」を用いる
– リクエストヘッダ中のハイフンは、アプリケーションが利用する際にアンダ
ースコアに変更される仕様を悪用
– アンダースコアはゲートウェイだとチェックされるが、端末のチェックはすり
抜ける


SSLを利用したリクエストヘッダ改変スクリプトの例
var requester = new XMLHttpRequest();
requester.open('GET', 'https://example.com/login.php', true);
requester.onreadystatechange = function() {
if (requester.readyState == 4) {
onloaded(requester);
}
};
requester.setRequestHeader("Host", "twtr.com");
requester.setRequestHeader("User_Agent",
"SoftBank/1.0/943SH/SHJ001/SN359XXXXXXXXXXX0 " +
" Browser/NetFront/3.5 Profile/MIDP-2.0 Configuration/CLDC-1.1");
requester.setRequestHeader(
"X_JPHONE_UID", "a3XXXXXXXXXXXXXP");
requester.send(null);


アプリケーションが受け取ったリクエストの例（一部）
HTTP_USER_AGENT=DoCoMo/2.1 P07A3(c500;TB;W24H15)Fake
SERVER_NAME=twitter.com
SERVER_PORT=443
HTTP_COOKIE=aaa=bbbx
REMOTE_ADDR=123.108.237.4
SERVER_PROTOCOL=HTTP/1.1
HTTP_X_JPHONE_UID=fakejphoneuid
HTTP_X_DCMGUID=fakedcmguid
HTTP_X_UP_SUBNO=fakesubno
HTTP_HOST=twitter.com

※URLと証明書のドメインが異なるので警告が出るが、処理は続行可能

ＳＳＬを悪用した能動型なりすまし攻撃への対策

• SSLではかんたんログインを受け付けない
– 必須はソフトバンクのみ禁止だが、全キャリア禁止することが無難
• キャリア判定は、User-Agentではなく、IPアドレスで行う


セッション管理の問題


ケータイWebアプリのセッション管理手法

• ケータイWebアプリでセッションIDを保持する場所はいくつか候
補がある
– URL埋め込み
• 現在の主流
• しかし、色々と注意点がある
– Cookie
• iモードブラウザがCookie非対応だったのであまり使われなかった
• 今後iモードもCookie対応になるので、中・長期的にはCookieへの移行が望ま
しい
– 端末固有IDそのものをセッションIDとして使用する方法
• 最近増えつつあるようだが
• 前述の理由でやめた方がよい
• SSLに対応できない
• 一般的なセキュリティ対策が使えない場合がある


セッションIDをURLに埋め込む場合の問題点

• URLに埋め込まれたセッションIDがReferrer経由で漏洩する
• セッションフィクセイション攻撃の可能性
• ユーザがURLをメールなどで教えてしまう(!)


URLに埋め込まれたセッションIDがReferrer経由で漏洩する
http://hogehoge.jp

WebサイトAにアクセス
A
http://hogehoge.jp/item.jsp;JSESSIONID=12345ABCDEF

WebサイトBへのリンク
<a href=“http://honya.jp/”>honya</a>

リンクをクリック
http://honya.jp/l

【アクセスログ】
【アクセスログ】
・・・
・・・
WebサイトBのログに、・・・
・・・
別サイトのセッションIDが記録される http://hogehoge.jp/
http://hogehoge.jp/
item.jsp;JSESSIO
item.jsp;JSESSIO
NID=12345ABCD
NID=12345ABCD
EF
EF
なりすましの危険性 WebサイトB ・・・
・・・
・・・
・・・
http://honya.jp/


RefererによるセッションID漏洩

• そもそもケータイブラウザではRefererは送出されるのか?
– iモードでは送出されないことになっていたが・・・
• iモードブラウザ2.0では送出されるようになった
– EZwebでは送出することになっているが・・・
– Yahoo! ケータイでは送出することになっているが・・・
• キャリアごとの端末世代依存、機種依存もある
– 端末のバグという話もあるが、このレベルのバグは改修されないことが多
い
• ケータイWebアプリでは、URLにセッションIDを埋め込む実装が
多く用いられるので、RefererからのセッションID漏洩には注意が
必要
• キャリアごとに違いにより、テスト漏れが発生しやすい
• 結局、細かいことを考えずに粛々とReferer対策をしておくのが一
番安全


セッションフィクセイション攻撃の可能性

• 攻撃者がセッションIDを取得する
• セッションIDつきのURLをメールなどで、正規ユーザ(被害者)に
送りつけ、巧妙なメッセージでURLを実行させる
• 正規ユーザが同URLをアクセスすると、攻撃者は同じセッション
を共有できることになる。


ユーザがURLをメールなどで教えてしまう(!)

• セッションフィクセイションと似ているが・・・
• セッションIDつきのURLを正規ユーザが知人などにメールで知ら
せてしまうorz
• 自爆型セッションフィクセイション


セッションフィクセイション対策

• 一般的なセッションフィクセイション対策は必須
– ログイン後にセッションIDを振り直す
– PHPの場合は session_regenerate_id() が使える
• ログイン前には極力セッションを使用しない
– hiddenの方が安全
– ログイン前のセッションは、全ユーザと共有しているくらいのつもりで
• 様々な「保険的対策」
– 検索エンジンにはセッションIDつきのURLが保存されないように注意
– SNSなどでは、ユーザが自分のページのURLをセッションIDつきで添付し
ないようにチェックする
– Refererチェックにより外部からリンクされた場合はセッションをリセットする
– セッションタイムアウトを短めに設定する / 明示的なログアウト
• Cookieへの移行を真剣に検討する


スマートフォンのセキュリティ
（グローバルな話題）


スマートフォンのWebアプリケーションセキュリティ

• PC向けのWebアプリケーションセキュリティと同じ
• 普通にセキュリティ対策する
– クロスサイト・スクリプティング
– クロスサイト・リクエストフォージェリ
– ・・・
• いわゆる「かんたんログイン」は実装してはいけない
– もっとも、iPhoneやAndroidのブラウザは端末固有IDを送出しないので、
やりたくてもできないが…
– アプリはどうか?


クライアントアプリのセキュリティ脅威

• 端末の紛失・盗難を気にする人が多いが
– 端末が他人の手に渡ったら、いくらでも時間を掛けて解析できるので、端
末上のデータは守れないと考えた方がよい
– 重要なデータはサーバー（クラウド）に
• サーバーとの通信にはHTTP/HTTPSが広く利用される
– 基本的にはWebアプリケーションと同じ脅威
– SQLインジェクションなど…
– XSS、CSRFなどブラウザ経由で起こる問題は発生しない
• ただし、アプリからブラウザを起動している場合などは例外
• 認証に注意
– 端末認証によりパスワードなしで使えるアプリが多い
– 認証方式に注意
– 端末の紛失・盗難時に、速やかにアカウントロックができるようにサーバー
側で考慮を


クライアントアプリのセキュリティ

• 重要な情報はサーバー上に保持する
• Ｗｅｂアプリケーションと共通のセキュリティ対策
• 認証がカギ
• 「見えないこと」に頼ったセキュリティは脆弱
– スマートフォンの場合、Wi-Fiパケットは簡単にキャプチャできる
– アプリのリバースエンジニアリングの可能性
• クライアントアプリなら端末固有IDが取得できるが
– iPhone: ICCID、UDIDなど
– Android: ANDROID_ID、IMEI、SIMシリアル番号など
– いずれも認証に使ってはいけない


AT&Tのウェブサイトから「iPad」ユーザーのデータが大量流出

• ブログネットワークのGawker Mediaは米国時間6月9日、AT&Tのウェブサ
イトから「iPad Wi-Fi ＋ 3G」ユーザー約11万4000人分の電子メールアドレス
情報が流出したと報じた。漏えいしたデータには、米国政府の高官や映画監
督、企業の最高経営責任者（CEO）のものも含まれているようだ。
• 同報道によると、Goatse Securityと名乗るハッカーグループが、AT&Tのウ
ェブサイトから、iPadのSIMカードのシリアル番号を含んだHTTPリクエストを
送信し、電子メールアドレスを入手したという。このICCIDと呼ばれるシリアル
番号は順番に付けられているため、容易に推測できるとしている。
• AT&Tの広報担当者は米CNETに対しデータ流出があったことを認め、同社
は7日、Goatse Securityとは関係しない人物からiPadのICCIDのデータ漏え
いの可能性について報告を受け、その翌日に電子メールアドレスを提供する
機能を停止したと述べた。また、ICCIDから引き出せる情報は、電子メールア
ドレスだけであり、同社は調査を継続するとともに、情報の流出について顧客
に報告していくと発表した。Goatse SecurityとAppleにもコメントを求めたが、
返答は得られていない。

http://itpro.nikkeibp.co.jp/article/MAG/20100611/349088/ より引用 108

「電波チェッカー」の事例

このアプリケーションは端末識別のためUDID情報を使用します。


対策


ケータイWebアプリの対策

• 認証とセッション管理が最大の課題
– いずれもcookieを使えば解決
• Webアプリケーションの一般原則として、セキュアな作りにする
– XSS、SQLインジェクション対策などをふつーに実装する
– 「これはケータイではできないはず」などと手を抜かない
– ケータイ固有の作法を極力使わない。cookieが使えればcookieを使う
• ケータイ固有の特性をよく勉強する
– キャリアとの契約により情報を入手する
– 地道に技術解説書を読む
– ネット等のセキュリティ勧告を地道に追う


ご清聴ありがとうございました


今日こそわかる、安全なWebアプリの作り方2010

More Related Content

今日こそわかる、安全なWebアプリの作り方2010