WikiにAdWords広告を追加してみました。AdWord広告は自分のBlog・Wikiにどんな広告が掲載されるか確認する事が主目的で付けているのですが上の方の広告だけだと見るたびに同じ広告なので面白くありません。右側に追加してみたらいろいろ見たことが無い広告が表示されるようになりました。
blogもそうですが書いてあるコンテンツによって表示される広告が変わるのは割と面白いです。よく出来ているからGoogleは儲かっているのですが、AdWordsよく出来ていますね。
HDDがクラッシュしてデータが飛んだ事があるので、Wikiを設置してから日時の訪問数ではないですが
Total: 9996
Today: 9
Yesterday: 31
Online: 2
となっていて今日中に1万を超えるみたいです。
もっといろいろ役に立ちそうな情報を載せたい、と思ってはいるのですがなかなか…
追記：現在のPHPでは$_SERVER[‘PHP_SELF’]はクエリ文字列（?以降のクエリパラメータ）を含みません。しかし、index.php/<script>alert(1)</script>/aaa/bbb とすることは可能です。PHP_SELFと同様の変数は以下です。
時々見かけるのでブログでも問題を指摘します。
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の出力が無いか確認すると良いかも?!
当たり前、と思うのですがNTPとの訴訟で争点となっていた特許の1つ（特許番号5,436,960）も却下されたようです。
備考：かなり古いブログですが公開し忘れしていた分です。
前にも書いたと思いますが、一般に公開する画面でリファラ表示は止めるようにした方よいと思います。以前に比べてリファラが一般に広く公開されているサイトは少なくなりましたがまだまだ沢山あります。
リファラSPAMでbotを使っていると思われるSPAMが常識になっています。IPはリクエスト毎に異なり、短時間に大量のリファラを残す事もほとんどなくなりました。中にはリクエスト先のURLも異なる物もあります。
こうなるともうほとんど普通のリクエストとリファラ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系な私でも自作できそう! なレベルにまで解説されています。
本物のIDカードがどんなカードか知らないと「私は○○です」とだまされる可能性が高くなります。ここでは10ユーロで世界中にIDカードを送ってくれるそうです。
10ユーロらしいのでチケットや物品の学割などに悪用されそう..
さすがに(?)オンラインで受け付けるとまずいと思ったのか注文書を郵送しなければならないようです。
しかし、多分日本語はダメでしょう（笑
CMSの比較サイト。さっきの時点で533のCMSアプリが登録されています。
5.1.0で直されていたはずなんですけど。記憶が確かなら。
え?という感じなのですがPHP 5.1.1, PHP 5.1.2にはシステムが初期化する配列にGLOBALSをチェックするコードを入れてなかったようです。自分では試してないですが簡単にチェックできるのでこのアドバイザリが間違っていることはないでしょう。
HTTP Response Smuggling終わっていない、ということ。
スタンダード原理主義者では無いですが、\r, \nのみで改行扱いはどうかと…
HTTP Response Splittingも再来していたのであるとは思っていましたが…
MySQLがFirebirdの開発者を採用したそうです。
独自の後期のデータベースエンジンを開発してInnodbとBerkeley DB問題を解決するための布石かな。
ちょっと思うところがってSJISはあまり使わない方がよいのでは考えています。色々なところで問題になりそうな気がします。時間が出来次第、色々調査・検証したいのですがいつになる事やら…
当分検証する時間は取れそうに無いので他の方が先に調査・検証するでしょうね。
# もし参考になるブログ、リンクを見つけられたら
# コメント、メール大歓迎です。
メモ。書く時間がないのでURLだけ。とりあえず面白そう。