最近のGoogleのセキュリティ対策は相当厳しい。
未だにお客さんの依頼でたまにある事。残念ながら古いフレームワークを使うとOAuth対応とかされていなかったりするので、自分で作るか「セキュリティの低いアプリで連携」になると思う。
ガシガシっとコーディングしてた時代なら自分でOAuth対応ライブラリー作るところだが、そこまで今は気力はない。

ログに出てくるエラー

もちろん、G Suiteの「安全性の低いアプリ」に設定していますが、メールを送信してみると依然エラーが発生する。

安全性の低いアプリを許可する

対処方法

どうもうまくいかないので今度はG Suite AdminではなくGoogle ユーザアカウントの方にある安全性の低いアプリを許可するページを設定してみた。結果大成功！

セキュリティ設定レベルを制御するページ

app/Config/email.php

Google Search Consoleの404エラーはSEO上重要なファクターです。Googleは404エラーは評価無視扱いとされ、色々な説がネットで流れていますが結果論から言ってしまうとエラーの割合が多いと順位が確実に下がります。つまり直接理由ではなくて間接的な要因から順位が下がってしまいます。ここには隠された謎があります。というのは通常４０４エラーは検索結果のリンク表示をクリックしたときに「ファイルがありません」というものを表すのですが、実はそれだけでは無いのです。ここをじっくり見ると攻撃の跡が見られます。つまり、隠されたページやバグを見つけようとして、あの手この手で存在していないURLを作り出してアクセスしてきていることがわかります。GSの管理画面でクロール＞クロールエラー＞URLエラーの項目を是非チェックして見てください。おかしいなと思うURLがあるはずです。ほぼそれが攻撃の形跡だと思います。

404エラーは一見すると無害のように思えて、有害の場合もある。

先に述べたように有りもしないページは勝手にアタックさせておけばと考えるのですが、意外と短い時間で連続アクセスされるとサイトによっては重くなる要因です。ページが重くなったら機会損失ですし、今は表示速度は評価の一つです。その他404エラーは間接的に色々なファクターを持っており、Googleがインデックスを刷新するタイミングを作る意味もあります。いい意味でコンテンツの切り替えがあって404エラーになってしまう場合もあります。これは健全な404エラーで全く問題ないのですが、ここにさらにページの生存期間が加わってくるとややこしいことに。

1ヶ月程度でネタが更新されてゆくサイトはページのURLが変わってしまうと損。

ページがきちんとGoogleに認識するまでの期間は意外と時間がかかります。私の感覚では更新ページが少なければ1日、2日で認識されるのもありますがページ数が多いと2週間から1ヶ月弱までかかる場合も多い。それで1ヶ月程度でネタが更新されてゆくともうお分かりでしょうが認識されず生涯を終えるページもあるわけです。

評価してもらうにはできるだけ長くインデックスにエージングしてもらう構造が必要。

つまり新しい記事ネタでもページURLは変わらずページBODYのみ定期的にダイナミックに変わるものが最も有利な構造と言えます。最初からデータベースでBODYコンテンツをダイナミックに作ればよいのでしょうが、図体のでかいサイトは簡単に変更できません。今はスクレイピングの技術やJavascriptの技術があるから置換したり局所的にはめ込みを更新するのは簡単なことです。私は実験で自分自身が持っている幾つかのサイトを完全ファイル構造を変えて刷新することをやってみましたがやはり全てのGoogle検索サーバが完全同期するまでには半年以上かかりました。その間は何度もGoogle Search Consoleの中で重複や404エラーの先祖返り評価を表示されることがあり、改めてGoogleの検索サーバの同期はものすごい時間がかかるので、ディレクトリ構造やファイル名をあんちょこにコロコロ変えるのは得策ではないとわかりました。

404エラーはゼロになる必要はないが、定期的にエラーをチェックしエラーの原因を掴みましょう

エラーはサイトの健康のバロメータであることはわかったかと思います。エラーが少ないにこしたことはありません。多いということはそれだけ無駄が潜んでいたり、セキュリティアタックを受けてたりと色々なことがわかります。セキュリティアタックなら攻撃パターンが分かれば対処は難しくありません。意外なところで便利な404エラーですね！皆さんも要チェック！

セキュリティとWEBマーケティングは一見すると互いに結びつかない知識のように感じる人も多いだろうと思う。現実的には今のネットワーク社会では犯罪の裏にネットワーク上の攻撃や詐欺が蔓延しており、WEBマーケティングに対する脅威は日々増え根拠は十分にあると言えます。

例えば、アメリカで起きているセキュリティ攻撃には相手企業を陥れるためのネットワーク攻撃があります。相手企業のWEBサーバがダウンすれば、影響を受けて当然、２番手、３番手の企業の売上は伸びることでしょう。しかしこの手の攻撃は攻撃する側も足がつかないようにするために、リスクに備えるための準備と攻撃基地を作るのにコストがかかる。まず日本ではかなり法整備やプロバイダー、警察の連携が大分整ってきたため足がつきやすいのは間違いない。よって日本でこのような事をやろうとしたら、海外にホスティングを借りて尚且、足がつかないホスティング業者や国を選択することになるだろう。また攻撃契約者とも足がつかないようにするのだと思います。

サイレントな攻撃パターン

以上の攻撃パターンは今までの典型的な攻撃の説明ですが、一番怖いのはサイレントな気が付きにくい攻撃だったりします。気が付きにくい攻撃とはさて何でしょうか？幾つか例をあげてみたいと思います。

1. サイトを殺さない程度に負荷をかけるDoS攻撃
2. サイトに侵略しても改ざんもウィルスも設置ぜず、攻撃ステーションとして利用する。
3. コンテンツの見かけの改ざんはせずに、サイト転送処理を行ってアクセスを散らす
4. わざと404エラーを大量発生させる。
5. わざと１ページ離脱を大量発生させる。
6. WEBの slow loris　攻撃でゆっくりと攻撃。WEBサイトをチアノーゼに追いやり、正常アクセス減、しかもセキュリティブロックを回避する。
7. 大量のコピーサイトを作成する。これによりオリジナルサイトが判定の勘違いで下げられてしまう場合も少なからずある。

以上のパターンが有名なところだろう。この攻撃パターンはGoogleの検索順位に確実に影響を与えます。しかもWEB担当者が攻撃されていることに気づかないため改善策を講じないからどんどん評価がゆっくり悪くなる。

検索順位に関わるSEO評価基準の例

• サイトの表示速度は順位に影響する
• 大量の404エラーは順位に影響する。
• 重複サイト、重複ページは著しい低評価を与える。尚且、何が正しいか判断もつきにくい
• 不用意なリダイレクトは評価を下げる

マーケティング統計情報の嘘と勘違い

どのWEBサイトにも、今は何かしらの計測用の埋め込みがされているのが普通では無いでしょうか？いちばん有名なところではGoogle Analyticsだと思います。この計測値は全てが本物のアクセスカウントだと思ったら大きな勘違いだと断言します。その理由は次にあげたいと思います

• 攻撃のアクセスは必ずしもエラーにならず、HTTPレスポンスで通常の「200 OK」ステータスも取れる攻撃はかなり多い。
• DoS攻撃は「200 OK」ステータスで攻撃が基本。シャットアウトされないように攻撃するのがセオリーだ。
• マーケティングで良い評価になるよう攻撃し、油断＆勘違いさせてサイトの向上努力をさせない。

今はスレイピング技術が各種プログラミング言語で発達しているため、高度な人間がクリック、入力したような動作をシュミレーションすることが出来ます。すなわちこれを応用して高度な攻撃が可能です。

セキュリティを向上させるとアクセス数が減る？

これも原因が２パターンあります。一つは例えばSSL化するとセキュリティの向上につながる事があります。つまり今までの攻撃が無効になることで、アクセスカウントに変換されていた攻撃がなくなるので、一見するとアクセス数が減ったように見えるというものです。ただし、セキュリティが強くなったからRejectされたのではなく、攻撃者がhttpsで攻撃する頭がなかった(笑　からhttpsにすると攻撃スクリプトがhttpだから弾かれるわけです。私の経験上の統計ではどのサイトも平均して２０％～４０％の攻撃カウントがアクセス数に含まれています。つまりSSL化したタイミングでアクセス数が激減するのは正常なカウントだけになったからなのです。攻撃カウントがゼロにはなりませんが、大幅にカウントが減るため皆導入後に躊躇します。こういう事が原因だったんですね。

２つ目は、セキュリティが強く効きすぎて正常なアクセスが遮断されるというものです。クッキーやセッション絡み、あるいはWAFの誤検知などがあげられます。これが様々な条件で生じるためテストの段階ではすり抜けてしまい結果的にエンドユーザ側で生じてしまうというケースです。

皆さんの周りに会社間の取引で見積りや重要書類を送るときにメールを２回送って、１回目はZIPパスワード付き書類で２回目はパスワードを送るという方法でやっている会社が非常に多くありませんか？

これ、実はとんでもない大きな誤りなのです。全く安全ではありません。

メールのヘッダーはSMTPコネクションで相互に交換する際に暗号化されませんしスニファー機能があるソフトで簡単にトラッキングできます。メールで暗号化されるのはメールクライアントとメールサーバ間だけであり、メールサーバから宛先のメールサーバ間は必ずしも暗号化されていません。暗号化には送信側と受信側の両方が暗号化通信に対応している条件が整っていなければただの平文が流れていると思ってください。

FromアドレスとToアドレスがネット上の通信パケットでテキストで読めるのですから例えばWireShark等のネットキャプチャーソフトでフィルターかけてトラッキングすれば簡単にわかります。
でも一般の方はこの事知られていないし、固くそれが安全だと信じています。

この方法の場合、少しやり方を変えて、最初のメールを送るまではOKです。2回目のメールのパスワードを送る箇所を別の方法に変えるとかなり安全になります。

• パスワードはビジネス用SNSで送る。
• または電話で相手に伝える。
• SMSで送る

上記のように何れかの方法にするとかなり安全になります。しかし、最初のZIPパスワード付きなのですが、これは１００％パスワード解読ではありませんがクラッカーの世界では解読するソフトが流通しています。完全に安全とは言えません。

少々乱暴ですが、Facebookのメッセンジャーやビジネスチャット等で添付して送るほうが何倍も安全です。Lineやfacebookの乗っ取りや事故は多くがセキュリティに疎いユーザがわかりやすいパスワードを付けたり、第三者にわかるようにパスワードを晒したり、スパイウェアをパソコンやスマホの中に感染してしまって起きているものであり、仕組みそのものが全く安全でないということではありません。

メールサーバは暗号化通信においてメールボディを暗号化して送受信を行う技術は確立されていますが、メールを送る先とメールを受け取る先が同じ規格でメールの通信する環境を作っていないと完全なる暗号化の相互受信はできません。
つまり、メールサーバやメールクライアントはその会社、プロバイダー、個人ごとに仕様がまちまちで、お互いに相互受信しようと思ったらノーマルのテキスト通信が一番問題なくメール交換が出来るのです。そりゃそうですよね～相手のメールが暗号化されても自分のメールクライアントが暗号化に対応してなければ受け取っても読めないですから。

WEBサイトのセキュリティ対策の中でも重要なのが画像のアップロード時の不正対策だ。最も行われている攻撃は画像のファイルのメタ情報に不正コードを埋め込んで、後から復元＆実行を穴のあるプログラムコードに混ぜて処理させファイル改竄に持ってゆくというものだ。この手法は古くからある手法だが残念ながら今でも十分有効な攻撃手法です。

画像ファイルアップロードで考慮すべきこと

• ファイルのアップロードデータをドキュメントルートの外フォルダへ配置する。移動ではなく保存先を最初から外部にする。
• ファイルのファイル名をオリジナルでは無いランダムなベースファイル名にする。
• アップロードした画像の中身が本当に画像ファイルなのか検査する。プログラムなのに拡張子が画像拡張子の場合を検査
• アップロードした画像の中にあるメタインフォに不正コードを含まれてしまう可能性があるのでexiftoolで削除する
• Google captchaなどを使用してバッチ処理の攻撃を防ぐ
• ファイルの格納は１種類に統一する。仮に画像種別が複数あっても保存時に変換する。変換するとメタ情報が消去される。
• 画像ファイルのアップロードできるサイズを規定し必要以上の大きなサイズでメモリ圧迫を避ける。

exiftoolを導入

元々はexiftoolの目的は画像のメタ情報（撮影時の機種、タイムスタンプ、画像のタイプ、場所などの付帯情報）を編集するツールです。このソフトはオープンソースなのでダウンロードしてどんなプラットフォームでも利用が可能です。それではLinux(CentOS6,7)などで利用する場合について解説していきたいと思います。

exiftoolのホームページ

ダウンロードしたら適用なディレクトリに配置して解凍します。

もしMakeする際にエラーが出るとしたら、perlモジュールが足りないため発生する可能性はあります。その場合はcpanをyumでインストールし cpanツール起動しライブラリーをインストールしてください。「cpan[1]> install ExtUtils::MakeMaker」

exiftoolでメタ情報を除去

気をつける点は”-all= *.jpg”の”=”の後は半角１個分のスペースの後に画像ファイル名を指定しないとエラーになる。またデフォルトで変換前のファイルはoriginalという名前が付加され残ります。残すと危険なので削除を最後に実施します。

　

画像変換にImageMagickを使う。

GoogleのreCaptchaで投稿を安全にする（連続投稿のブロック）

簡単に設置できるので試してください。「私はロボットではありません」のボックスが表示されます。

Google reCaptcha