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の一番上とかに書いておけば勝手にやってくれます。

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のサービスは使用しない方がいい感じです。

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

WordPressを完全にSSLへ移行してみた

うちのサイトは証明書の関係でPreload HSTS(HTTP Strict Transport Security)にはしていないけれど、
HSTS設定前でもかなりhttpsからのアクセスがあったのでHSTSの設定をして、常にhttpsへ接続してもらうようにました。

で、2017年1月にリリース予定のChromium 56から、パスワードやカード情報を送信するhttpなサイトは「安全ではない」と表示するようになるようです。
Chromium Blog: Moving Towards a More Secure Web

HTTP/2.0になって完全にhttpは要らないんじゃ?って感じになってきてるみたいですね。

もうそれなら完全にSSLへ移行しちゃって良いんじゃないかー!って事で、httpをhttpsへ301でリダイレクトするようにしました。
方法はいろいろあるけれど、WordPressならrewriteで良いと思う。

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://blog.wolfs.jp$1 [R=301,L]

ちなみに、RewriteRuleのURLで最後にスラッシュを入れるとリダイレクト先でダブルスラッシュになるので注意。
例:
 RewriteRule: RewriteRule ^(.*)$ https://blog.wolfs.jp/$1 [R=301,L]
 アクセスURL: http: //blog.wolfs.jp/page-1/
 リダイレクトURL: https: //blog.wolfs.jp//page-1/

これの何が悪いかと言うと、
ダブルスラッシュになっているとWordPressのリダイレクトが働いてhttps://blog.wolfs.jp/page-1/へリダイレクトされるので合計2回リダイレクトされる事に。
かなり無駄なので注意。
RewriteBase /なんかを使うと良いけど、別にそんなの指定しなくても/を1つ抜くだけで動くから要らないとおもうw

この状態でMozillaが提供しているサイトのセキュリティ診断、Observatory by Mozillaをうけてみると・・・
Observatory 結果
うんA+でかなり良いスコアがでました。
続きを読む

WordPressのインラインJavaScriptをなくして、Content Security Policyを設定

うちのテーマは今のこのデザインになるまでは、サードパーティーのテーマを使っていたんです。
で、そのテーマには脆弱性があってXSSが有効だったんですよー((゜Д゜;))

今は1から作った独自のテーマを使っていて、汎用的な拡張性(テーマに必要な画像等のアップロード機能やAJAX)や外部を参照する不明なコードはありません。
なのでテーマ経由の脆弱性はない感じなのです。

だけれど、XSSを防ぐセキュリティ関連のヘッダーを設定しておいた方が良いって事なのでApacheにヘッダーを追加してみました。
新しく追加したのはX-Content-Type-Options、X-XSS-Protection、Content-Security-Policyの3つで、どれもXSSを防ぐのに効果が高いもの。
X-Frame-Optionsだけはブログをiframeで表示されていたサイトがあったので設定済みでしたw

設定内容はこんな感じ。

Header always set X-Frame-Options SAMEORIGIN
Header always set X-Content-Type-Options nosniff
Header always set X-XSS-Protection "1; mode=block"
Header always set Content-Security-Policy "default-src 'self' *.wolfs.jp; script-src 'self' *.wolfs.jp; child-src 'self' data: www.youtube.com; style-src 'self' 'unsafe-inline' *.wolfs.jp; img-src 'self' data: *.wolfs.jp *.gravatar.com;"

 
で、今回躓いたのはContent Security Policy(CSP)の設定。

JavaScriptやCSSは以前から1つにまとめているので大した問題ではなかったのですが、CSPで「script-src 'self' *.wolfs.jp」のようにインラインスクリプトを許可しない設定だとWordPressが出力するコメント関連のスクリプトが動かなくなっちゃう。
かと言って許可するとXSSに対して弱くなり、CSPを設定しないのとあまり変わらないような結果になります。

うちの環境で見た感じ、主にWordPressが出力するインラインJavaScriptは、
 ・コメントフォームの隠しフィールド「_wp_unfiltered_html_comment_」
 ・コメントのある「返信」ボタンのonclick
のようです。

とりあえず、その辺を無効化して無効化した物を再度使用可能にするように作っていきます。
続きを読む

WordPress 4.6で追加されたdns-prefetchを無効化する

WordPress 4.6からヘッダーに<link rel="dns-prefetch" href="//s.w.org/">が追加されるようになりました。
見つけた瞬間サイトがクラックされたのか?!とヒヤっとしたけれど、s.w.orgはWordPressのショートドメインて事がわかって一安心しましたw

うちはWordPressの絵文字とかを使っていないのでs.w.orgのDNSプリフェッチは必要なし。
なのでこれを無効化してみました。

作成したPHPコードはこれ。

<?php
 
add_filter('wp_resource_hints', function ($urls, $relation_type) {
    if (is_admin() === false) {
        if ($relation_type === 'dns-prefetch') {
            return array();
        }
    }
 
    return $urls;
}, 10, 2);
 
?>

コードは簡単でwp_resource_hintsにフィルターをかけて、管理ページ以外かつタイプがdns-prefetchの場合は定義されている内容を空っぽにして返すって感じ。
管理ページの場合は、なにかあるとダメなので引数をそのまま返すようにしてあります。

全く使わないならremove_action('wp_head', 'wp_resource_hints');の方がはやいんじゃない?って思ったんだけど、なぜかこれが効かなかったのでadd_filterで対処する荒療治に。

ちなみに、この記事を書いた時の$relation_typeの種類はdns-prefetch、preconnect、prefetch、prerenderとありました。
詳しい動作を追いたい場合はwp-includes/general-template.phpの2800行付近にfunction wp_resource_hints()があるのでそこから見てください。