ホーム > タグ > PHP

PHP

$_SERVER[‘HTTP_*’] はクライアントの値

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

スパム投稿の特徴を見つけ出すのに、どんな値を
ログに記録してたらいいのか試行錯誤してたところ、
PHPがあらかじめ用意してくれるスーパーグローバル変数
$_SERVER の中でキーが HTTP_ で始まるものが
クライアントが送信してきた値だとつい最近知りました。

よく Proxy が付加してくる ViaX-Forwarded-For など
全て大文字で、- (ハイフン)は _ (アンダーバー) に変換され
こんなキーで得られます。

$_SERVER[‘HTTP_VIA’]
$_SERVER[‘HTTP_X_FORWARDED_FOR ‘]
続きを読む

auto_prepend_fileで役割分担

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

このブログ、12日の早朝よりスパム投稿の集中砲火をあびとります。
今朝出勤ししてから仕事を終えて戻るまでに
コメントスパムとトラックバックスパム両方で300件強。
あーめんどくさい。

広く知られた WordPress だけにスパム業者も解析済みのようで
コメントスパムもフォームを拾いに来た形跡がありません。
TBに至ってはフォームそのものが無関係なので
今回は Javascriptでスパム投稿対策 とはいかんようです。

スパム業者には早々退散願いたいところですが
WordPress に手を加えるのもなんだと思ったので
auto_prepend_file を使ってみました。

auto_prepend_file は、
リクエストされたPHPスクリプトの実行前に
自動で実行するスクリプトを指定するPHPの設定です。
自動 require みたいな事ができます。

コア php.ini ディレクティブに関する説明
auto_prepend_file

これが指定できるのは .htaccess です。
自動実行させたいスクリプトのパスが
‘/home/userdir/spamFilter.php’ だとすると
該当ディレクトリの .htaccess に次の1行を書き加えます。

.htaccess

php_value auto_prepend_file "/home/userdir/spamFilter.php"

これによりPHPスクリプトがリクエストされると
その実行前に必ず spamFilter.php が実行されます。
自動実行される spamFilter.php は、
普通のPHPスクリプトと変わりなくなんでも出来ます。
ただし、対象のディレクトリ以下全てのPHPスクリプトの実行前に
必ず実行されることになるので使いどころ注意です。

今回はスパム投稿をハネて余分なサーバーの負荷を
減らせれば良いので、POSTメソッド以外はサッサとスルーさせ
残りをブラックリストでフィルタリングです。
引っかかったやつには、
「404 Not Found + 本文無し」 のレスポンスです。

spamFilter.php

<?php
if ('POST' === $_SERVER['REQUEST_METHOD']):
    $__isSPAM = false;

   /**
    * このへんは、UAやHost、Proxyっぽいものなど
    * 適当にブラックリストでフィルタリング。
    * 該当する場合は $__isSPAM = true; にする。
    */

    if (true === $__isSPAM) {
        header('HTTP/1.0 404 Not Found');
        exit();  // SPAMに本文は不要!
    }
endif;
?>

auto_prepend_file でこうした役割を持たせれば
アプリケーションに手を加えることもなく本来の役割に専念させられます。

スパム投稿の発信元を追跡してみる

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

hidden + IP でスパム投稿対策 でフォームに埋めたIPは
ホントの発信元ではなくほとんどが接続を中継してる PROXYサーバーのIPです。

少しでも発信元に近づくためリクエストヘッダをログにとってみると
次のようなPROXYサーバーらしき痕跡を見つけられます。

Via: 1.1 192.168.19.1 (Mikrotik HttpProxy), 1.1 121.7.231.132 (Mikrotik HttpProxy)',
X-Forwarded-For: 72.36.182.226, 125.160.91.245, 121.7.231.132
X-Proxy-ID: 2035636757, 1382434604

標準のアクセスログにはこうした情報まで記録されないので
PHPの apache_request_headers() 関数で
リクエストヘッダを独自のログにとってみました。

このうち X-Forwarded-For はPROXYサーバーが
付加するクライアントのIPなので、より発信元に近いIPってことになります。

1件だけ眺めててもピンときませんが
フォームに埋め込んだIPが同じリクエストを
ひとつのグループとしてみると、いくつかの共通したIPが見えてきます。

72.232.10.98
72.232.81.78
72.232.220.34
72.36.182.226

whois で調べてみると、
どれも同じ US の会社が管理するIPだとわかります。
この会社はホスティングサービスなどをやってる普通の会社なので
ココのユーザーがスパムを発信してる可能性が高いです。
ただし上のIPもPROXYの可能性もあるので
断定はできませんが、かなり発信元に近づいたと思います。

ここまできたら、この会社にスパム投稿の発信元にされている旨を
ログなどの蓄積した情報を添えて相談すると。
しっかりログをとっていれば、
ネットワークの専門家でなくてもこのくらいまでの追跡は可能です。

ワンタイムチケットでスパム投稿対策

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

JavaScript でスパム投稿対策に「100%排除」って書いたけど
サーバー側の対策との合わせ技で100%達成してるので
そのスパム投稿対策も紹介しておきます。

1.ワンタイムチケット
フォーム出力の際、サーバー側で一度きりのユニークなIDを生成し
セッションに保存、同じIDをフォームにも埋め込んで出力します。
投稿された際このIDを照合すれば、
正規のフォームから投稿されたものだと判断できます。

尚、比較後すぐにセッション側のIDを破棄すれば
リロード(二重投稿)防止対策にもなります。

2.COOKIEにIPアドレス
フォーム出力の際、リモートホストのIPアドレス を COOKIEで送信します。
投稿された際、COOKIEのIPと実際投稿してきたホストの
IP を比較し、おなじなら同一ホストと判断できます。

スパム投稿では、一度得たフォームやCOOKIEを使いまわししてるようなので
これが違う場合は、自動投稿ロボットの可能性が高いです。
ただIPがコロコロかわる携帯端末などでは使えません。

【デメリット】
どちらも COOKIE必須 。
また1の場合はセッションの寿命が残ってる間に
投稿を完了しないと受け付けられないことです。

普通に投稿するユーザーの利便性を損ねないことはとても大切なんですが、
スパム投稿に含まれてるURLにはフィッシング詐欺のものもあるので
普通のユーザのためにもスパム投稿を見逃すわけにはいきません。
クッキー と JavaScript は ON でご協力お願いします。

staticなプロパティの使いどころ

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

PHP4とPHP5の違うところメモ第2段です。

PHP5からは、static を指定したプロパティは
インスタンス化しなくてもアクセス出来るよう変わりました。
static キーワード

以下のようなオブジェクトの入れ物的な静的クラスがスマートに書けます。
PHP4、5のどちらも register::set($object) でオブジェクトを登録し
register::get($className) で取りだします。
続きを読む

@演算子のパフォーマンス

[`evernote` not found]
[`grow` not found]
[`livedoor` not found]
[`yahoo` not found]
Delicious にシェア
このエントリーをはてなブックマークに追加

エラー出力を制御する@演算子のパフォーマンスについて
MyRSS.jpさんとこのブログで興味深い実測をされてました。

「@」でエラー抑制すると PHP が遅くなるという噂について
@を使った場合、何も使わなかった場合、isset()を使った場合の
3つについてパフォーマンスを比較されています。

ふと、予め「初期化した値」だと違ってくるのか?
と思ったのでこれにのっかってみました。
続きを読む

1 2 3 4

ホーム > タグ > PHP

Ad
Apache
MySQL
PHP
お気に入り
ん。。。。。。広告
アーカイブ
Ad

ページの上部に戻る