『例えば、PHPを避ける』以降PHPはどれだけ安全になったか
この記事はPHPアドベントカレンダー2014の22日目の記事です 。 2002年3月に公開されたIPAの人気コンテンツ「セキュアプログラミング講座」が2007年6月に大幅に更新されました。そして、その一節がPHPerたちを激しく刺激することになります。 (1) プログラミング言語の選択 1) 例えば、PHPを避ける 短時日で素早くサイトを立ち上げることのみに着目するのであれば、PHPは悪い処理系ではない。しかし、これまで多くの脆弱性を生んできた経緯があり、改善が進んでいるとはいえまだ十分堅固とは言えない。 セキュアプログラミング講座（アーカイブ）より引用 「PHPを避ける」とまで言われてしまったわけで、当然ながらネット界隈では炎上を起こし、現在はもう少しマイルドな表現に変わっています(参照)。 本稿では、当時のPHPの状況を振り返る手段として、この後PHPのセキュリティ機能がどのように変化
twitterに学ぶなりすまし投稿対策
先日もtwitter上の犯行予告により20歳の青年が逮捕されたようですが、なりすましによる誤認逮捕ではなかったのか気になるところです。そこで、twitterが、なりすまし投稿をどの程度対策しているかを調べてみることにしました。twitterの安全性を確認することが目的というよりも、twitterが実施している対策を知ることにより、皆様のWebサイトを安全にする参考にしていただければと思います。 今回調べた「なりすまし投稿」の手法は下記の通りです。 クロスサイト・リクエスト・フォージェリ(CSRF) クロスサイトスクリプティング（XSS） HTTPヘッダーインジェクション クリックジャッキング DNSリバインディング クッキーモンスターバグ このうち、上の5つの解説は拙稿「“誤認逮捕”を防ぐWebセキュリティ強化術」、最後のクッキーモンスターバグについては、過去のエントリ「クッキーモンスター
ログアウト機能の目的と実現方法
このエントリでは、Webアプリケーションにおけるログアウト機能に関連して、その目的と実現方法について説明します。 議論の前提 このエントリでは、認証方式として、いわゆるフォーム認証を前提としています。フォーム認証は俗な言い方かもしれませんが、HTMLフォームでIDとパスワードの入力フォームを作成し、その入力値をアプリケーション側で検証する認証方式のことです。IDとパスワードの入力は最初の1回ですませたいため、通常はCookieを用いて認証状態を保持します。ログアウト機能とは、保持された認証状態を破棄して、認証していない状態に戻すことです。 Cookieを用いた認証状態保持 前述のように、認証状態の保持にはCookieを用いることが一般的ですが、Cookieに auth=1 とか、userid=tokumaru などのように、ログイン状態を「そのまま」Cookieに保持すると脆弱性になります
IPAから『DOM Based XSS』に関するレポート出ました
DOM Based XSSに関しては、IPA「安全なウェブサイトの作り方」でも、拙著でもごく簡単にしか触れておらず、まとまった解説が要望されていましたが、本日（2013年1月29日）にIPAから「IPA テクニカルウォッチ『DOM Based XSS』に関するレポート」が公開されました。 同冊子の目次は下記の通りです。 はじめに 1. DOM Based XSSの概要 2. IPAに報告されたDOM Based XSSの脆弱性 3. DOM Based XSSの事例 4. DOM Based XSSの対策方法 コラム おわりに IPAのレポートと言うことで、DOM based XSSの届出の状況も説明されています。以下にグラフを引用します。 一見して「急増」していることと、昨年の10月から12月の3ヶ月で92件も届出があったということで、対策が急務となっている状況が見て取れます。これは、こ
Ruby on Railsのfind_by_*メソッドにSQLインジェクション脆弱性(CVE-2012-5664) | 徳丸浩の日記
Ruby on Rails(3.2.9, 3.1.8, 3.0.17以前)のfind_by_*メソッドにSQLインジェクション脆弱性が見つかりました(CVE-2012-5664)。このエントリではその概要と対策について説明します。 概要 Ruby on Railsのfind_by_*メソッドの引数としてハッシュを指定することで、任意のSELECT文を実行できる脆弱性があります。 検証 Ruby on Rails3.2.9の環境を用意して、以下の2つのモデルを用意しました。 $ rails g scaffold user name:string email:string $ rails g scaffold book author:string title:string モデルUserは個人情報を保持しており、自分自身の情報のみが閲覧できるという想定です。モデルBookは書誌データベースであ
セキュリティ情報:PHP5.4.8、PHP5.3.18以前にhashdos脆弱性
チェック用スクリプト hashdosの状態を確認するためのスクリプトを作成してみましたので、Webサイトのチェックにご活用下さい。 このスクリプトを任意のファイル名（PHPスクリプトとして実行できる拡張子）でチェック対象Webサーバーに保存して下さい。Webブラウザを用いて、このスクリプトを実行すると、結果が表示されます。JavaScriptを有効にして下さい。チェック終了後はスクリプトを削除して下さい。 <?php if (@$_GET['mode'] === 'check') { header('Content-Type: text/plain'); echo (int)count($_POST); exit; } $max_input_vars = ini_get('max_input_vars'); $postnumber = (int)$max_input_vars + 10;
PHPの入門書を書くことになりました&レビュアー募集のお知らせ
PHPの入門書をソフトバンククリエイティブさん出すことになりました。かねがね、PHPの入門書がよろしくないという問題意識を持ち、かつ色々な場でお話ししておりましたが、またしても「言い出しっぺの法則」が発動して、自分で書くことになりました。 PHPの入門書を（たぶん）10冊以上読んで（あるいは眺めて）、以下のような感触を持っています。 ものすごく初歩的な本は悪くないが、行き着くゴールが極めて限定される SQLなどまで行き着く入門書は、後述する欠点を持つ傾向がある 中級者・上級者向けについては、良いものが出て来た PHP入門書の欠点というのは以下のようなものです。私の読んだPHP入門書は、次のいずれかに該当します。 執筆者のスキルが低いために説明やサンプルの品質が低い 執筆者のスキルは高いはずだが、説明のスキルが低く、不正確 執筆者のスキルが高く説明も正確だが、初心者には難しく入門書でなくなっ
COOKPADの「伏せ字にせず入力」ボタンは素晴らしい
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです（P337～P338）。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な（危険な）パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
さくらDNSにサブドメインハイジャックを許す脆弱性
さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。 DNSサービスへのドメイン登録時における不具合について 障害内容 : 当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。 本問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。 この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。 (12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日（6月13日）には改修されましたので
情報処理試験問題に学ぶJavaScriptのXSS対策
指摘事項A中の(a)は、他を見なくても「セキュア」属性だと分かりますね。徳丸本（体系的に学ぶ 安全なWebアプリケーションの作り方）では、4.8.2クッキーのセキュア属性不備(P209)に説明があります。 指摘事項Bは、ここだけ読むと、XSSのようでもあり、サーバーサイドのスクリプトインジェクションのようでもありますが、検査ログからXSSであることがわかります（下図はIPAからの引用）。XSSは、徳丸本4.3.1クロスサイトスクリプティング（基本編）と4.3.2クロスサイトスクリプティング（発展編）にて説明しています。 ここまでは、ごく基本的な問題ですが、問題文P6に出てくる以下の部分は、少しだけひねってますね。 このプログラムは、利用者が入力した文字列をダイアログに表示するために、受け取ったパラメタの値をスクリプトに埋め込み、動的にスクリプトを生成する。図4の( c )行目では
「クロスサイトスクリプティング対策」でGoogle検索して上位15記事を検証した
昨年の11月にブログエントリ『「SQLインジェクション対策」でGoogle検索して上位15記事を検証した』という記事を書いたところ、非常に好評で、「次はXSSについて書いてください」という要望をいただいておりました。中々XSSについては手がついておりませんでしたが、ようやく書いてみました。以下のURLで検索した結果の上位15位の記事を検証しました。 http://www.google.co.jp/search?q=クロスサイトスクリプティング対策&pws=0 検索結果は変動するため、私が検索した際の結果をEvernoteの公開ノートとして記録しています。 1～10位 11～20位 記事の「正しさ」の検証基準としては、IPAの「安全なウェブサイトの作り方改訂第5版」を参考に、最低限として以下が記述されているかどうかを確認しました。 HTMLのエスケープ処理を行う 属性値はダブルクォートで囲む
PHPのescapeshellcmdを巡る冒険
以前、ブログ記事「PHPのescapeshellcmdの危険性」にて、escapeshellcmd関数の「余計なお世話」によって危険性が生まれていることを指摘しましたが、その後大垣さんによって修正案が提示され、結局「それはマニュアルの間違い」ということで決着が着いたようです。ところが、この議論とは別のところで、escapeshellcmdはPHP5.4.0で挙動が少し変わっていることが分かりました。 経緯 2011/1/1 徳丸が「PHPのescapeshellcmdの危険性」を書いて、クォート文字がペアになっている場合にエスケープしないという仕様が余計なお世話であり、危険性が生じていることを指摘 2011/1/7 大垣さんがブログエントリ「phpのescapeshellcmdの余計なお世話を無くすパッチ」にて修正案を提示 2011/10/23 廣川さんが、大垣さんのパッチ案を少し修正して
悪いサニタイズ、良い(?)サニタイズ、そして例外処理
先日のエントリ「処理開始後の例外処理では「サニタイズ」が有効な場合もある」は、素材の消化不足、私の表現の未熟等から、一部で誤解を招いてしまったようで申し訳ありません。アプローチを変えて、サニタイズについてもう一度考えてみたいと思います。結論から言えば、悪いサニタイズはあっても、「良いサニタイズ」はないと考えます。しかしながら、状況によっては妥協の産物としてサニタイズを使うことは、あり得ると考えます。 本稿で用いる「サニタイズ」の定義 サニタイズという用語は、歴史的に都合の良いように使われてきた歴史があり、あらためてネット検索して見ると、本当に多様な使われ方をしていると感じました。その様子は、高木浩光氏のブログ記事『「サニタイズ」という言葉はもう死んでいる』からも伺えます。 ここでは、議論の都合上、以下をサニタイズの定義として用いることにします。 サニタイズとは、 主にセキュリティ上の目的で
処理開始後の例外処理では「サニタイズ」が有効な場合もある
このエントリでは、脆弱性対処における例外処理について、奥一穂氏(@kazuho)との会話から私が学んだことを共有いたします。セキュアプログラミングの心得として、異常が起これば直ちにプログラムを終了することが推奨される場合がありますが、必ずしもそうではないというのが結論です。 はじめに Webアプリケーションの脆弱性対策では、脆弱性が発生するのはデータを使うところであるので、データを使う際の適切なエスケープ処理などで対処するのがよいと言われます。しかし、処理内容によってはエスケープができない場合もあり、その場合の対処についてはまだ定説がないと考えます。 エスケープができない場合の例としては、以下があります。 SQLの数値リテラルを構成する際に、入力に数値以外の文字が入っていた メール送信しようとしたが、メールアドレスに改行文字が入っていた 入力されたURLにリダイレクトしようとしたところ、U
Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
28C3(28th Chaos Communication Congress)において、Effective Denial of Service attacks against web application platforms（Webプラットフォームに対する効果的なサービス妨害攻撃）と題する発表がありました（タイムスケジュール、講演スライド）。 これによると、PHPをはじめとする多くのWebアプリケーション開発プラットフォームに対して、CPU資源を枯渇させるサービス妨害攻撃(DoS攻撃)が可能な手法が見つかったということです。この攻撃は、hashdos と呼ばれています。 概要PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には
PHP5.4のhtmlspecialcharsに非互換問題
第3引数を指定していない場合の影響前述のように、htmlspecialchars関数の第3引数を指定していない場合、PHP5.3までは、文字エンコーディングがISO-8859-1が指定されたとみなされます。この場合、入力内容にかかわらず不正な文字エンコーディングと判定されることはありません。したがって、文字エンコーディングのチェックが働かない代わりに、エラーになることもありませんでした。 これに対して、PHP5.4の仕様により文字エンコーディングがUTF-8とみなされた場合に、Shift_JISやEUC-JPの2バイト文字が入力されると、高い確率で「UTF-8として不正」というエラーになり、htmlspecialchars関数の出力は空になります。つまり、プログラムが正常に動作しません。 htmlspecialchars関数の第3引数を指定しておらず、内部文字エンコーディングがShift_
都道府県型JPドメインがCookieに及ぼす影響の調査
JPRSからのプレスリリース『JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定』や報道などで「都道府県型JPドメイン」というものが新設されることを知りました。 都道府県型JPドメインとは、現在活発に使われていない地域型ドメインを活性化する目的で、地域型ドメインの制約（ドメイン名が長い、一人・一団体あたり1つまで）を簡略化しようというもののようです。 しかし、現在の地域型ドメインは、ブラウザにとって処理がややこしいもので、IEなどは昔からまともに対応していません。このため、Cookie Monster Bugという脆弱性になっているという経緯があります。このルールをさらに複雑にすることになるということから、ブラウザセキュリティに関心の高い人たちが騒ぎ始めています。 そこで、高木浩光氏の日記「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」の以
Apache killerは危険～Apache killerを評価する上での注意～
Apacheの脆弱性(CVE-2011-3192)いわゆるApache killerが話題になっていますが、その脅威については一部誤解があるようです。 以下は、非常に脅威とする報告の例です。 一方今回のはプロセスの肥大化を伴うので、実メモリ消費して更にスワップも使い尽くしてOS毎激重になったあげくLinuxとかの場合はOOM Killer発動と、他のプロセスや場合によってはOSを巻き込んで逝ってしまいます。 CVE-2011-3192 Range header DoS vulnerability Apache HTTPD 1.3/2.xより引用 以下は、それほど脅威でなかったとする報告の例です。 pooh.gr.jp は結構頑丈だったので 60 並列でやっと CPU idle 30% まで減らせた。 Apache Killer (CVE-2011-3192) 対策 for CentOS 5
PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
PDOにおける一応の安全宣言と残る問題点
8月18日にPHP5.3.7がリリースされました。このリリースにより、PDOのSQLインジェクションの問題が一応解決されたと判断しましたので、ここに「一応の安全宣言」を表明するとともに、残る問題について報告します。 PDOの問題とは何か 以前、ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)にて報告したように、PHP5.3.5以前のPDOにはDB接続時に文字エンコーディングを指定する機能がないため、文字列リテラルのエスケープの際に文字エンコーディングをLatin1を仮定してしまうという問題がありました。この状態ですと、DBにShift_JISで接続している際に、SQLインジェクション脆弱性が混入しました。 ※ 実は、先のエントリの「追記(2010/07/01 22:20)」に紹介した方法で文字エンコーディングを指定できるのですが、ほとんど知られていないのと
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
