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

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

3.

徳丸浩の自己紹介 • 経歴 – 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/ – 独立行政法人情報処理推進機構非常勤研究員 Copyright © 2010 HASH Consulting Corp. http://www.ipa.go.jp/security/ 3

4.

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

5.

6.

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

7.

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

8.

入力値検証の正規表現の具体例チェック内容数字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}で指定（量指定子） Copyright © 2008-2010 HASH Consulting Corp. 8

9.

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

10.

11.

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

12.

13.

14.

正しくない例2(2008年) ??? これは無意味 Billy Hoffman、Bryan Sullivan著、GIJOE監訳、渡邉了介訳「Ajaxセキュリティ」、毎日コミュニケーションズ、2008年、P113より引用 • このような方法では効果が薄いだけではなく、ケースバイケーズで正しい方法を考えなければならない点が問題 • 脆弱性対策は、もっと機械的に適用できるものでないと実用的でない Copyright © 2008-2010 HASH Consulting Corp. 14

15.

正しくない例3(2008年) 【前提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/ Copyright © 2008-2010 HASH Consulting Corp. 15

http://itpro.nikkeibp.co.jp/article/COLUMN/20080514/301660/

16.

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

17.

処理系のバグ（不適切な仕様）を避ける目的も…（過去の話題）問題は、このプログラムではユーザ入力データをそのまま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スクリプトを呼び出す機能があった • しかも、パイプ記号をエスケープする手段が提供されていなかった • 不適切な仕様だが、現在では改修されている Copyright © 2008-2010 HASH Consulting Corp. 17

18.

【参考】なぜセミコロン「;」を削除したがるのか? • 実はセミコロンの削除には実効的な意味はあまりない • セミコロン削除の意図は、複文実行の防止と思われる – 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 Copyright © 2008-2010 HASH Consulting Corp. 18

19.

20.

そもそもなぜSQLインジェクションが発生するのか? • 原因は、リテラルとして指定したパラメータが、リテラルの枠をはみ出し、SQLの一部として解釈されること • 文字列リテラルの場合 – シングルクォートで囲まれた(クォートされた)範囲をはみ出す SELECT * FROM XXX WHERE A=’’OR’A’=A’ • 数値リテラルの場合はみ出した部分 – 数値でない文字(空白、英字、記号など)を使う SELECT * FROM XXX WHERE A=1OR TRUE Copyright © 2008-2010 HASH Consulting Corp. 20

21.

エスケープは檻にしっかり入れるイメージ • 檻に入っている分には、中身の「危険性」を気にする必要なはい • 危険性がなくても、檻から出てしまうのはバグ select * from animals whre kind=' ' 「危険な文字・文字列」 ; | ' @ declare union xp_cmdshell @ ... Copyright © 2008-2010 HASH Consulting Corp. 21

22.

23.

24.

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種類ある（静的・動的） Copyright © 2008-2010 HASH Consulting Corp. 24

25.

静的プレースホルダ安全なSQLの呼び出し方より引用 http://www.ipa.go.jp/security/vuln/websecurity.html •SQLとパラメータは別々にサーバーに送られる •パラメータ抜きでSQLは構文解析される •パラメータは後から割り当てられる SQLインジェクション脆弱性の可能性が原理的になくなる Copyright © 2008-2010 HASH Consulting Corp. 25

http://www.ipa.go.jp/security/vuln/websecurity.html

26.

動的プレースホルダ安全なSQLの呼び出し方より引用 http://www.ipa.go.jp/security/vuln/websecurity.html • SQLとパラメータは呼び出し側で、エスケープ、連結される • データベースサーバー側は、組み立てられた文字列をSQLとして実行するだけライブラリにバグがなければ、 SQLインジェクション脆弱性は発生しない Copyright © 2008-2010 HASH Consulting Corp. 26

http://www.ipa.go.jp/security/vuln/websecurity.html

27.

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

28.

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

29.

【参考】商用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 Copyright © 2008-2010 HASH Consulting Corp. 29

30.

【参考】 MySQLの文字列リテラルの定義 8.1.1. 文字列一部のシーケンスは、個々の文字列内で特別な意味を持ちます。これらのシーケンスは、いずれも、エスケープ文字として知られるバックスラッシュ（‘¥’）で始まります。MySQLでは、次のエスケープシーケンスが認識されます。文字列に引用符を含める方法は、いくつかあります。 •‘’’で囲んだ文字列内で、‘’’を使用する場合、‘’‘’と記述することができます。【後略】「MySQL :: MySQL 5.1 リファレンスマニュアル :: 8.1.1 文字列」から引用 http://dev.mysql.com/doc/refman/5.1/ja/string-syntax.html Copyright © 2008-2010 HASH Consulting Corp. 30

http://dev.mysql.com/doc/refman/5.1/ja/string-syntax.html

31.

【参考】 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 Copyright © 2008-2010 HASH Consulting Corp. 31

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

32.

文字列リテラルのエスケープ • どの文字をエスケープするのか? – 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 ’ ¥ ’’ または ¥’ (’’を推奨) ¥¥ Copyright © 2008-2010 HASH Consulting Corp. 32

33.

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の構文が改変された(「¥’」で「’」一文字と見なされる) Copyright © 2008-2010 HASH Consulting Corp. 33

34.

[beta]

数値型パラメータの対処
• 一部で、数値パラメータについても、エスケープしてクォートする
（引用符で囲む）ことを推奨しているが…
例: 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 |
+-----------------------+
Copyright © 2008-2010 HASH Consulting Corp.

34

35.

数値型パラメータの対処（続き） • なぜ、奇妙な結果になるか? 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.

http://dev.mysql.com/doc/refman/5.1/ja/type-conversion.html

36.

[beta]

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
O'Reilly
-123
123abc
-123
123abc

型指定
'text'
'text'
'decimal'
'decimal'
'integer'
'integer'

戻り値
'abc' （PHPの文字列型の値、クォートを含む）
O''Reilly' （PHPの文字列型の値、クォートを含む）
-123 （PHPの文字列型の値）
123 （PHPの文字列型の値）
-123 （PHPの整数型の値）
123 （PHPの整数型の値）

Copyright © 2008-2010 HASH Consulting Corp.

36

37.

[beta]

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)
DBI(DBD::PgPP)
PDO
MDB2

結果
1a¥'
'1a¥¥¥''
'1a¥¥¥''
1 (int型)

なにもしていない！（脆弱性）

正しい結果

• quoteメソッドに期待したが、現状SQLの仕様通り動作するのはMDB2のみ
• プレースホルダの利用を推奨
Copyright © 2008-2010 HASH Consulting Corp.

37

38.

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

39.

[beta]

ソースコード（要点のみ）
<?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));
?>
Copyright © 2008-2010 HASH Consulting Corp.

39

40.

41.

[beta]

対策

• 文字エンコーディング指定のできるデータベース接続ライブ
ラリを選定し、文字エンコーディングを正しく指定する
$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

Copyright © 2008-2010 HASH Consulting Corp.

41

http://www.ipa.go.jp/security/vuln/websecurity.html

42.

【文字コードの問題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(); Copyright © 2008-2010 HASH Consulting Corp. // クエリの実行 42

43.

http://www.ipa.go.jp/security/vuln/websecurity.html

44.

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を指定する） Copyright © 2008-2010 HASH Consulting Corp. 44

45.

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

46.

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

47.

48.

49.

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

50.

51.

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

52.

53.

【参考】ソフトバンクの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から引用 Copyright © 2008-2010 HASH Consulting Corp. 53

http://creation.mb.softbank.jp/web/web_ssl.html

54.

55.

56.

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

57.

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

58.

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

59.

60.

「かんたんログイン」とは端末固有IDのみをキーとして認証する端末固有IDあれこれキャリア名称 NTTドコモ FOMA端末識別番号 HTTPヘッダ User-Agent iモードＩＤ X-DCMGUID Au EZ番号 X-UP-SUBNO ソフトバンク端末シリアル番号 User-Agent ユーザーＩＤ X-JPHONE-UID Copyright © 2008-2010 HASH Consulting Corp. 60

61.

62.

63.

64.

「かんたんログイン」がなりたつための条件 • 端末固有IDは、同一端末であれば、すべてのサイトに同じ値が送出される。すなわち、端末固有IDは秘密情報ではない • 秘密情報でない、固定のIDで認証するためには、端末固有IDは書き換えができないという前提が必要 • 端末固有IDはHTTPヘッダに乗ってくる値なので、通常は任意に書き換えができる。携帯電話を使っている時は変更できないと考えられているが… • まとめると、かんたんログインはケータイの以下の条件によって支えられている – ケータイWebが閉じたネットワークで利用される – ケータイ端末の機能が低く、HTTPヘッダを書き換える機能がない Copyright © 2008-2010 HASH Consulting Corp. 64

65.

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

66.

かんたんログイン脆弱性および事故の例 http://www.kuronekoyamato.co.jp/info/info_101025.html 66

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

67.

68.

ケータイ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 Copyright © 2008-2010 HASH Consulting Corp. 68

69.

70.

71.

72.

DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 192.0.2.2 ワナ example.jpのDNS evil 115.146.17.185 ケータイJavaScript 10秒後に evil.example.jp を閲覧開始 Copyright © 2008-2010 HASH Consulting Corp. 72

73.

74.

75.

DNS Rebindingによるなりすまし攻撃 www.hash-c.co.jp 115.146.17.185 攻撃対象 evil.example.jp 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 にアクセス Copyright © 2008-2010 HASH Consulting Corp. 75

76.

77.

78.

79.

DNSリバインディング対策はケータイ事業者側ではできない • 本来はケータイブラウザあるいはゲートウェイで対策するべきものではあるが… • ケータイブラウザはゲートウェイ（PROXY）経由のアクセスなので、ブラウザでは名前解決をしていない。すなわち、ブラウザでは対策（DNS Pinning）できない • ゲートウェイはマルチユーザが対象なので、文脈を意識した Pinningは不可能で、いつかはIPアドレスを切り替えなければならない Copyright © 2008-2010 HASH Consulting Corp. 79

80.

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

81.

82.

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

83.

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

84.

85.

86.

本当に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 Copyright © 2008-2010 HASH Consulting Corp. 86

87.

88.

89.

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

90.

91.

ケータイJavaScriptによる能動的攻撃の可能性 • iモードブラウザ2.0はsetRequestHeader()が無効化されているので、User-AgentやX-DCM-GUIDの変更は不可能と思われる • ソフトバンク端末では、 setRequestHeader()関数自体は無効化されていないが、User-AgentやX-JPHONE-UIDの変更は禁止されている • ・・・ • 抜け道はないのか？ Copyright © 2008-2010 HASH Consulting Corp. 91

92.

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

93.

[beta]

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);

Copyright © 2008-2010 HASH Consulting Corp.

93

94.

アプリケーションが受け取ったリクエストの例（一部） 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と証明書のドメインが異なるので警告が出るが、処理は続行可能 Copyright © 2008-2010 HASH Consulting Corp. 94

95.

96.

97.

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

98.

99.

URLに埋め込まれたセッションIDがReferrer経由で漏洩する http://hogehoge.jp A Webサイト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/ Copyright © 2008-2010 HASH Consulting Corp. ・・・・・・・・・・・・ 99

100.

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

101.

102.

103.

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

104.

105.

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

106.

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

107.

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

108.

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

109.

110.

111.

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

112.

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

徳丸浩

関連スライド

SPAセキュリティ超入門

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

Webアプリケーション開発に潜むリスクのケーススタディ

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

各ページのテキスト

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

徳丸 浩

関連スライド

SPAセキュリティ超入門

SPAセキュリティ入門～PHP Conference Japan 2021

ウェブセキュリティのありがちな誤解を解説する

ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること

Webアプリケーション開発に潜むリスクのケーススタディ

SSRF対策としてAmazonから発表されたIMDSv2の効果と破り方

各ページのテキスト

徳丸浩