WikiにgoogleのAdWordsを追加

WikiにAdWords広告を追加してみました。AdWord広告は自分のBlog・Wikiにどんな広告が掲載されるか確認する事が主目的で付けているのですが上の方の広告だけだと見るたびに同じ広告なので面白くありません。右側に追加してみたらいろいろ見たことが無い広告が表示されるようになりました。

blogもそうですが書いてあるコンテンツによって表示される広告が変わるのは割と面白いです。よく出来ているからGoogleは儲かっているのですが、AdWordsよく出来ていますね。

Wikiのフロントページの訪問者数が1万目前

HDDがクラッシュしてデータが飛んだ事があるので、Wikiを設置してから日時の訪問数ではないですが

Total: 9996
Today: 9
Yesterday: 31
Online: 2

となっていて今日中に1万を超えるみたいです。

もっといろいろ役に立ちそうな情報を載せたい、と思ってはいるのですがなかなか…

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内の< > を検出して

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

の様なケースの場合、

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の出力が無いか確認すると良いかも?!

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

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

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

リファラ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のクッキーが設定できてしまうのでセッションの固定化攻撃には注意が必要です。

1枚からのIDカード

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

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

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

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も再来していたのであるとは思っていましたが…

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

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

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

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

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

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

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

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

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

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

PHP文字列のエスケープ

セキュリティ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スクリプトとなる文字列型データです。

Mozilla “Suite”を捨てる時期が来ました

Mozilla “Suite”を使用されている方はもうご存知だと思いますが、Mozillaを捨ててSeaMonkeyに移行する時期が来ました。

http://www.mozilla.org/security/announce/mfsa2006-05.html

は重大なセキュリティフィックスです。そして、このセキュリティアドバイザリに記載されているように、Mozillaには脆弱性を修正したバージョンはリリースされないようです(Firefox 1.0は1.0.8がでるようですが)Mozilla Suiteのユーザは後継プロジェクトであるSeaMonkeyに移行しなければなりません。

http://www.mozilla-japan.org/projects/seamonkey/
(このアドバイザリの1日前に1.0がリリースされました。名前は違いますが中身はMozilla Suiteその物です。)

Mozilla Japanのサイトにもあまりよく分かるような形で書いてない(?)ようです。本家はまだMozilla 1.7.12のダウンロードリンクがトップにあります。

Mozilla Suiteを使っている方はSeaMonkeyへ移行が必要です。しかし、今ひとつ認知されていない気がしたので念のため。

4 core CPUは来年はじめ

この記事によると4(Quad) core CPUは来年はじめにリリースされるらしい。現在は新しいデザインをレビューしている所だそうです。デスクトップPCにはPenium Dを使っていますがやはりDualの方がコンパイルが速くて使い心地が良いです。Quad-coreになると make -j6 くらいがちょうどかな?