備考：かなり古いブログですが公開し忘れしていた分です。
前にも書いたと思いますが、一般に公開する画面でリファラ表示は止めるようにした方よいと思います。以前に比べてリファラが一般に広く公開されているサイトは少なくなりましたがまだまだ沢山あります。
リファラ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だけ。とりあえず面白そう。
Googleがgmailをgmail.com以外のドメインで使えるようにしたそうです。
https://www.google.com/hosted/Home
から登録依頼を送信できます。gmailのアカウントが必要です。私も@gm.ohgaki.netのメールアドレスで試しに使えるように依頼を送信してみました。
追記：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スクリプトとなる文字列型データです。
メモ。IPv6の広大なメモリ空間がWormの脅威を軽減させる、という論文。
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へ移行が必要です。しかし、今ひとつ認知されていない気がしたので念のため。