WordPressでpingbackを検証できないサイトがある

最近うちのブログにpingbackを飛ばしてきたブログがあってそのブログのpingbackがエラーコード0、エラーメッセージnullで失敗とログに記録されていました。
なんだろうー?とXMLRPCサーバーの処理を追ってみたところ、HEADエレメント内のHTML文法エラーとJavaScriptの問題でした。

HTML文法エラーはそのまんまで <meta property="og:description" content=""説明""/> など普通の文法エラーによる解析失敗。
そしてJavaScriptはpackerで難読化した物がHEAD内にあると動作不良を起こしていました。

pingbackの主な処理はwp-includes/class-wp-xmlrpc-server.phpのfunction pingback_pingで行われます。

<?php
 
public function pingback_ping( $args ) {
    ...省略...
 
    $request = wp_safe_remote_get( $pagelinkedfrom, $http_api_args );
    $remote_source = $remote_source_original = wp_remote_retrieve_body( $request );
 
    if ( ! $remote_source ) {
        return $this->pingback_error( 16, __( 'The source URL does not exist.' ) );
    }
 
    /**
     * Filters the pingback remote source.
     *
     * @since 2.5.0
     *
     * @param string $remote_source Response source for the page linked from.
     * @param string $pagelinkedto  URL of the page linked to.
     */
    $remote_source = apply_filters( 'pre_remote_source', $remote_source, $pagelinkedto );
 
    // Work around bug in strip_tags():
    $remote_source = str_replace( '<!DOC', '<DOC', $remote_source );
    $remote_source = preg_replace( '/[\r\n\t ]+/', ' ', $remote_source ); // normalize spaces
    $remote_source = preg_replace( "/<\/*(h1|h2|h3|h4|h5|h6|p|th|td|li|dt|dd|pre|caption|input|textarea|button|body)[^>]*>/", "\n\n", $remote_source );
 
    preg_match( '|<title>([^<]*?)</title>|is', $remote_source, $matchtitle );
    $title = isset( $matchtitle[1] ) ? $matchtitle[1] : '';
    if ( empty( $title ) ) {
        return $this->pingback_error( 32, __( 'We cannot find a title on that page.' ) );
    }
 
    $remote_source = strip_tags( $remote_source, '<a>' ); // just keep the tag we need
 
    $preg_target = preg_quote($pagelinkedto, '|');
 
    foreach ( $p as $para ) {
        if ( strpos($para, $pagelinkedto) !== false ) { // it exists, but is it a link?
            preg_match("|<a[^>]+?".$preg_target."[^>]*>([^>]+?)</a>|", $para, $context);
 
            // If the URL isn't in a link context, keep looking
            if ( empty($context) )
                continue;
 
            // We're going to use this fake tag to mark the context in a bit
            // the marker is needed in case the link text appears more than once in the paragraph
            $excerpt = preg_replace('|\</?wpcontext\>|', '', $para);
 
            // prevent really long link text
            if ( strlen($context[1]) > 100 )
                $context[1] = substr($context[1], 0, 100) . '&#8230;';
 
            $marker = '<wpcontext>'.$context[1].'</wpcontext>';    // set up our marker
            $excerpt= str_replace($context[0], $marker, $excerpt); // swap out the link for our marker
            $excerpt = strip_tags($excerpt, '<wpcontext>');        // strip all tags but our context marker
            $excerpt = trim($excerpt);
            $preg_marker = preg_quote($marker, '|');
            $excerpt = preg_replace("|.*?\s(.{0,100}$preg_marker.{0,100})\s.*|s", '$1', $excerpt);
            $excerpt = strip_tags($excerpt); // YES, again, to remove the marker wrapper
            break;
        }
    }
 
    ...省略...
}
 
?>

ここのwp_safe_remote_getでpingback送信元へGETリクエストを送信しHTTPヘッダーとHTMLをダウンロードします。
そして次のwp_remote_retrieve_bodyでHTMLのみのデータを変数へセット。

その後はスペース、改行、エレメントを整理しpreg_match( '|<title>([^<]*?)</title>|is'....で記事タイトルをゲット。
strip_tagsでアンカーを消してexplode( "\n\n", $remote_source );で改行毎に配列に格納します。

後はforeach ($p as $para)で配列の中からpingback送信先URLが含まれる配列を探して、配列内にあるpingback送信先URLの前後の文章を抜粋して終了の流れ。

抜粋処理周りにはフィルターが一切ないので処理の変更ができません。
packerの難読化を使っているどうしようもないサイトからのpingbackへどうしても対応したい・・って事なら処理が開始される前に通るフィルターpre_remote_sourceがあるので、これでscriptタグを全て削除すると良いかもしれません。
 
私的には・・・
packerの難読化のような何にもならない物を使っているサイトは放置しても良いと考えます。
と言うのも、packerには悪いと思いますが、後ろめたいコードを書いている多くのサイトに使われている物ですし、元のコードへ戻すのが非常に簡単で使う意味がほぼ無な物なので。

送信側の方はpingbackの送信に失敗するな?と思ったら自分のブログのコードが正常か確認を。

Bingクローラーは学習しない

うちのブログは今年9月に完全SSL化しましたが、SNI未対応クライアントを配慮してSSLバーチャルホストのデフォルトをblog.wolfs.jpに設定していました。
その影響でSSLのwww.wolfs.jp、www.blog.wolfs.jpのアクセスも許可していました。

上記サブドメインを許可していた期間は僅か1ヶ月ほどでしたが一部の検索結果に上記サブドメインも載るようになったようで、www.wolfs.jp、www.blog.wolfs.jpへのアクセスがかなり増えましたw
これはダメだな・・と言うことでSNI未対応環境を捨ててblog.wolfs.jpドメインからのみアクセスを許可するよう設定し、検索結果から消すために301 Moved Permanentlyでリダイレクトするように設定して更に1ヶ月が経過。

Googleは9割blog.wolfs.jpへアクセスするようになったけれど、Bingだけは2ヶ月前と全く変わりません。
ログを見るとリダイレクト先へアクセスしていない状況。
但し、robots.txtのリダイレクトだけはちゃんとリダイレクト先にアクセスするよう。

Bingの挙動はかわってるなーと思っていたけど301を理解しないバカクローラーだとは思いませんでしたw
と言うことで、Bingは301を理解しないのでドメインを変更するときは注意が必要です。

ちなみに、リダイレクトをしているのはユーザーエージェントがGoogleとBingだけです。
リダイレクトのコードはこんな感じ。

<?php
 
if ($_SERVER['HTTP_HOST'] !== 'blog.wolfs.jp') {
    $agent = strtolower($_SERVER['HTTP_USER_AGENT']);
    if (strstr($agent, 'googlebot') !== false || strstr($agent, 'bingbot') !== false || strstr($agent, 'msnbot') !== false) {
        $redirect_host = 'blog.wolfs.jp';
        if (strstr($_SERVER['HTTP_HOST'], 'wolfs.jp') !== false) {
            $redirect_host = 'blog.wolfs.jp';
        } else if (strstr($_SERVER['HTTP_HOST'], 'xn--n6x.jp') !== false) {
            $redirect_host = 'xn--n6x.jp';
        } else {
            http_response_code(400);
            exit;
        }
 
        http_response_code(301);
        header('Location: https://'.$redirect_host.$_SERVER['REQUEST_URI'], true, 301);
        exit;
    }
 
    http_response_code(403);
    exit;
}
 
?>

これをwp-config.phpの一番上とかに書いておけば勝手にやってくれます。

Battlefield 1のコンソール対策

最近にBattlefield 1で遊んじゃってます。
友達宅ではBattlefield 2やBattlefield 4を遊んだことはあるけれど、自分で買って遊んだのはこのBattlefield 1が初めて。

で、Battlefieldシリーズは日本語キーボード環境だとコンソールの誤爆問題があるそうです。
Battlefield 1 - コンソール画面
(赤枠がコンソール)

誤爆問題ってなんだろうって事なんだけれど、
英語キーボードだとチルダ(˜)キーでコンソールの表示/非表示ができるのですが、日本語キーボードの場合は半角/全角キーが該当します。
コンソールが表示されるとDirectInputからIMEに入力が移行し、半角/全角を押してもコンソールを閉じることができなくなります。

対策としてはBattlefield起動時前に英語キーボードの設定にするのが一般的なようです。
が、私はATOKを使用しており、MSIMEをアンインストールしているので再インストールが面倒なのと、ATOKで英語キーボードにすると一部のソフトで正常に変換が行えなくなる症状がでるので論外です。

なら、なにで対策するのか?というと、ソフトウエアベースのキーリマップツールを使います。
今回使うのはAutoHotkey L
(ちなみに、多くのオンラインゲームに搭載されているnProtectやHackShieldなどのチート対策ソフトはAutoHotkeyをチートツールと認識するので、オンラインゲームをプレイするときは終了しておかないとゲームが起動しません。)

AutoHotkeyはキーへマクロや別の機能を割り当てを行う常駐型のソフトで、割り当てを行う設定はAHKスクリプトで書いて動作するツールなんです。
使うのはマクロではなく、キーのリマップ機能。

コンソール対策のスクリプト自体は簡単で、「半角/全角」キーが押されたら「1」キーが押された事にするだけ。
SHKスクリプトはこんな感じ。

vkF3sc029::1
vkF4sc029::1

上記コードをメモ帳から適当な名前の.ahkファイルとして保存する。

AutoHotkeyの起動方法はx64環境ならAutoHotkeyU64.exe、x32環境ならAutoHotkeyU32.exeへ保存したahkファイルをD&Dするだけ。
ショートカットやプロンプトから起動する場合は「AutoHotkeyU64.exe 保存したスクリプト.ahk」とすれば問題なし。
終了するときはタスクバーのアイコンから終了するだけ。

これで戦闘中に強制固定砲台になるコンソール誤爆対策ができました。
昔から言われてるんだから、開発側はさっさと対策すればいいのになあ

UCOM(ARTERIA Networks Corporation)のアビューズ対応

UCOMはアビューズ対応を行わない糞なISPでしたが、そのUCOMからウィルス付きメールが送信されてきたので、ちょっと公式サイトを覗いてみたところ・・・
いつの間にか社名がARTERIA Networks Corporationにかわっていて、ドメインも新しくなりアビューズ報告フォームもできていました。

いざアビューズ報告を行うと・・報告確認画面で真っ白に。
拡張などの機能をきったプロファイルのFirefox、Chromeで試したけれど同じでした。

なのでIPをRIRへ照会したときに出てくる公開連絡先abuse@ucom.ne.jpへメールを送ろうとした所、見事に送信不能でした。

% [whois.apnic.net]
% Whois data copyright terms http://www.apnic.net/db/dbcopyright.html
% Information related to '221.240.0.0 - 221.255.255.255'
inetnum: 221.240.0.0 - 221.255.255.255
netname: Vectant
descr: ARTERIA Networks Corporation
descr: Sumitomo Fudosan Mita Twin Bldg.East Wing,Shibaura,4-2-8, minato-ku, Tokyo,108-0023 Japan
admin-c: JNIC1-AP
tech-c: JNIC1-AP
remarks: Email address for spam or abuse complaints : abuse@ucom.ne.jp
country: JP
status: ALLOCATED PORTABLE
mnt-by: MAINT-JPNIC
mnt-lower: MAINT-JPNIC
mnt-irt: IRT-JPNIC-JP
changed: ip-apnic@nic.ad.jp 20070221
changed: ip-apnic@nic.ad.jp 20070507
changed: ip-apnic@nic.ad.jp 20140514
changed: ip-apnic@nic.ad.jp 20160714
source: APNIC
irt: IRT-JPNIC-JP
address: Urbannet-Kanda Bldg 4F, 3-6-2 Uchi-Kanda
address: Chiyoda-ku, Tokyo 101-0047, Japan
e-mail: hostmaster@nic.ad.jp
abuse-mailbox: hostmaster@nic.ad.jp
admin-c: JNIC1-AP
tech-c: JNIC1-AP
auth: # Filtered
mnt-by: MAINT-JPNIC
changed: abuse@apnic.net 20101108
changed: hm-changed@apnic.net 20101111
changed: ip-apnic@nic.ad.jp 20140702
source: APNIC
role: Japan Network Information Center
address: Urbannet-Kanda Bldg 4F
address: 3-6-2 Uchi-Kanda
address: Chiyoda-ku, Tokyo 101-0047,Japan
country: JP
phone: +81-3-5297-2311
fax-no: +81-3-5297-2312
e-mail: hostmaster@nic.ad.jp
admin-c: JI13-AP
tech-c: JE53-AP
nic-hdl: JNIC1-AP
mnt-by: MAINT-JPNIC
changed: hm-changed@apnic.net 20041222
changed: hm-changed@apnic.net 20050324
changed: ip-apnic@nic.ad.jp 20051027
changed: ip-apnic@nic.ad.jp 20120828
source: APNIC
% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (UNDEFINED)

じゃあ電話で報告してやれ!って事でフリーダイヤルへかけたところ、調べてかけ直すとの事だったので電話を待っていたところ・・・
20時毎に電話があり「弊社では一切迷惑行為の対応を行わない」と切り捨てられました。
こちらがサーバーログ及びメールデータの提供を行うと言っても拒否されました。

ARTERIA Networks Corporationは「特定電子メールの送信の適正化等に関する法律」に違反しているユーザーを処罰できる立場にありながら、発信元ユーザーへの電気通信役務の提供を停止しない悪質な業者と言えます。
犯罪行為が行われているのを知っていながら放置する非常に危険なISPって事ですね。

回線速度もクソだと言うことを聞きますし、アビューズ対応を行わないので過去に悪事を働いたIPが割り振られた時には・・・と思うと怖いですねー
UCOM光やARTERIA Networks Corporationのサービスは使用しない方がいい感じです。

ちなみに、送られてきたメールとサーバーログはこんな感じ。 続きを読む