タグ

ブックマーク / blog.tokumaru.org (30)

  • 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_

  • ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る

    WEB & NETWORK SSL/TLSより引用 わざわざSSLの場合にもゲートウェイを割り込ませている目的としては、ケータイID(UID)を付与することと、絵文字の変換があるようです。 ※注意:EZwebにもゲートウェイ型のSSLがあります(仕様)がProxyサーバーのホスト名が見えているわけではないので、今回報告するような問題はありません。 ゲートウェイ型SSLの問題点 ゲートウェイ型SSLが廃止されるきっかけは、高木浩光氏と、ソフトバンクモバイル取締役専務執行役員CTOの宮川潤一氏のtwitter上のやりとりであると言われています。この内容は、Togetterにまとめられています。これを読むと、ゲートウェイ方式のSSLでは、httpとhttpsでドメインが異なるため、Cookieを引き継ぐことができないことが問題として説明されています。現場のニーズとしてこの問題は大きいと思うのです

  • CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 書では、CSRFの対策について以下のように説明されています(同書P338)。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で

    shimooka
    shimooka 2011/01/27
    『マイクロ秒とはいえ日時を元にしているので、予測可能な情報を元にトークンを生成している』
  • escapeshellcmdの危険な実例

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2011年1月4日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 先日の日記PHPのescapeshellcmdの危険性ではPHPのescapeshellcmd関数の危険性について指摘しましたが、脆弱となる実例を挙げていなかったので、「当に危険なのか」と半信半疑の方もおられると思います。そこで、同関数が危険となる実例を考えたので報告します。 grepを使って、サーバー内を検索するスクリプトを考えます。 <?php header('Content-Type: text/html; charset=UTF-8'); ?> <html> <body><pre> <?php $k

  • PHPのescapeshellcmdの危険性 - 徳丸浩の日記

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2011年1月1日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり を書いています。初稿を一通り書き上げ、第2稿を作成中です。その過程で見つけたことを報告します。 PHPのescapeshellcmdはパラメータをクォートしないので呼び出し側でクォートする必要がありますが、escapeshellcmdの仕様がまずいために、呼び出し側でクォートしても突破できることが分かりました。 escapeshellcmdの仕様 PHPにはシェルのパラメータをエスケープする関数が2つあります。escapeshellargとescapeshellcmdです。escapeshellargは、エ

  • 文字コードに起因する脆弱性を防ぐ「やや安全な」php.ini設定

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2010年9月27日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPカンファレンス2010にて「文字コードに起因する脆弱性とその対策」というタイトルで喋らせていただきました。プレゼンテーション資料をPDF形式とslideshare.netで公開しています。 文字コードのセキュリティというと、ややこしいイメージが強くて、スピーカーの前夜祭でも「聴衆の半分は置いてきぼりになるかもね」みたいな話をしていたのですが、意外にも「分かりやすかった」等の好意的な反応をtwitter等でいただき、驚くと共に喜んでいます。土曜にPHPカンファレンスに来られるような方は意識が高いというの

    shimooka
    shimooka 2010/09/27
    『データベースによってはBMP外の文字(U+10000以降の文字)に対応していないものもあるので、「つちよしテスト」を全てのアプリケーションがパスできるとは限りません』
  • htmlspecialcharsのShift_JISチェック漏れによるXSS回避策

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2009年10月9日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり このエントリでは、PHPhtmlspecialchars関数の文字エンコーディングチェック不備をついたクロスサイト・スクリプティング(XSS)脆弱性について、PHP側のパッチが提供されない状況での回避策について説明します。 何が問題か PHPにおいて、XSS対策にはhtmlspecialcharsによって記号をエスケープすることが行われますしかし、htmlspecialcharsを利用していても、Shift_JISの先行バイトを利用して、XSSが発生する場合があります。 例えば、以下のようなINPUTがあ

  • そろそろWAFに関して一言いっとくか~三重苦を乗り越えてWAFが普及するための条件とは~

    補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブはてなブックマーク1、はてなブックマーク2) 備忘のため転載いたしますが、この記事は2008年7月22日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 なお、この記事を書いた後、WAFはこの記事の予言(願い?)通りに進展したように思います。そのあたりの歴史については、こちらのインタビュー記事を参照下さい。 補足終わり PCIデータセキュリティ基準(PCIDSS)がWAF(Web Application Firewall)について言及していることなどから、最近再びWAFへの関心が高まっている。一方、WAFは、一部のユーザや専門家に非常に評判が悪い。なぜ、そのようなことになるのか。稿では、WAFの基機能を説明した上で、その限界と運用上の問題を指摘し、今後のWAFの使い方

    そろそろWAFに関して一言いっとくか~三重苦を乗り越えてWAFが普及するための条件とは~
  • session_set_save_handlerのパストラバーサルで任意コマンドの実行が可能

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年8月19日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日の日記(session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性)で、PHPの公式リファレンスマニュアルに出ているsession_set_save_handlerサンプルにはパストラバーサル脆弱性があることを報告しましたが、その影響度について書き漏らしていて、影響度を過小に受け取られることに気がつきましたので補足します。 このパストラバーサルは情報漏えいよりは書き込み・破壊の影響の方が現実的というのはその通りなのですが、Web公開領域のファイルを書き換えら

  • session_set_save_handlerリファレンスマニュアルのサンプルにパス・トラバーサル脆弱性

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年08月18日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり PHPsession_set_save_handlerのリファレンスを眺めていて、ふと、これはパス・トラバーサルの脆弱性があるのではないかと思いました。 function read($id) { global $sess_save_path; $sess_file = "$sess_save_path/sess_$id"; // ← ファイル名の組み立て return (string) @file_get_contents($sess_file); } function write($id, $sess_