20090218 第５回「PhpによるWebアプリケーションのセキュリティ入門」

「 PHP による web アプリケーションのセキュリティ入門」第５回社内勉強会

攻撃を防ぐには

攻撃の種類を知る

防御の方法を知る

なにより

攻撃されている、ということを知る

本日のお題

PHP による web アプリケーションのセキュリティ入門

本日の目標

業務でおなじみ PHP を例に

PHP に限ったことじゃない

基礎知識と危機感を持って帰ってください

本日ご紹介しますのは

XSS

CSRF

SQL インジェクション

クロスサイトスクリプティング

略称： XSS

入力データを無防備に HTML 出力　↓

ブラウザがタグとして解釈　↓

当然 <script> タグも有効　↓

閲覧したクライアント上で任意の JavaScript コードを実行させることができる

やってみよう

デモ

クロスサイトスクリプティング

JavaScript を実行されるとこんなに危険

クッキーの値を設定・取得できる

セッションハイジャック

意図しないページ遷移を起こさせる

クロスサイト・リクエスト・フォージェリ ( 後述 )

ページ全体を置き換える

フィッシング

フォームのアクションを書き換える

フォーム情報の不正取得

対策

表示するときは文字列をエスケープする

htmlspecialchars($value, ENT_QUOTES) ;

http://jp.php.net/htmlspecialchars

'&' ( アンパサンド ) は '&' になります。 ENT_NOQUOTES が設定されていない場合、 '"' ( ダブルクォート ) は '"' になります。 ENT_QUOTES が設定されている場合のみ、 ''' ( シングルクオート ) は ''' になります。 '<' ( 小なり ) は '<' になります。 '>' ( 大なり ) は '>' になります。

不十分な場合もある・１

タグの属性に出力する場合

<a href="{$url}">LINK</a> $url = htmlspecialchars( "javascript:alert(document.cookie)", ENT_QUOTES) ;

安全な URL であるかチェックする必要がある

IE のバグ： java script:alert()

不十分な場合もある・２

そもそも設計を見直すべき場合

それは本当に必要か？

入力に HTML タグを許可したい場合

結構大変

例：はてなダイアリーの場合

ホワイトリストで制限する

独自タグを実装する

あきらめる

まとめ

クライアントから送られてくる値は信用しない

$_GET, $_POST

$_REQUEST は使わないようにしよう

エスケープは表示する直前に行う

元データを加工してしまうと転用しづらい

私たちはケータイだから関係ないや

… と思わずしっかり対策する

クロスサイト・リクエスト・フォージェリ

略称：CSRF / XSRF

「しーさーふ」ってダサいよね

攻撃者が攻撃用のページを用意　↓

利用者がアクセスすること　↓

攻撃リクエストが送信される

やってみよう

デモ

クロスサイト・リクエスト・フォージェリ

恐ろしいところ：正規のリクエストと見分けがつかない

対策が大変

パスワードを再入力させる

CAPTCHA を使う

トークンを使う

トークン？CAPTCHA？

トークンって？

ユーザごとに固有の値

登録時に一度だけ生成する使い捨ての値

　ワンタイムトークン

CAPTCHA

こんなの

トークンによる対策の概要

フォームでトークン生成　↓

hiddenフィールドから一緒に送信

サーバ側でセッションに格納　↓

リクエストとセッションを突き合わせる　↓

合致したら正当なリクエストとして扱う

私たちは携帯向けサイトを作っている

cookieが使えない

セッションIDをURLで引き回すのも前時代的

webサーバが複数ある

PHP標準のセッション機能が使えない

油断しがち

「ソースが見えない」「パラメータは改竄できない」は幻想

対策いろいろ

端末識別 ID による認証

ケータイサイトでは基本

賛否両論ありますが…

クリティカルな箇所はトークン

チートページを作って自分自身のアカウントを攻撃　↓

自分のパラメータを書きかえられちゃうとマズー

DB 、 memcached などを使っていろいろ実装する必要がある

入力値のチェック

クライアントから送られてくる値は信用しない

$_GET, $_POST

$_REQUEST は使わないようにしよう

大事なことなので二回言いました

まとめ

いろいろ大変

手を抜くと被害が大きい

大変だが油断しないこと

人には言えない痛い目に遭ってます

SQLインジェクション

アプリケーションが想定しない SQL文を実行させること

デモスクリプトで削除に使ってるクエリ

$sql = "DELETE FROM bbs" . " WHERE id = { $_POST['id'] }" . " AND pass = '{$_POST['pass']}' " . " LIMIT 1" ;

見るからに危険

こんな攻撃ページを作った <form action="http://localhost/Part2/2-1.php" method="POST"> sql:<input type="text" name="id“ value=" 0 OR 1 # “ readonly="true" /><br /> <input type="submit" name="delete“ value="Do It!" /> </form>

やってみよう

デモ

SQLにパラメータを埋め込む

展開すると MySQLは[#]から行末までと [/* ～ */]がコメント

ということは…

DELETE FROM bbs WHERE id = 0 OR 1 # AND pass = '' LIMIT 1

対策

プリペアドステートメントとバインド使え。以上。

PHP 5.2以上は PDOで…

$sql = "DELETE FROM bbs" . " WHERE id = :id" . " AND pass = :pass " . " LIMIT 1" ; $pdo = new PDO($connection_param) ; $stmt = $pdo->prepare($sql) ; $stmt->bindParam(":id", $_POST['id'] , PDO::PARAM_INT) ; $stmt->bindParam(":pass", $_POST['pass'], PDO::PARAM_STR) ; $stmt->query() ;

使えない場合は？(数値型)

数値型は数値としての妥当性をチェックする

intval()

is_int()

is_numeric()

preg_match("/^[0-9]+$/", $param)

それぞれ挙動が違うので適切なものを利用する

使えない場合は？(文字列型・1)

データベース接続モジュールが提供するエスケープ関数を利用する

string mysql_escape_string( string $unescaped_string)

string pg_escape_string( [resource $connection], string $data)

使えない場合は？(文字列型・2)

自力でエスケープ

PostgreSQL は 8.1.4 から設定で「 ‘ 」を拒否できるようになった

「 '' 」を使うのが望ましい 1

\ ‘’ or ’ ‘ MySQL PostgreSQL ‘’ ‘ Oracle MS SQL DB2 エスケープ元の文字 DB

全体のまとめ

一番よくある攻撃３種類を簡単に紹介

攻撃されることを前提にした設計・コーディングを

リクエストパラメータは絶対に信用しない

攻撃者は執念深い

「ケータイだから」と油断は禁物

攻撃方法はこれだけじゃない

常に情報を収集する努力を

必読

PHPサイバーテロの技法 ―攻撃と防御の実際

社内蔵書にあるので必読

この本だけで十分とは言い切れないのが恐ろしい

リンク集

クロスサイトスクリプティング - Wikipedia

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0

クロスサイトリクエストフォージェリ - Wikipedia

http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%AA