カテゴリー
Other

WikiにgoogleのAdWordsを追加

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

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

カテゴリー
Other

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

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

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

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

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

カテゴリー
Computer Programming Security

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

カテゴリー
Computer

RIMが特許紛争に勝つ

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

カテゴリー
Security

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

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

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

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

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

カテゴリー
Computer Security

日本のアイドルサイトからのリファラ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をばらばらにリクエストしている所が新しいです。

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

カテゴリー
Security

クロスサイトクッキー

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

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

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

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