書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 | 徳丸浩の日記
図のように、大垣本のCSRF対策方式（以下、「大垣方式」と表記）では、トークン（同書ではフォームIDと表記）をランダムな鍵として生成（②）し、それをフォームの隠しフィールドとDBに保存します（③、④）。ユーザーがフォームをサブミット（⑤）すると、送信されてきたトークンがDB上に存在するか確認（⑥）し、あればトークンを削除（⑦）して、サーバー上の処理に進みます。⑥でトークンがDBにない場合は、エラーとして処理には進みません。 一般的なCSRF対策手法との違い 大垣方式が一般的なCSRF対策と異なる点は以下の2点です。 フォームの2重投稿防止機能を兼ねている トークンがセッション変数ではなくDBに保存される トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CR
JSON SQL Injection、PHPならJSONなしでもできるよ
DeNAの奥さんと、はるぷさんがJSON SQL Injectionについて公表されています。 The JSON SQL Injection Vulnerability 不正なJSONデータによるSQL Injectionへの対策について (Json.pm+SQLクエリビルダー) 上記の記事は、主にPerlスクリプトがJSONデータを受け取るシナリオで説明されています。もちろん、この組み合わせに限定したはなしではないわけで、それではPHPではどうだろうと思い調べてみました。 JSON SQL Injectionとは 以下、はるぷさんの「不正なJSONデータによる…」にしたがってJSON SQL Injectionについて説明します。 Perl向けのSQLジェネレータの一つであるSQL::Makerにおいて、以下のスクリプトを想定します。 my ($sql, @bind) = $builde
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
PHPのセッションIDは暗号論的に弱い乱数生成器を使っており、セッションハイジャックの危険性がある : DSAS開発者の部屋
下記の文章は、PHPのセッションIDに対する攻撃についてFull Disclosure MLに2010年に投稿された文章を和訳したものです。訳者の意見としては、攻撃の成立条件は極めて厳しく、そこまで深刻度は高くないと考えています。 とはいえ、疑似乱数列への攻撃がどのように行われるのか、その可能性を示す文章は比較的珍しいもののように思います。暗号論的に安全な疑似乱数とは何か、なぜ必要なのかといった内容を間接的に教えてくれる面白い文章だと感じましたので、今回翻訳してみました。 （以下、原文の和訳です） 原文：http://seclists.org/fulldisclosure/2010/Mar/519 Advisory (c) 2010 Andreas Bogk <andreas () andreas org> Product:PHP Version:5.3.2 以降 脆弱性の種類:暗号論的な
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
facebookにPHP CGIの脆弱性を試してみたら面白い対策がされていた！！ - cakephperの日記(CakePHP, Laravel, PHP)
PHPに新たな脆弱性が見つかって、CGIモードで動作するPHPの場合コマンドライン引数がHTTP経由で渡せてしまうため、-sオプションを渡すとPHPのソースコードが丸見えになるというのが話題になってます。(-sオプションはhtmlでシンタックスハイライトまでしてくれてコードが見やすくなる) そこでFacebookに向けてこれを試してみると・・・ https://www.facebook.com/?-s こんな情報が！！ <?php include_once 'https://www.facebook.com/careers/department?dept=engineering&req=a2KA0000000Lt8LMAS'; このURLにアクセスすると、セキュリティエンジニアの求人情報ページに行きます :) おしゃれー
不適切な脆弱性情報ハンドリングが生んだ WordPress プラグイン cforms II のゼロデイ脆弱性 - co3k.org
2012/02/15、 JVN から JVN#35256978: cforms II におけるクロスサイトスクリプティングの脆弱性 が公開されました。これはクレジットされているとおり、海老原と、同僚の渡辺優也君が勤務中に発見した脆弱性です。 脆弱性自体はどこにでもあるような普通の XSS ですが、実はこの脆弱性、 2010 年 10 月に exploit コードが公開され、それから 1 年 4 ヶ月後の 2012 年 2 月まで修正版が提供されていなかったものです。 このような危険な状態が長期間続いていたのには、様々な理由があります。ここでは、その説明と、どうすれば事態が防げたかということについて検討したいと思います。 脆弱性の概要 本題に入る前に、主に cforms II のユーザ向けに脆弱性自体の概要についてざっくり説明します。前述のとおり、未修正の状態で exploit コードが公開
ウェブルの関連サービスが改竄され不正なコードが挿入された件の報告 | ウェブル
特定の共用サーバーに入っている、私の一部のサイトが WordPress プラグインの phpMyAdmin を経由して改竄されましたのでご報告します。この期間に該当するサイトを閲覧された方はウィルスに感染していないか調べてみてください。 改竄されたサイト一覧 ウェブル ウェブルニュース Webデザインサンプル 食品栄養素データベース 顔文字データバンク 学習型しりとり アニメマップ（メインサイトのみ） 発生期間について 2012年1月16日18時頃に改竄され、2012年1月17日20時より大まかな除去が完了。全ての改竄されたファイルの除去に2012年1月20日15時に完了しました。この期間にウェブル運営のサイトを閲覧された方はウィルスに感染していないかお使いのパソコンをチェックしてください。 改竄された原因について WordPress プラグインの WP-phpMyAdmin の setu
PHPのイタい入門書を読んでAjaxのXSSについて検討した(2)～evalインジェクション～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。タイトルはXSSとなっていますが、今回紹介する脆弱性はXSSではありません。 作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（本書P20の図1-23）。 Ajaxのアプリケーションでは、XMLHttpRequestメソッド等でデータを要求し、サーバーはXML、JSON、タブ区切り文字列など適当な形式で返します。ブラウザ側JavaScriptでは、データ形式をデコードして、さまざまな処理の後、HTMLとして表示します。以下に、Ajaxのリクエストがサーバーに届いた後の処理の流れを説明します。 サーバー側でデータを作成、取得 データ伝送用の形式（XML、JSON、タブ区切り文字列等）にエンコード
最近発覚したパスワードに関する重大な脆弱性4選 - ockeghem's blog
最近、パスワードにまつわる重大な脆弱性を見かけることが多いように思いますので、その中から4つを選んで紹介します。既に私のブログで紹介したものや、少し古い問題も含まれます。 PHP5.3.7のcrypt関数がハッシュ値を返さない脆弱性 crypt関数は、様々なハッシュアルゴリズムによるソルト化ハッシュを返す関数ですが、PHP5.3.7（2011年8月18日リリース）において、crypt関数にMD5を指定した場合、ハッシュ値を返さない（ソルトは返す）バグがありました。私のブログエントリにて説明したように、最悪ケースでは任意のパスワードで認証できてしまう状況があり得ました。 PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439) | 徳丸浩の日記 PHP :: Bug #55439 :: crypt() returns only the salt for MD5 このバグが混入
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から参照することができます。以下に、おおまかな流れを図示します。まずはバ
PHPにおけるファイルアップロードの脆弱性CVE-2011-2202 - ockeghem's blog
PHPの現行バーション（PHP5.3.6以前）には、ファイルアップロード時のファイル名がルート直下の場合、先頭のスラッシュを除去しないでファイル名が渡される問題があります。CVE-2011-2202として報告されています。 後述するように影響を受けるアプリケーションは少ないと思われますが、念のためアプリケーションの確認を推奨します。また、次バージョンPHP5.3.7のRC1で修正されていることを確認しましたので、PHP5.3.7正式版が公開され次第、できるだけ早期に導入することを推奨します。 ※このエントリは、http://blog.tokumaru.org/2011/06/PHP-file-upload-bug-CVE-2011-2202.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。
PHPで誰でも簡単Webサービス製作！でなんか作って公開した奴ちょっと来い - 甘味志向＠はてな
タイトルは出来れば関連する方に読んで欲しかったので、軽く釣り針にしました。すみません。:*) 最近はやりのヒウィッヒヒー（Twitter）でも、よく「○○ったー」みたいなサービスがばんばん登場してますね！ おかげでますますツイッターが面白い感じになってて、いい流れですね！ でも･･･ちょっと気になることが･･･ 最近「もうプログラマには頼らない！簡単プログラミング！」だとか･･･ 「PHPで誰でも簡単Webサービス作成！」だとか･･･ はてなブックマークのホッテントリで見かけますよね･･･ プログラミングする人が増えるのは素敵です！レッツ･プログラミングなう！ なんですけど･･･ ちゃんとセキュリティのこと考えてますか･･･！？ 『セキュリティ対策とか難しいし面倒くせーし、俺の適当に作ったサービスとかどうなってもイイしｗｗ』 いいんですいいんです！ 別にそう思ってるならどうでもいいんです！
Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PHPでセキュリティを真面目に考える
IBM Developer
PHPでのセキュリティ対策についてのメモ - Liner Note