Posted:
今日では、ハッキングされるウェブサイトの数は、1 日あたり数千に及ぶと言われています。ハッキングされたサイトは、ユーザーに悪意のあるソフトウェアを配布する、ユーザーの個人情報を収集する、ユーザーをまったく別のサイトにリダイレクトするなどの方法で、ユーザーに危害を加えるおそれがあります。もしサイトがハッキングされたら速やかに復旧したいものですが、その方法は単純ではありません。

Google では、サイトがハッキングされた場合にできるだけ簡単に復旧できるよう、セキュリティの問題ハッキングされたサイトに関するヘルプハッキングされたサイト専用のフォーラムなどを提供しています。最近、ハッキングされた 2 つのサイトのウェブマスターの方に、どうやってサイトを復旧したかについてお話を伺う機会がありました。こうした事例をご紹介することで、ハッキングの被害にあったウェブマスターの皆様がサイトの復旧を行う際のヒントになれば幸いです。

事例 1: レストランのウェブサイトがハッキングされ、複数のスクリプトが挿入された

このレストランでは Wordpress でウェブサイトを作成していましたが、ある日サイトがハッカーによって改ざんされたことを警告する Google からのメッセージがウェブマスター ツール アカウントに届きました。Google では検索ユーザーを保護するため、このウェブサイトがハッキングされたことを示すラベルを Google 検索結果に表示しました。このサイトのウェブマスターであるサムさんがソース コードを確認したところ、「viagra(バイアグラ)」、「cialis(シアリス)」などの薬剤用語を使った不審なリンクが数多く見つかりました。また、「buy valtrex in florida(バルトレックス 購入 フロリダ)」のような meta description タグが HTML 上に追加されているページも数多く見つかりました。さらには、多くのページに(HTML 内にも)非表示の div タグが挿入され、さまざまなページにリンクしていました。もちろん、これらはサムさんが追加したものではありません。

サムさんは、ハッキングされたコンテンツを可能な限り削除して再審査リクエストを送信しました。リクエストは承認されませんでしたが、Google からメッセージがあり、PHP ファイル(もしくは、その他のサーバー ファイル)内に不審なスクリプトが追加されていないか、.htaccess に変更が加えられていないか確認するようアドバイスされました。これらは、ハッカーがサイトを改ざんする際、スクリプトを追加するのによく狙うファイルだからです。通常、ハッカーはこのようなスクリプトを使って、ハッキングしたコンテンツを検索エンジンに対してのみ表示し、一般のユーザーにはそのコンテンツが表示されないようにしてしまいます。サムさんはすべての .php ファイルを確認し、ハッキング前にバックアップしておいたファイルと比較しました。その結果、footer.php、index.php、functions.php に新しいコンテンツが追加されていることが判明しました。これらのファイルをバックアップ ファイルで置き換えた後にハッキングされたコンテンツがそれ以上見つからないことを確認し、もう一度再審査リクエストを送信したところ、サイト内のハッキングされたコンテンツがすべて削除されていることを知らせる Google からの通知が届きました。

ハッキングされたコンテンツはすべて削除しましたが、サムさんとしては今後のハッカーの攻撃からサイトを保護しなければなりません。そこで以下の方法によりサイトを保護することにしました。
  • コンテンツ管理システム(WordPress、Joomla、Drupal など)を常に最新のバージョンに更新する(プラグインも忘れずに更新する)。
  • コンテンツ管理システムの管理機能を使用できるアカウントに、強度の高いパスワードを使用する。
  • コンテンツ管理システムでサポートされている場合は、ログインの 2 段階認証(英語)を有効にする(2 要素認証と呼ばれることもあります)。この方法は、パスワードの再設定に使用するアカウントにもおすすめします。GoogleMicrosoftYahoo(英語)など、ほとんどのメール プロバイダでサポートされています。
  • インストールされているプラグインやテーマが信頼できる提供元からのものであることを確認する。既にサポートが終了しているようなプラグインやテーマを使用し続けることは大変危険です。また、海賊版のプラグインやテーマには、ハッカーの侵入を容易にするようなコードが挿入されていることが多いようです。

事例 2: 事業用ウェブサイトに検出が難しいハッキングされたページが大量に見つかった

小規模事業主であるマリアさんは、管理しているウェブサイトがハッキングされていることを知らせるメッセージをウェブマスター ツールで受け取りました。メッセージには、ハッカーが追加したページの例として http://example.com/where-to-buy-cialis-over-the-counter/ が挙げられていました。ホスティング プロバイダに相談したところ、ホームページのソース コードを確認してくれましたが薬剤に関するキーワードは見つからず、http://example.com/where-to-buy-cialis-over-the-counter/ にアクセスするとエラー ページが返されるという状況でした。有料のマルウェア スキャン サービスも利用しましたが、サイト内に悪意のあるソフトウェアを見つけることはできませんでした。
その後、ウェブマスター ツールの Fetch as Google 機能を使用して、Google が例示した URL(http://example.com/where-to-buy-cialis-over-the-counter/)にアクセスしてみましたが何も返されませんでした。どうしようもないため再審査リクエストを送信したところ、不承認メッセージが届き、以下の 2 点を試すようアドバイスがありました。
  1. www のないサイト URL をウェブマスター ツールに追加する。これは、ウェブマスターが見落としがちなフォルダにハッカーのコンテンツが隠されている場合があるためです。

    http://example.com と http://www.example.com は同じサイトのように見えますが、Google ではこれらを別々のサイトとして処理しています。http://example.com は「ルート ドメイン」で、http://www.example.com は「サブ ドメイン」です。マリアさんは http://www.example.com は確認していましたが、http://example.com は確認していませんでした。しかし、ハッカーが追加していたページは http://example.com/where-to-buy-cialis-over-the-counter/ のような www のないページで、こちらを確認することが重要だったのです。マリアさんが http://example.com を確認したところ、ウェブマスター ツールの Fetch as Google 機能を使用してハッキングされたコンテンツを表示することができました。
  2. .htaccess ファイルに新たなルールが追加されていないか確認する。

    マリアさんが、ホスティング プロバイダにやり方を教わって .htaccess ファイルを確認したところ、次のような追加した覚えのない不審なコンテンツが追加されていました。

    <IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{HTTP_USER_AGENT} (google|yahoo|msn|aol|bing) [OR]
    RewriteCond %{HTTP_REFERER} (google|yahoo|msn|aol|bing)
    RewriteRule ^([^/]*)/$ /main.php?p=$1 [L]
    </IfModule>


    この mod_rewrite(英語)ルールはハッカーが挿入したもので、特定の検索エンジンから訪れたすべてのユーザーと検索エンジン クローラを、ハッキングされたコンテンツの生成元である main.php にリダイレクトしているものでした。このようなルールで、携帯端末でサイトにアクセスしてきたユーザーをリダイレクトすることも可能です。同じ日、最近のマルウェア スキャンによって、main.php ファイルに不審なコンテンツが見つかっていたことも判明しました。さらには、ウェブサイト開発ソフトウェアの FTP ユーザー領域に、不明なユーザーが登録されていることにも気付きました。
マリアさんは main.php ファイルと .htaccess ファイルを削除し、FTP ユーザー領域から不明なユーザーを削除しました。これにより、サイトのハッキングを止めることができたのです。

今後ハッキングされないための対策

  • サーバーへのファイル転送に FTP の使用を避ける。FTP では、パスワードをはじめすべてのトラフィックが暗号化されません。代わりに SFTP を使用することで、パスワードを含むすべてのトラフィックが暗号化され、盗聴者からデータを保護できます。
  • .htaccess のような重要なファイルへのアクセス権限を確認する。この点については、必要に応じてホスティング プロバイダに相談してください。.htaccess はサイトの改善や保護に使用する重要なファイルですが、このファイルへのアクセスを許してしまうとハッカーに悪用されるおそれがあります。
  • サイトを変更する権限のあるユーザーを確認できる場所(管理パネルなど)をこまめにチェックして、不明なユーザーが追加されていないかどうか確認する。
Google では、ウェブマスターの皆様のサイトがハッキングされないことを願っておりますが、万が一ハッキングされた場合はハッキングされたサイトに関するヘルプをご覧ください。ハッキングされたサイトを復旧するためのさまざまな資料が用意されています。それでもご不明な点がある場合や、他のウェブマスターと情報交換していただける場合は、ウェブマスター ヘルプ フォーラムをご利用ください(フォーラムに投稿する際やサイトの再審査リクエストを送信する際は、#NoHacked を含めるようにしてください)。

最後に、ハッキングによる被害はなかなか気づかないことも多いようです。サイトの不正なハッキングをいち早く見つけ、普段からサイトのセキュリティ強化を意識しましょう!

Posted:
JSON-LD は、Google などの検索エンジンに対してサイト上のコンテンツを記述する構造化データの実装に使用できる JSON ベースのデータ形式です。たとえば、イベント、店舗、人物などのリストがある場合に、schema.org ボキャブラリを JSON-LD スニペットとしてウェブページに埋め込むことで、構造化された方法でリストのデータをページに含めることができます。構造化データにすることで、Google がページの内容を把握しやすくなり、ナレッジグラフ イベントリッチ スニペットなどの検索機能でコンテンツがハイライトで表示されやすくなります。

Web Components は、カスタマイズした再利用可能なユーザー インターフェース ウィジェットとその動作を定義するための技術です。複数の技術で成り立ち、その仕様は現在も策定中です。ウェブ デベロッパーであれば誰でも Web Components をビルドできます。まず、ユーザー インターフェースの個々のパーツについてテンプレートを定義し、Web Components を使用したいページにテンプレートをインポートします。Web Components の動作を定義するには、Custom Elements を使用します。ユーザー インターフェースのパーツの表示とロジックが Web Components にバンドルされるため、このバンドルを他のページや他のデベロッパーと共有したり、再利用したりでき、ウェブ開発が簡単になります。

JSON-LD と Web Components は、併せて利用するととてもうまく機能します。Custom Elements がプレゼンテーション層として機能し、JSON-LD は Custom Elements や検索エンジンが読み込むデータ層として機能します。つまり、schema.org/Eventschema.org/LocalBusiness など、どのような種類の schema.org についても、Custom Elements をビルドできることになります。

アーキテクチャは次のようになります。構造化データはデータ ベースに格納されます(例: チェーンの店舗の所在地)。このデータは JSON-LD スニペットとしてウェブページに埋め込まれます。つまり、Custom Elements によって読み込まれ、人間の訪問者に対して表示されたり、Googlebot によって Google のインデックス登録のために取得されたりできるようになります。

Custom Elements の詳細や独自の Custom Elements の使用方法については、以下をご覧ください。

Posted:
多くのウェブサイトでは、重要な目標を達成するための手段としてフォームを使用しています。たとえば、ショッピング サイトでは代金の決済、ニュース サイトでは会員の登録などです。ユーザーの多くは、ウェブ上の各サイトでオンライン フォームを入力するたびに、氏名、メール アドレス、電話番号、住所などの情報を繰り返し入力することになります。同じ情報を何度も入力するのは面倒なだけではありません。入力エラーが発生しやすく、ユーザーがフォームの途中で入力をやめる原因にもなってしまいます。パソコンよりも携帯端末で閲覧するユーザーが多くなり、フォームをすばやく簡単に入力できるようにすることが不可欠となっています。Google では 3 年前、フォームへの入力をすばやく、簡単に、スマートに行えるようにするため、Chrome で新たに「autocomplete」属性をサポートすることを発表しました。現在では、最新の WHATWG の HTML 標準(英語)に準拠する形で「autocomplete」属性が完全にサポートされています。これにより、ユーザー インターフェースやバックエンドに変更を加えることなく、入力要素項目に一般的なデータ タイプ(「name」、「street-address」など)をラベル付けできるようになっています。既にたくさんのウェブマスターがフォームをマークアップしてオートコンプリートを実装し、フォーム入力の完了率を上昇させています。

たとえば、フォームのメール アドレス項目をオートコンプリートできるようにするには、次のようにマークアップします(サンプル フォームもご覧ください)。

<input type="email" name="customerEmail" autocomplete="email"/>
携帯端末ユーザーが増加した今、操作やブラウジングが簡単なウェブサイトにすることが非常に重要です。「autocomplete」属性でマークアップされたフォームが、今後ますます増えていくことを願っております。詳細については、「Web Fundamentals」の Label and name inputs properly (英語)で仕様を確認してください。ご質問などありましたら、いつもどおりウェブマスター ヘルプ フォーラムに投稿してください。

Posted:
Google のサーチ クオリティ チームは、ユーザーに対するウェブスパムの影響を最小限に抑える方法について継続的に取り組んでいます。誘導ページもその対象の 1 つです。

Google では従来より、検索エンジンのためだけに作成された誘導ページについて、ユーザーの検索体験の品質に悪影響を及ぼす可能性があるとの見解を持っています。

たとえば、検索結果に表示されるすべてのページが、検索ユーザーを同じサイトに誘導するものであった場合を考えてみてください。ユーザーがある検索結果をクリックして閲覧し、その内容が目的に沿うものではなかったため検索結果ページに戻って次の結果をクリックしても、結局は最初に閲覧した目的に沿わなかったページと同じページに誘導されてしまい、ユーザーの利便性が大きく妨げられてしまいます。

Google では長い間、明確な独自の価値を提供していないにもかかわらず検索結果の上位に表示されることのみを目的とするサイトを目にしてきました。このような誘導は、サイト内の複数のページを利用したり、多数のドメインを利用したり、またはそれらを組み合わせた形で行われています。Google ではユーザーに表示される検索結果の品質向上を目的として、より適切にこのような種類のページに対応するためのランキングの調整を近日中に開始します。大規模かつ入念な誘導キャンペーンを実施しているサイトは今回の変更によって大きな影響を受ける可能性があります。

ウェブマスターの皆様に Google のガイドラインを十分にご理解いただけるよう、品質に関するガイドラインに誘導ページの明確な例を追加するとともに、その定義を更新しました。
誘導ページかどうかは、たとえば、以下のような項目に基づいて判断されます。
  • 検索エンジン用に最適化することでサイト内の有用なコンテンツや関連性の高いコンテンツにユーザーを案内することを目的としているか。そうである場合、そのページがサイトのユーザー エクスペリエンスに不可欠か。
  • ページのコンテンツが極めて具体的であるにもかかわらず、一般的なキーワードで検索結果の上位に表示されることを目的としていないか。
  • 検索トラフィックを増やすことを目的に、そのページにサイト上の既存の項目(場所や商品など)をまとめたコンテンツを繰り返して掲載していないか。
  • コンテンツや機能において独自の価値はなく、単にお金儲けのためにユーザーを別のページに誘導することのみを目的に作成されたページではないか。
  • ページが「孤立」して存在していないか。サイト内の他の場所からそのページへの移動が困難または不可能ではないか。検索エンジンのためだけに、サイト内の他のページやサイトのネットワークからそのページへのリンクを作成していないか。

誘導ページにつきましては、こちらのブログ記事「誘導ページ(Doorway Page)はガイドライン違反です」もご覧ください。誘導ページについてのご質問やご意見がありましたら、ウェブマスター ヘルプ フォーラムまでお寄せください。

Posted:
昨年の秋、多くの重要な自動処理の実装に役立つ新しい Webmaster Tools API 提供の開始をアナウンスしました。そしてこのたび、保留となっていた ClientLogin の終了(英語)とともに、2015 年 4 月 20 日に古い Webmaster Tools API (英語)を廃止します。

古い API を利用している場合でも、新しい API への移行は簡単です。新しい API は、メッセージとキーワードの機能を除いて古い API の機能をすべてカバーしています。Python (英語)、Java (英語)、および(コマンドラインに慣れた方のため、およびテストを容易にするために)OACurl (英語)のサンプルを用意しています。加えて、サイトを自動的に追加するためのSite Verification API (英語)も提供しています。 Python を使った検索クエリのダウンロード機能(英語)は当分の間提供を続けますが、今後数か月の間に新しい API に置き換わる予定です。

この記事に関するコメントやご意見・ご感想は、ウェブマスター  ヘルプ フォーラム までお寄せください。