yohgaki's blog

  • PHP_SELFはそのまま出力できない

    追記：現在のPHPでは$_SERVER[‘PHP_SELF’]はクエリ文字列（?以降のクエリパラメータ）を含みません。しかし、index.php/<script>alert(1)</script>/aaa/bbb とすることは可能です。PHP_SELFと同様の変数は以下です。

    • $_SERVER[‘PATH_INFO’]
    • $_SERVER[‘PATH_TRANSLATED’]

     

    時々見かけるのでブログでも問題を指摘します。

    PHPの$_SERVER配列に入っているPHP_SELF要素はPATHINFOも含めてしまうため、そのまま出力するとXSSに脆弱になる場合があります。

    phpinfo()がXSSに脆弱だ、と指摘する人がいるので（元々phpinfo()の出力は管理者・開発者のみ参照できるようにしておくべきですが..)現在のPHPはPHP_SELF内の< > を検出して

    <script> </script>

    等と書けないようになっています。しかし、この対策はphpinfo()の事しか考えていないので

    <?php
echo '<a href="'. $_SERVER['PHP_SELF'] .'">aaa</a>';
?>

    の様なケースの場合、

    http://example.com/xss.php/%22%20onMouseOver=%22javascript:alert(‘xss’);

    等としてJavaScriptの挿入が可能になります。

    SCRIPT_NAMEにはPATH情報が無いのでこの問題は発生しません。PHP_SELFでは無くSCRIPT_NAMEを使用すべき所をPHP_SELFを利用しているケースは時々見かけます。

    注意が必要かもしれませんね。

    UNIX系OSならPHPのソースがあるディレクトリに移動して

    find . -name “*.php” | xargs grep -n “PHP_SELF”

    等として怪しいPHP_SELFの出力が無いか確認すると良いかも?!

  • RIMが特許紛争に勝つ

    当たり前、と思うのですがNTPとの訴訟で争点となっていた特許の1つ（特許番号5,436,960）も却下されたようです。

  • リファラの表示は止めましょう

    備考：かなり古いブログですが公開し忘れしていた分です。

    前にも書いたと思いますが、一般に公開する画面でリファラ表示は止めるようにした方よいと思います。以前に比べてリファラが一般に広く公開されているサイトは少なくなりましたがまだまだ沢山あります。

    リファラSPAMでbotを使っていると思われるSPAMが常識になっています。IPはリクエスト毎に異なり、短時間に大量のリファラを残す事もほとんどなくなりました。中にはリクエスト先のURLも異なる物もあります。

    こうなるともうほとんど普通のリクエストとリファラSPAMは区別できません。インターネットユーザにできる自衛策は「みんながリファラを公開しない」「おかしなリファラをクリックしない」しかありません。

  • 日本のアイドルサイトからのリファラSPAM?

    久しぶりにブログへのSPAM掃除をしていたら、日本のアイドルサイトからのリファラSPAMと思われるログが複数ありました。

    #リンクにならないようにhttpのhを削除しました。

    ttp://suzukiairi.net/cgi-bin/up/upload.php?page=all
    ttp://www.umedaerika.com/ume/uperika.php?page=all
    ttp://melon-kinenbi.plala.jp/~ayumi/sam.php?start=100
    ttp://ai-flavor.com/upload/flavorupload.php?page=all
    ttp://www.sudomaasa.com/rabi/upmaasa.php?page=all

    なにこれ?と思っていたところどうもこのアップローダ（正確にはサムネイルの表示スクリプト）にはXSS脆弱性があるようです。某サイトのサンプルファイルを修正して使っているようです。

    このスクリプトはXSSに脆弱なのでファンが勝手にXSSに脆弱なスクリプトを利用してSAPMを送信したのか、とも思ったのですが同じIPアドレス（サーバのとは別のIP：xxx.87.1.155）のリファラであるためXSSを利用しているとは断定できません。書きませんがwhois情報を見ると…、となっています。

    サーバ（多分このIPはプロキシ）がクラックされているか?内部のクライアントがクラックされているのか? 単純に内部の利用者によりプロモートするためにリファラSPAMが仕掛けられているのか?業者によるこれらのタレントのプロモーション用SPAMなのか?

    他の業者とは異なるのは参照先のURLがトップページ固定ではなく、ほとんどが実在するURLをばらばらにリクエストしている所が新しいです。

    とりあえず様子を見ることにします。

  • クロスサイトクッキー

    随分前にブログにも書いたつもりでいたのですが、書いていないようなので。
    ccTLD(*.co.jpなど）のクッキーの信頼性はTLD（*.com）に比べて低い、という話。

    自分で最後に試したのは去年末か今年初め（だったかな?）だと思いますが、IE、FF共にccTLDのドメインにたいしてクッキーを設定できました。

    まさかクッキーを信用しているサイトは無いと思いますが、設定されているクッキーの数が異常だとエラーになるサイトなどの場合、DoSに脆弱になります。

    追記：
    書き忘れていましたが、デフォルトのPHPのセッション管理ではセッションの固定化（Session Fixation）に脆弱になります。use_only_cookiesにしてもccTLDの場合、セッションIDのクッキーが設定できてしまうのでセッションの固定化攻撃には注意が必要です。

  • キーロガーを自作する

    S/W系な私でも自作できそう! なレベルにまで解説されています。

  • 1枚からのIDカード

    本物のIDカードがどんなカードか知らないと「私は○○です」とだまされる可能性が高くなります。ここでは10ユーロで世界中にIDカードを送ってくれるそうです。

    10ユーロらしいのでチケットや物品の学割などに悪用されそう..
    さすがに(?)オンラインで受け付けるとまずいと思ったのか注文書を郵送しなければならないようです。

    しかし、多分日本語はダメでしょう（笑

  • CMS Matrix

    CMSの比較サイト。さっきの時点で533のCMSアプリが登録されています。

  • PHP 5.1でregister_globals=onには注意

    5.1.0で直されていたはずなんですけど。記憶が確かなら。

    え?という感じなのですがPHP 5.1.1, PHP 5.1.2にはシステムが初期化する配列にGLOBALSをチェックするコードを入れてなかったようです。自分では試してないですが簡単にチェックできるのでこのアドバイザリが間違っていることはないでしょう。

  • HTTP Response Smuggling再来

    HTTP Response Smuggling終わっていない、ということ。

    スタンダード原理主義者では無いですが、\r, \nのみで改行扱いはどうかと…
    HTTP Response Splittingも再来していたのであるとは思っていましたが…

  • MySQLがFirebirdの開発者を採用

    MySQLがFirebirdの開発者を採用したそうです。

    独自の後期のデータベースエンジンを開発してInnodbとBerkeley DB問題を解決するための布石かな。

  • SJISはあまり使わないようがよいかも

    ちょっと思うところがってSJISはあまり使わない方がよいのでは考えています。色々なところで問題になりそうな気がします。時間が出来次第、色々調査・検証したいのですがいつになる事やら…

    当分検証する時間は取れそうに無いので他の方が先に調査・検証するでしょうね。

    # もし参考になるブログ、リンクを見つけられたら
    # コメント、メール大歓迎です。

  • Yahooが面白い

    メモ。書く時間がないのでURLだけ。とりあえず面白そう。

  • gmailをgmail.comドメイン以外で使う!

    Googleがgmailをgmail.com以外のドメインで使えるようにしたそうです。

    https://www.google.com/hosted/Home

    から登録依頼を送信できます。gmailのアカウントが必要です。私も@gm.ohgaki.netのメールアドレスで試しに使えるように依頼を送信してみました。

  • addslashesによるエスケープ処理は止めましょう

    追記：PHPエスケープ関連の検索でこのエントリを参照されたと思います。PHPでのエスケープ全般については以下のエントリを参照してください。

    https://blog.ohgaki.net/php-string-escape

    セキュリティmemoにaddslashesよるエスケープ処理でSQLインジェクションが可能なるという記事を見つけました。

    私のセミナーを聞いたことがある方は「addslashesによるエスケープ処理は止めましょう」と言っていた事を覚えているでしょうか? mysql_real_escape_string()やpg_escape_string()等のデータベース専用のエスケープ関数を使いましょう、とも話しています。

    ちなみにSQLiteを使っている場合はaddslashesでエスケープ処理はNGです。もっと根本的に間違っています。SQLiteではMS SQL Server, Sybaseと同様「’」は「”」とシングルクオートでエスケープします。

    基本には忠実に :)

    追記：
    サーバとクライアントのエンコーディングが合っていないと問題が発生します。PostgreSQLの場合、SET文でクライアントエンコーディングを変えるのではなくpg_set_client_encoding()を利用してエンコーディングを変えないとならないです。MySQLでも同様にアプリからSET NAMESでエンコーディングを変えるのはNGです。

    addslashesでエスケープして良い物はPHPスクリプトとなる文字列型データです。