皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書きました通り、今日はWeb系の脆弱性情報をお伝えします。

PHP･Apache･HTTP/2の脆弱性について

8月1日と8月20日に、JPCERTコーディネーションセンターは以下の脆弱性を発表しています。

＜PHP にバッファオーバーフローの脆弱性＞

PHP には、バッファオーバーフローの脆弱性があり、遠隔の第三者が、サービス運用妨害 (DoS) 攻撃を行ったり、任意のコードを実行したりする可能性がある。

対象は、

・PHP 7.3.8 より前のバージョン

・PHP 7.2.21 より前のバージョン

・PHP 7.1.31 より前のバージョン

PHP開発者や配布元提供の修正済みのバージョンへの更新で解決。

＜Apache HTTP Web Server 2.4 に複数の脆弱性＞

Apache HTTP Web Server 2.4 系に以下の脆弱性があり、情報改ざん、悪意のあるページへのリダイレクト、情報漏えい、サービス運用妨害（DoS）攻撃の影響を受ける可能性がある。

・mod_proxy のエラーページに限定的なクロスサイトスクリプティングの脆弱性

・mod_rewrite に潜在的なオープンリダイレクトの脆弱性

・mod_http2 に h2 コネクション切断時における解放済みメモリ読み込みの脆弱性

・mod_http2 にメモリ破壊の脆弱性

・mod_http2 に h2 worker 枯渇によるサービス運用妨害 (DoS) 攻撃の脆弱性

・mod_remoteip にスタックバッファオーバーフローおよび NULL ポインタ逆参照の脆弱性

対象は、Apache HTTP Web Server 2.4.41 より前のバージョン

Apache Software Foundation提供の修正済みのバージョンへの更新で解決。

＜HTTP/2 の実装に対するサービス運用妨害（DoS）攻撃＞

HTTP/2 通信の処理は、HTTP/1.1 通信の処理と比較して多くのリソースが必要であり、RFC7540 の Security Considerations セクションにおいても、サービス運用妨害（DoS）状態に関する検討が行われている(10.5. Denial-of-Service Considerations)。しかし、どのように対策すべきかは実装者にまかされており、これが以下の問題につながっている。

・Data Dribble

・Ping Flood

・Resource Loop

・Reset Flood

・Settings Flood

・0-Length Headers Leak

・Internal Data Buffering

・Empty Frame Flooding

各 HTTP/2 実装者が提供するアップデートの適用を実施。

これらのものに該当する場合、早めに修正済みバージョンへ更新されることをお勧めします。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた『HSTS Preload List Submission』は登録できなかったとしても特別問題はないのですが、『共用サーバ』を使っている場合には登録できないケースがあったりします。

HSTSのPreload Listが登録できない

『共用サーバ』の場合、全く知らない個人や事業者が同一のサーバに同居していますが、そのすべてのユーザーが適切に『HTTPS化』できているとは限りません。

その場合にホスティング会社はどのようなセッティングをするか？

『HSTS』は使えても『includeSubDomains』や『Preload』を無効にすることがあります。

理由として、『HTTPS化』への対応が適切にされていなかったりすることで表示上の問題が発生するケースがあるからです。

その場合、『HSTS Preload List Submission』の要件にある『includeSubDomains』と『Preload』が満たせないために登録できないということになります。

これを何とかしたい場合には以下の内容を『.htaccess』に記述してみて下さい。

<IfModule mod_headers.c>

Header always unset Strict-Transport-Security
Header set Strict-Transport-Security “max-age=31536000; includeSubDomains; preload”
</IfModule>

これで何とかなるケースがあります。

また、『www』サブドメインで正規化している場合、『.htaccess』でのリダイレクトではなくhtmlの『meta refresh』を使ったリダイレクトでないとうまく行かないことがありますので、苦肉の策ではありますがそれを使います。

（Googleは『meta refresh』を推奨していませんが、『やむを得ない場合』にはNGとはしていないので問題ないかと思います。）

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

すっかり遅くなってしまいましたので今日は少しだけ。

今年の春にリリース予定の『Windows 10（Version 1903）』では、Microsoft（マイクロソフト）のブラウザ『Edge』に搭載されているセキュリティ機能が『Chrome』と『Firefox』でも利用できるようになります。

Chrome Firefox 向け Defender

まもなくリリースされるであろう『Windows 10（Version 1903）』では、Windows Defenderの機能を『Chrome』と『Firefox』でも利用可能になります。

『Windows Defender Application Guard』というそうです。

信頼されていない（定義されていない）サイトにアクセスしようとした場合、サンドボックス内の『Edge』にリダイレクトされるようになっているとされています。

今後、Windows 10 のセキュリティは『Windows Defender』を考えている小規模事業者で、ブラウザは『Chrome』か『Firefox』を使いたい方にはいいかもしれません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いた記事を投稿したのが『WordPress 4.6』あたりの時ですが、その後の『WordPress 4.7』や『WordPress 4.8』以降においてアップデート更新時に『更新が止まっているように見える』現象を引き起こすものがありそうです。

WordPress更新で注意するディレクティブ

さて、今回新たにWordPressのアップデート更新にて『更新が止まっているように見える』現象を引き起こす可能性のあるものですが、それは『output_handler』に『ob_gzhandler』を用いた場合です。

『output_handler』は『スクリプトの全ての出力を関数にリダイレクトすることができる』もので、モード的には『PHP_INI_PERDIR』になるため、『php.ini』、『.htaccess』、『httpd.conf』、『.user.ini（PHP5.3以降の場合）』で設定可能なものです。

このディレクティブに『ob_gzhandler（出力バッファをgzip圧縮するためのもの）』という値を指定していた場合に『更新が止まっているように見える』現象を引き起こす可能性があります。

これは、特定のWordPressバージョンにおいてしか起こらない可能性もあります。

『WordPress 4.7』、『WordPress 4.8』、『WordPress 4.9』あたりは現象が起こる可能性が高い感じがしますが、『WordPress 5.0』以降においては現象が起こらない、問題が発生しない状態に戻っている可能性が高いと思われます。

ご参考までに。

その際、表示されたのは暗号化されていない『www.nta.go.jp』でした。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、WebサイトのHTTPS化は結構進んできたということは間違いないのですが、そのHTPPS化が中途半端な状態で行われていることがよくあります。

では、実際にどのような状態になっているのでしょうか？

WebサイトのHTTPS化での不備とは

まず、この国税庁のサイトを例にあげると、検索結果に表示されるリンク先が『HTTP』のものと『HTTPS』のものと混在しているようです。

今年の3月末、国税庁のホームページはリニューアルされたわけですが、その際、各ページのサイトマップはHTTPSに書き換えを行っているはずです。

ここから推察すると、まずは検索エンジン側のインデックスが間に合っていない可能性が高いと言えます。

しかし、これに関しては簡単に対処できます。

HTTPでのアクセスをHTTPSにリダイレクトすれば問題は起きません。

例えば、以下のようなルールを.htaccessに記述しておけば防げます。

RewriteEngine on

RewriteCond %{SERVER_PORT} !^443$ [OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

この他にも、せっかくHTTPS接続で読み込まれたHTMLでも、中に含まれているコンテンツのURLが『HTTP』となっている場合には『mixed content』となってしまい、『保護された通信』とはなりません。

これらのことにも気を配り、何度が表示確認をした上で、日々問題が発生している部分は改修していくことも重要です。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日本時間の昨日、WordPressの更新版であるWordPress4.9.5が公開されました。

今日はそのニュースをお伝えします。

WordPress4.9.5セキュリティ・メンテナンス

WordPressのブログでは、以下のように説明されています。

WordPress 4.9.5 がご利用いただけるようになりました。これは WordPress 3.7 以降のすべてのバージョンに対するセキュリティ・メンテナンスリリースとなります。今すぐにサイトの更新を行うことを強くおすすめします。

バージョン 4.9.4 以前の WordPress は、3つのセキュリティ問題の影響を受けます。コアチームの継続的なセキュリティ強化の取り組みにより、4.9.5 では、次の修正が実装されました。

１．デフォルトで localhost を同じホストとして扱わない。
２．SSL が強制されている場合に、ログインページのリダイレクトに安全なリダイレクトを使用する。
３．ジェネレータータグでバージョン文字列が正しくエスケープされていることを確認する。

WordPress 4.9.5 では、その他25個のバグが修正されました。特筆すべきは、以下となります。

・キャプションショートコードで以前のスタイルが復元されました。
・タッチスクリーンデバイスでクロッピングがサポートされるようになりました。
・エラーメッセージなどの文字列がより明解となるよう更新されました。
・アップロード中の添付ファイルのプレースホルダーの位置が修正されました。
・REST API JavaScript クライアントのカスタムノンス機能が、コードベース全体で一貫したものとなりました。
・PHP 7.2 との互換性が向上しました。

注意したいのは、『WordPress4.9.3で嫌な不具合』でご紹介した通り、WordPress4.9.3において自動バックグラウンド更新をサポートするサイトが自動的に更新されないというバグ（不具合）があったため、手動で4.9.4にアップデートされていない場合は4.9.5に自動更新されることはないと思われますので、念のため管理画面で確認をしておくことをお勧めします。

そのラボにおける活動の第一弾として、『日本国内におけるWordPressセキュリティの現状』の分析レポートが公開されています。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

冒頭に書いたラボが公開した分析レポートにおいて、WordPressへの攻撃（検出箇所）として以下のものが最多として書かれていましたのでご紹介します。

WordPressへの攻撃で最多のものとは

WordPressへの攻撃（検出箇所）で検出が最も多かったものは、『xmlrpc.php』というものです。

『XML-RPC』というのは、遠隔での呼出しを行うプロトコルの一種で、WordPressで言えば、通常の管理画面以外からの投稿を可能にするものです。

WordPressの場合、スマホアプリなどのXML-RPCを使った更新にも対応しているため、xmlrpc.phpというファイルが用意されています。

これが使用可能になっているとどうなるのか？

xmlrpc.phpをターゲットとしたDDoS攻撃などの被害に遭う可能性があり、それを受けた際にはサーバが高負荷状態でパンクしてしまうことにもなります。

つまり、アクセスできない状態にされてしまう恐れがあるということです。

では、これを避けるための対策法はどのようにすれば良いのか？

xmlrpc.phpファイルへの攻撃の対処法

WordPress3.5未満においては管理画面の投稿設定にxmlrpcを無効にするチェックボックスがあったのですが、WordPress3.5以降のバージョンではそれがなく（現在の最新は4.9.4）、デフォルトで有効な状態にあります。

その場合、一番簡単な方法は『.htaccess』でxmlrpc.phpへのアクセスを禁止してしまう方法です。

<Files xmlrpc.php>

Order allow,deny
Deny from all
</files>

と、記述を追加すればOKです。

どうしても特定のIPアドレスからのみ許可をしたい場合、

<Files xmlrpc.php>

Order allow,deny
Deny from all
Allow from xxx.xxx.xxx.xxx
</files>

と、赤字の部分を加えればOKです。

これ以外に、多少サーバへの負荷が残るものを考慮したいのであれば以下の方法が良いです。

<IfModule mod_rewrite.c>

RewriteEngine On
RewriteBase /
RewriteRule ^xmlrpc\.php$ “http\:\/\/0\.0\.0\.0\/” [R=301,L]
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

というように、WordPressで.htaccessに設定される記述に赤字の部分を追加し、xmlrpc.phpへのアクセスを0.0.0.0にリダイレクトさせてしまう方法もあります。

ちなみに、プラグインを使って無効化する方法もありますが、プラグインそのものに脆弱性が見つかることもあるためお勧めではありません。

さて、このセキュリティ警告は本物か偽物か？

皆さん、こんにちは。

業務改善を行う業務コンサルタント、高橋です。

先日、私の知人が突然電話をかけてきました。

内容は、『パソコンにWindowsのセキュリティ警告が出てしまってどうしたらいいかわからない。』というものでした。

悪質な電話詐欺への誘導

そこで、表示されているエラーっぽいものを読み上げてもらいました。

ALERT xxxxxxxxxx

Windowsセキュリティの重要な警告

Windowsセキュリティ&アンチウイルスサービスでエラーが発生しました。

お使いのシステムのオンライン診断結果

Windowsは、お使いのシステム上で可能な主要なレジストリの障害を検出した可能性があります。

詳細については、フリーダイヤル：03-XXXX-XXXXで、カスタマーサポートにお問い合わせください。

個人情報露出発生リスクの可能性

クレジットカード情報や銀行情報

電子メールのパスワード、その他のアカウントのパスワード

個人Facebook、Skype、AIM、ICQおよびその他のチャットログ

プライベート／家族の写真やその他の機密ファイル

ウェブカメラ、VPN、ウイルス、ストーカーによってリモートでアクセス

すぐに問題を修正し、データの損失を防ぐためにフリーダイヤル：03-xxxx-xxxxのWindowsサポートにお問い合わせください。

という内容のものでした。

これ、危険なウェブサイトを閲覧しようとしてリダイレクトされた先に表示されたものです。

そして、コンピュータの問題が生じたと思わせて電話をかけさせる『電話詐欺』です。

もっともらしいことは書かれていますが、フリーダイヤルなのに固定電話番号が表示されていることで直ぐにわかります。

あわてず冷静に対処

このような場合、パソコンに問題が生じてしまったと思って直ぐに電話をかけるなどの行為をしては絶対にいけません。

あわてず、冷静に対処することが重要です。

今回の場合、危険なウェブサイトからリダイレクトされたものであったことから、単純にインターネットブラウザーを閉じてしまえば終わりな話しですが、相手はパニックになるであろう閲覧者を狙ってやっています。

もしインターネットブラウザーが終了できなければ、タスクマネージャーを開き、インターネットブラウザーのタスクを終了することで閉じることはできます。

その後にインターネットブラウザーのキャッシュなどのクリアを行い、パソコンを再起動し、インターネットブラウザーでYahoo!の画面でも開いてみて下さい。

そこで何もエラーが出なければとりあえずはOKです。

また、このような危険なサイトに誘導されないためにも、危険なサイトをブロックしてくれる機能をもったセキュリティソフトを導入されることをお勧めします。