気づけばプロ並みPHP 副読本：お助け電子BOOKへの寄稿の顛末
谷藤賢一さんの著書『気づけばプロ並みPHP~ショッピングカート作りにチャレンジ! 』に、発売1周年の謝恩キャンペーンとして『副読本：お助け電子BOOK』が公開されました(*1)。私はこの副読本の中で、『第2章 【徳丸 浩氏 スペシャル寄稿】安全なWebアプリケーションのために』を寄稿しています。このエントリでは、寄稿の顛末を報告したいと思います。 動機 私が本書『気づけばプロ並みPHP』を購入したのは昨年の10月29日ですから、本書が出版されてまもなく、今から約1年前です。私は本書を一読して、セキュリティ上の多数の問題があることに気がつきました。 以前は、セキュリティ上の問題が多い本は書評をブログ記事として書くことも多かったのですが、この際は書評という形にするのはためらいがありました。その理由は以下の様なものです。 私のブログの読者層はセキュリティに関心の高い方たちであり、本書の読者とは重
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
クッキーモンスターバグがあると、IPアドレス偽装防止のCSRF対策が回避される
日経Linux 2013年1月号に「“誤認逮捕”を防ぐWebセキュリティ強化術」を書き、それが今週4回連載で、ITproに転載されました。この中で、クロスサイトリクエストフォージェリ(CSRF)対策について説明しましたが、クッキーモンスターバグ(Cookie Monster Bug)がある場合に対策が回避されることに気がつきました。 それでは、どのような対策が望ましいかを考えてみると、中々難しい問題です。以下、その内容について検討します。 解決すべき課題の整理 記事の趣旨は、昨年無実の市民のパソコンからCSRFによる犯行予告が横浜市のサイトに書き込まれたことを受けて、サイト側でCSRF対策をして、なりすまし書き込みができないようにしようというものです。なりすましの犯行予告には、CSRFのほか、マルウェアを用いる方法、CSRF以外のWebサイトへの攻撃手法もあるので、CSRF対策だけで十分と
セッションフィクセイション脆弱性の影響を受けやすいサイトとは
最近、セッションフィクセイション脆弱性に対する関心がなぜか高まっています。同脆弱性は割合地味な脆弱性であり、話題になることはあまりありません。そこで、関心の高いこの時期に、セッションフィクセイション脆弱性の影響を受けやすいサイトについて説明し、注意を喚起したいと思います。 セッションフィクセイション脆弱性とは セッションフィクセイション（セッションIDの固定化）脆弱性は、なんらかの方法で利用者（被害者）のブラウザ上でセッションIDを強制的に指定して、その後利用者がログインしたタイミングで、攻撃者が「ログイン済みのセッションID」を知ることができるという脆弱性です。「安全なウェブサイトの作り方(改訂第五版)」P17から図を引用します。 図の「2.何らかの方法で自分が取得したセッションIDを利用者に送り込む」手法は、安全なウェブサイトの作り方では説明されていません。そこで、以下に「セッションI
Tポイントツールバーを導入するとSSL通信の履歴までもが盗聴可能になる
twitterなどでTポイントツールバーの利用規約が話題になっています。このエントリでは、Tポイントツールバーを実際に導入して気づいた点を報告します。結論として、当該ツールバーを導入すると、利用者のアクセス履歴（SSL含む）が平文で送信され、盗聴可能な状態になります。 追記(2012/08/10 20:10) たくさんの方に読んでいただき、ありがとうございます。一部に誤解があるようですが、ツールバーが送信している内容はURLだけで、Cookieやレスポンスまでも送信しているわけではありません。URLを送信するだけでも、以下に示す危険性があるということです。 追記終わり 追記(2012/08/13 23:50) ポイントツールバーにバージョンアップがあり、WEB閲覧履歴の送信がSSL通信に変更されました。従って、WEB閲覧履歴が盗聴可能な状況は回避されました。本日22:50頃確認しました。
PHPの入門書を書くことになりました&レビュアー募集のお知らせ
PHPの入門書をソフトバンククリエイティブさん出すことになりました。かねがね、PHPの入門書がよろしくないという問題意識を持ち、かつ色々な場でお話ししておりましたが、またしても「言い出しっぺの法則」が発動して、自分で書くことになりました。 PHPの入門書を（たぶん）10冊以上読んで（あるいは眺めて）、以下のような感触を持っています。 ものすごく初歩的な本は悪くないが、行き着くゴールが極めて限定される SQLなどまで行き着く入門書は、後述する欠点を持つ傾向がある 中級者・上級者向けについては、良いものが出て来た PHP入門書の欠点というのは以下のようなものです。私の読んだPHP入門書は、次のいずれかに該当します。 執筆者のスキルが低いために説明やサンプルの品質が低い 執筆者のスキルは高いはずだが、説明のスキルが低く、不正確 執筆者のスキルが高く説明も正確だが、初心者には難しく入門書でなくなっ
COOKPADの「伏せ字にせず入力」ボタンは素晴らしい
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです（P337～P338）。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な（危険な）パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)
CGI環境でPHPを動作させているサイトには、リモートからスクリプト実行を許してしまう脆弱性があります。php.netから提供されている修正リリース(PHP 5.3.12 / PHP 5.4.2)は不完全なため、該当するサイトは至急回避策を導入することを推奨します。 概要 CGIの仕様として、クエリ文字列に等号を含めない場合は、クエリ文字列がCGIスクリプトのコマンドライン引数として指定されます。 例えば、http://example.jp/test.cgi?foo+bar+bazという呼び出しに対しては、test.cgiは以下のコマンドラインで呼び出されます。 test.cgi foo bar baz この仕様を悪用して、CGI版のPHPにコマンドライン引数としてPHPのオプションを指定できます。例えば、http://example.jp/test.php?-s というリクエストは、-s
hashdos攻撃をmod_securityで防御する(CentOS+yum編)
このエントリでは、hashdos対策としてのmod_securityの導入と設定の方法を説明します。CentOS環境でyumによりApacheを導入しているサイトに対して、yumによりmod_securityを導入するというシナリオで説明します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。まだhashdosによる攻撃事例は報告されていないようですが、既に攻撃コード（PoC）が公表されているため、いつ攻撃が起こっても不思議ではない状況です。 PHPも影響を受けるプラットフォームであり、PHP5.3.9で対処予定となっていますが、まだPHP5.3.9はリリースされて
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_
PostgreSQLは標準でバックスラッシュをエスケープしない仕様になった
PostgreSQL9.1の仕様変更にて、デフォルト時の設定として、standard_conforming_stringsがonとみなされるようになりました。この仕様変更により、デフォルト設定でのPostgreSQLは、バックスラッシュをエスケープする必要がなくなり、ISO規格のSQLと同様のエスケープルール（シングルクォートを重ねるのみ）となります。 PostgreSQLの文字列リテラルは、元々MySQL同様に、バックスラッシュをエスケープする仕様でした。その後、リリース8.1にて、設定パラメータ standard_conforming_strings が追加され、この値が on の場合、バックスラッシュをエスケープしない（ISO規格と同様の）仕様となりました。従来のリリースでは、standard_conforming_stringsを指定しない場合offとみなされていました。これは、後
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関数のバグはこうして生まれた
昨日のブログエントリ「PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)」にて、crypt関数の重大な脆弱性について報告しました。脆弱性の出方が近年まれに見るほどのものだったので、twitterやブクマなどを見ても、「どうしてこうなった」という疑問を多数目にしました。 そこで、このエントリでは、この脆弱性がどのように混入したのかを追ってみたいと思います。 PHPのレポジトリのログや公開されているソースの状況から、PHP5.3.7RC4までこのバグはなく、PHP5.3.7RC5でこのバグが混入した模様です。RC5はPHP5.3.7最後のRelease Candidateですから、まさに正式リリースの直前でバグが入ったことになります。 バグの入る直前のソースは、ここの関数php_md5_crypt_rから参照することができます。以下に、おおまかな流れを図示します。まずはバ
ぼくがPDOを採用しなかったわけ(Shift_JISによるSQLインジェクション)
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2010年7月1日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり PHPのデータベース・アクセス・ライブラリPDOは、DB接続時の文字エンコーディング指定ができないため、文字エンコーディングの選択によっては、プレースホルダを使っていてもSQLインジェクション脆弱性が発生します。 追記(2011/06/19) ここに来て急にブクマが追加されはじめていますが、このエントリを書いてから状況が改善しています。PHP5.3.6(2011/03/17)にて、PDOでもデータベース接続の文字エンコーディングを指定できるようになりました。この版で、UNIX版のPHPでは解決しましたが、Win
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
