PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 - 徳丸浩の日記(2011-03-29)
_PDO/MySQL(Windows版)の文字エンコーディング指定の不具合原因 前回のブログ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり」にて、PHP5.3.6（本エントリ執筆時点での最新版）からPDOにてサポートされた文字エンコーディング指定がWindows版では正しく動作しないことを報告しました。Linuxでは正常に動作するので不思議だなという話になっていたのですが、千葉征弘さん(@nihen)が調べてくださった結果がtwitter上で発表されました（toggerによるまとめ「PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合にまつわる件」）。この件につき、当ブログでも報告します。 問題点の復習 PHP5.3.6以降のPDOでは、データベースに接続する際の文字エンコーディングを
PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり - 徳丸浩の日記(2011-03-22)
_PHP5.3.6からPDOの文字エンコーディング指定が可能となったがWindows版では不具合（脆弱性）あり PHP5.3.6からPDO/MySQLにてデータベースの接続文字列にて文字エンコーディングが指定可能となりました。この機能を検証した結果、Linux上では正常な動作を確認しました。Windows版でも一見動作するようですが、動的プレースホルダ内部のエスケープ処理に不備があり、Shift_JISでデータベースと接続している際にSQLインジェクション脆弱性の可能性があります。 きっかけ @haruyamaさんのツイートがきっかけで、PHP5.3.6からPDOの文字エンコーディング指定が有効となったことを知りました。 PHP 5.3.6以降では PDO/MySQLのDSNでのcharset指定が有効になったようです. (MySQL 4.1.11以降, MySQL 5.0.7以降, もし
問題点の概要 - 「PHPで作成する携帯会員サイトの基本」の諸問題(1) - 徳丸浩の日記
_問題点の概要 CodeZineから発表されている「PHPで作成する携帯会員サイトの基本」という記事はツッコミどころ満載で、既にいくつかの問題が修正されているのだが、まだ残っている問題があることや、修正内容にも疑問があるので、いくつか指摘してみたい。ざっと書いたところ、ものすごく長くなりそうだったので、小出しで「連載」の形で書く。忙しいので途中でやめるかもしれない。今回は、問題点の概要を報告する。 くだんの記事をざっと見たところ、以下の問題を見つけた。 IPアドレス制限のない「かんたんログイン」 Net_UserAgent_Mobileを用いて携帯電話の端末IDを取り出し、かんたんログインを実装しているが、ゲートウェイのIPアドレス経由であることを確認していない。以下のリストは、端末IDを取り出しているところ（4ページ目）。 $agent = Net_UserAgent_Mobile::s
JavaアプレットのDNSリバインディングはJRE側で対策済みだった - 徳丸浩の日記
Black Hat Japan 2007における金床氏のプレゼンテーションや金床本で、Javaアプレットに対するDNSリバインディングの手法が説明されている。ここしばらく、その追試を行っていた。結論としては、金床氏の方法にはJRE側で対策がとられていたので報告する。 金床氏が報告しているDNSリバインディングの手法とは以下のようなものだ（金床本に説明されている方法）。 被害者のユーザにワナのページをPROXY経由で閲覧させる ワナのドメイン(FQDN)に対するIPアドレスを変更する ワナページ上で数秒～数十秒のちにJavaScriptによりJavaアプレット用のHTMLをレンダリングする JREがアプレットをPROXY経由で*1ダウンロードする アプレットのダウンロード時点で既にDNSレコードは書き換わっているが、PROXYがDNSキャッシュしているため、アプレットは正常にダウンロードされ
ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された - 徳丸浩の日記(2010-02-22)
_ケータイtwitter(twtr.jp)においてDNS Rebinding攻撃に対する脆弱性を発見・通報し、即座に修正された twitterのケータイ版twtr.jpにおいて、DNS Rebindingによるなりすましを許す脆弱性が発見され、1/15に通報したところ、その日のうちに修正された。以下、その経緯について報告する。 経緯 今年の1月12日に読売新聞の記事が出たのを受けて、現実のサイトはどうなのだろうかと改めて気になった。 ＮＴＴドコモの携帯電話のうち、インターネット閲覧ソフト「ｉモードブラウザ２・０」を搭載した最新２９機種を通じて、利用者の個人情報を不正取得される恐れのあることが、専門家の指摘で明らかになった。 同社は携帯サイトの運営者にパスワード認証などの安全対策を呼びかけている。携帯電話の機能が高機能化するにつれ、こうした危険は増しており、利用者も注意が必要になってきた。
DNSリバインディング: かんたんログイン手法の脆弱性に対する責任は誰にあるのか - 徳丸浩の日記(2010-02-12)
_かんたんログイン手法の脆弱性に対する責任は誰にあるのか id:ikepyonの日記経由で、NTTドコモのサイトに以下のセキュリティ・ガイドラインが掲示されていることを知った。 iモードブラウザ機能の多様化により、機種によってiモードサイトにおいてもJavaScriptを組み込んだ多様な表現、CookieやReferer情報を有効に活用したサイト構築が行えるようになりました。 しかし、PC向けインターネットサイト同様に、セキュリティ対策が十分に行われていないサイトでは、そのサーバの脆弱性を突き（クロスサイトスクリプティング、SQLインジェクション、DNSリバインディングなど様々な攻撃手法が存在しています）、これらの機能が悪用される危険性があります。十分にご注意ください。 [作ろうiモード：iモードブラウザ | サービス・機能 | NTTドコモより引用] XSSやSQLインジェクションと並ん
徳丸浩の日記 - iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった
_iモードブラウザ2.0のXMLHttpRequestでPOSTデータの扱いが困難になった このエントリでは、iモードブラウザ2.0の制限により、XMLHttpRequestでPOSTメソッドの利用が困難になっていることを確認したので報告する。 iモードブラウザ2.0のJavaScriptを試していて、POSTメソッドでデータが渡せていないことに気がついた。以下のようなプログラムで検証してみた。 【post.html】 <html> <head> <script> function test() { try { var requester = new XMLHttpRequest(); requester.open('POST', '/dumppost.php', true); requester.onreadystatechange = function() { if (requeste
[Perl][PHP][SQL]: quoteメソッドの数値データ対応を検証する - 徳丸浩の日記(2009-10-19)
_quoteメソッドの数値データ対応を検証する このエントリでは、PerlのDBI、PHPのPDO、MDB2にて用意されているquoteメソッドが数値データをどのように扱えるかを検証しました。結論としてMDB2が合格、それ以外は不合格で、とくにDBD::mysqlを使用した場合、脆弱性といってもよいような結果となりました。 概要 DBI、PDO、MDB2は、いずれもデータベースアクセスを抽象化したモジュール(クラス)であり、汎用的な記述によりさまざまなデータベースを利用できるように工夫されています。これらモジュール(クラス)にはquoteというメソッドが用意されています。DBIのquoteメソッドの呼び出し例を示します。 my $dbh = DBI->connect('DBI:mysql:dbname:localhost', 'user', 'pass'); print $dbh->quo
論点の整理: 文字エンコーディングバリデーションは自動化が望ましい - 徳丸浩の日記(2009-09-18)
_文字エンコーディングバリデーションは自動化が望ましい 私が9月14日に書いたブログエントリPHP以外では - 既にあたり前になりつつある文字エンコーディングバリデーションに対して、大垣靖男さんから名指しで「セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?」というエントリを頂戴しましたので、それに回答する内容を書きたいと思います。 まずは論点の整理から始めます。 合意していると思われる内容 まずは合意できていると思われる内容から書き始めたいと思います。以下の内容は、大垣さんと私で合意事項だと考えています。 論点1.文字エンコーディングの問題によるセキュリティ上の脅威がある 論点2.文字エンコーディングに起因するセキュリティ上の問題に対して、文字エンコーディングのバリデーションが有効である 論点3.Webアプリケーションによっては文字エンコーディングのバリデーションが不
PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14)
_既にあたり前になりつつある文字エンコーディングバリデーション 大垣靖男さんの日記「何故かあたり前にならない文字エンコーディングバリデーション」に端を発して、入力データなどの文字エンコーディングの妥当性チェックをどう行うかが議論になっています。チェック自体が必要であることは皆さん同意のようですが、 チェック担当はアプリケーションか、基盤ソフト（言語、フレームワークなど）か 入力・処理・出力のどこでチェックするのか という点で、さまざまな意見が寄せられています。大垣さん自身は、アプリケーションが入力時点でチェックすべきと主張されています。これに対して、いや基盤ソフトでチェックすべきだとか、文字列を「使うとき」にチェックすべきだという意見が出ています。 たとえば、id:ikepyonの日記「[セキュリティ]何故かあたり前にならない文字エンコーディングバリデーション」では、このチェックは基盤ソフ
i-mode2.0セキュリティの検討: 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 - 徳丸浩の日記(2009-08-05)
_携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 このエントリでは、携帯電話のブラウザに搭載されたJavaScriptと、WebサイトのXSSの組み合わせにより、いわゆる「かんたんログイン」に対する不正ログインの可能性について検討する。 5月28にはてなダイアリーに書いた日記「i-mode2.0は前途多難」にて、今年のNTTドコモの夏モデルP-07AにてJavaScript機能が利用停止されたことを指摘した。同日付のNTTドコモ社のリリースによると、「ソフトウェア更新に伴い、高度化した機能の一部をご利用いただけなくなっていますが、再びご利用いただけるよう速やかに対処いたします」とあったが、それ以来2ヶ月以上が経つものの、未だにJavaScript機能は利用できない状態のままだ。 実は、NTTドコモ社が慌てふためいてJavaScript機能を急遽停止
文字コードのセキュリティ問題はどう対策すべきか: U+00A5を用いたXSSの可能性 - 徳丸浩の日記(2009-03-11)
_U+00A5を用いたXSSの可能性 前回の日記では、昨年のBlack Hat Japanにおける長谷川陽介氏の講演に「趣味と実益の文字コード攻撃(講演資料)」に刺激される形で、Unicodeの円記号U+00A5によるSQLインジェクションの可能性について指摘した。 はせがわ氏の元資料ではパストラバーサルの可能性を指摘しておられるので、残る脆弱性パターンとしてクロスサイト・スクリプティング(XSS)の可能性があるかどうかがずっと気になっていた。独自の調査により、XSS攻撃の起点となる「<」や「"」、「'」などについて「多対一の変換」がされる文字を探してきたが、現実的なWebアプリケーションで出現しそうな組み合わせは見つけられていない。 一方、U+00A5が処理系によっては0x5C「\」に変換されることに起因してXSSが発生する可能性はある。JavaScriptがからむ場合がそれだ。しかし、
書籍「はじめてのPHPプログラミング基本編5.3対応」にSQLインジェクション脆弱性 - 徳丸浩の日記(2008-10-29)
id:hasegawayosuke氏にそそのかされるような格好で、「はじめてのPHPプログラミング基本編5.3対応」という書籍を購入した。 本書は、ウノウ株式会社の下岡秀幸氏、中村悟氏の共著なので、現役バリバリのPHP開発者が執筆しているということ、下記のようにセキュリティのことも少しは記述されているらしいという期待から購入したものだ。 目次から抜粋引用 07-07 Webアプリケーションのセキュリティ [セキュリティ] 08-04 データベースのセキュリティ [SQLインジェクション] 09-13 セキュリティ対策 [セキュリティ] 本書をざっと眺めた印象は、「ゆるいなぁ」というものであるが、その「ゆるさ」のゆえんはおいおい報告するとして、その経過で致命的な脆弱性を発見したので報告する。 問題の報告 それは、本書P280に登場する「SQLインジェクション対策用の関数(dbescape)」
徳丸浩の日記 - 書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性
_書籍「PHP×携帯サイト デベロッパーズバイブル」の脆弱性 「PHP×携帯サイト デベロッパーズバイブル」という携帯サイト開発のノウハウを解説した書籍が今月初頭に発売され、話題になっている。Amazonの「インターネット・Web開発」カテゴリで1位ということで、たいしたものだ。私も発売前から予約して購入した。 私がこの書籍を購入した動機は大きく二つある。一つは、携帯サイトの最新の開発ノウハウをまとめた書籍に対する期待をしていたということ。もう一つは、セキュリティに対する記述がどの程度あるのかを見てみたいというものだった。 このうち、前者については、期待は叶えられた。非常に盛りだくさんのテーマが手際よくまとめられていて、かつ読みやすい。あまり原理・理屈のことは書いていないが、開発現場では、コピペの情報源として重宝されることだろう。 しかし、問題はセキュリティについての記述である。 本社のサ
XSS: 今こそXSS対策についてまとめよう - 徳丸浩の日記(2008-08-22)
_今こそXSS対策についてまとめよう 沢出水（さわ いずみ）さんからトラックバックを頂戴した。 元々はホワイトリスト方式の優位は神話というエントリでホワイトリストはどう作る?を引用(批判)した事が発端の模様です。 一見真っ向対決しているようなので興味深く読ませていただいたのですが、正直、両者の主張の違いがわかりません。 どちらもXSS等インジェクション系の対策としてはアプリケーションで入力値が正しい形式の範囲内かチェックし、出力時に必要なエスケープ処理を行う、という結論に思えるんですけど… [ホワイトリストとブラックリストより引用] ご指摘の通りで、XSS対策は入り口でのバリデーションと表示(HTML組み立て)時のエスケープだ。しかし、元ブログの主題はホワイトリストとブラックリストの比較なので、「ただ、表面的に文章を追っただけでは『何をホワイトリストと呼ぶのか』という部分がだいぶ違う印象を
ホワイトリスト: プログラミングではホワイトリスティングが基本ではない - 徳丸浩の日記(2008-08-20)
_プログラミングではホワイトリスティングが基本ではない 大垣さんのブログにて反論をいただいた。 プログラミングではホワイトリスティングが基本 ホワイトリストはどう作る? 長文のエントリで、「暇な方だけお付き合いください」と書かれている。あいにく締め切りを抱えていて暇ではないのだが、名指しで反論されている以上、放置するのも失礼なので、簡潔にコメントしたい。 私は、一応セキュリティの専門家の端くれのつもりで、XSS Cheat Sheetをはじめ、大垣さんや金床さんの本にも目を通している。しかし、大垣さんの上記2エントリは、私にはさっぱり理解できない。以下、プログラミングの局面で、XSS向けのホワイトリストが作成可能なのかというポイントに絞って議論する。 プログラミングの基本は仕様に忠実であること 大垣さんが具体的な「ホワイトリストの作り方」を提示してくれないので、どのようなホワイトリストをイ
複文が利用できるデータベースの調査(2): SQL Serverが狙われるにはまだまだ理由がある - 徳丸浩の日記(2008-06-27)
_SQL Serverが狙われるにはまだまだ理由がある 徳丸浩の日記 - 複文が利用できるデータベースの調査 - SQL Serverが狙われるには理由があるにおいて、SQLインジェクションで別のSQL文を注入するためには、複文のサポートが必要で、SQLインジェクションの文脈でこれが可能であるDBMSはMS SQL ServerとPostgreSQLであることを示した。 ここで、複文を記述するには、セミコロン「;」で複数のSQL文を区切ると説明していたが、マイクロソフトの公表している文書によると、SQL Serverにおいては、複文の区切りにセミコロンは必要ないことが分かったので報告する 注意 複数の SQL ステートメントを区切るのに、セミコロンは必ずしも必要ありません。必要かどうかは、ベンダまたはインプリメンテーションによって異なりますが、Microsoft SQL server では
複文が利用できるデータベースの調査: SQL Serverが狙われるには理由がある - 徳丸浩の日記(2008-05-02)
_SQL Serverが狙われるには理由がある SQLインジェクションを利用したWebサイトの改ざん事件が頻発している。標的となったサイトの多くがIIS(ASP)とSQL Serverの組み合わせを利用していることから、今回の攻撃がIISやSQL Serverの脆弱性を利用したものだと言う報道があるらしい。 これに対して、マイクロソフトが反論している。 「SQLインジェクション攻撃とIISは無関係」とMicrosoft しかしMicrosoftはセキュリティ対策センター（MSRC）のブログで、今回のWebサーバ攻撃では「未知の脆弱性や新しい脆弱性は悪用されていないことが当社の調査で分かった」と説明。攻撃はIISやSQL Serverの脆弱性を突いたものではなく、アドバイザリー951306の脆弱性とも無関係だとした。 これはまぁ、もっともな内容だと思う。しかし、疑問は残る。なぜ、IISとSQ
変数に型のない言語におけるSQLインジェクション対策に対する考察(5): 数値項目に対するSQLインジェクション対策のまとめ - 徳丸浩の日記(2007-09-24)
_数値項目に対するSQLインジェクション対策のまとめ 一連の議論では、以下の条件におけるSQLインジェクション対策について議論している。 SQLインジェクション対策において、バインド機構が利用できない(したくない) 変数に型のない言語(Perl、PHP、Rubyなど)を使用している 数値型の列の場合 この場合の対策としては、以下の二種類が機能する。 SQL文組み立ての前に、数値としての妥当性検証を行う 数値項目もシングルクォートで囲み(クォートし)、文字列リテラルと同様のエスケープを行う 数値項目もクォートする方法 このうち、後者の積極的な推進者として大垣靖男氏がおられる。例えば、以下のような記事 すべての変数をエスケープする対策 この方法はすべてのデータベースに利用できる対策です。文字列，整数などデータ型に関わらず変数すべてを文字列としてエスケープすることにより，SQLインジェクションを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IPAは脆弱性の呼び方を統一して欲しい - 徳丸浩の日記(2009-03-28)