公開しているメールアドレスは、最近トレンドなフィッシングメールをピックアップで紹介したように、フィッシングメールが毎日山ほど届きます。せっかくなので訪問してみました。 フィッシングサイトに嵌ってみました 最近のブラウザは […]
IT実践
偽サイトに嵌って防衛手段を検証する
phishing
IT実践
最近トレンドなフィッシングメールをピックアップ
JALがフィッシングメールで騙され3億8000万円を失ったというニュースは記憶に新しいところです。 プレスリリースを送信すると、連絡先メールアドレスが複数のWebサイトに載ったままになるわけですが、あえてそのアドレスを削 […]
ICT実践記事
- 常時SSL化（https）後に旧サイトのアクセスが減らない
最近SSL化したサイトで旧サイト（http）へのアクセスが一向に減らないという現象が発生しました。 httpへのアクセスを301リダイレクトでhttpsへ遷移。 Google Search Consoleのプロパティにhttpsサイトを追加。旧サイトも削除せずに監視。 これで安心してしまっていたのですが、1ヶ月経っても、Google Search Consoleで旧サイト（http）の表示回数が減らない。（一時的に減少しましたが、盛り返してきている）平均掲載順位に至っては上昇している。 どうもおかしいと思い調べたところ、もともとHTTPヘッダとしてcanonical属性を出力していたのですが、スキンをカスタマイズした際に書き出されなくなってしまっていたようです。 これはChromeのデベロッパーツールを使って以下のように確認しました。 HTTPレスポンスヘッダ・リクエストヘッダの確認方法 Chromeを開き[F12]を押してデベロッパーツールを開く。 Networkタブを選択しておく。 HTTPヘッダを確認したいページを開く。 Nameの一番上（AdSense等がある場合は2番目以降になっている場合があります）にある該当ページをクリックする。 Headersタブをクリックするとレスポンスヘッダやリクエストヘッダが確認できます。 全てのページで<link rel=”canonical” href=”ページURL”>を<head>～</head>内に出力するように修正して完了です。 ※ページURLには各ページのURLを正確に書きます。
- 自社・自宅サーバーをVPSに移行するための有力候補3サービス
ConoHa VPSがリニューアルされました。自社サーバーの移設先として使えそうなVPSサービスを実際に契約して試した結果を独自の視点から検証しました。
- 時代錯誤な自社サーバーをクラウド（VPS）にするメリット
いまだに回線もサーバーも自社運用しているWeb制作会社がクラウド（VPS）への移行を考えて現在の構成を見直してみる。ランニングコストもさることながらスキル習得に無駄な時間を注ぎ込んできた気がする。
- Webの文字サイズはvwでシルバーファーストに
Webコンテンツをシルバーファーストで Web制作において「パソコンで表示する文字サイズはvwを使ってmax-widthは1920pxまで対応するべき」という話。 最近は年配の方でも自宅でネットを楽しんでいますが、小さい文字が読みにくいためブラウザを最大化にしている姿をよく見かけます。 残念なことに、有名どころを含めてほぼすべてのサイトで文字は大きくならずに、左右の空白が増えるのみ。 「Ctrlを押しながらマウスホイールで拡大」すれば大抵のブラウザでは拡大されますが、そんな技を使っている一般高齢者を見たことがありません。 パソコンのディスプレイサイズは昔と比べて大きくなりましたが、それと共にディスプレイの高精細化も進んできたため、「目が悪くなってきたから大きなディスプレイを買うかのう」は期待を裏切られる結果となってしまいます。 一般的にWeb制作の現場では、幅1920px以上で見る人向けに作ってしまうと、小さいディスプレイ（解像度の低い）を使っている人や、ブラウザを最大化しないで使用している人には表示がはみでてしまうため、幅1000～1200pxで見た時に最適になるように制作されています。 少し前まではタブレットやスマホはこれよりも画素数が少ないものが多かったため、レスポンシブデザインという表示サイズによって可変のデザインが主流になりました。 しかし可変とは言っても通常はモバイル対応がメインです。画素数の大きい端末での全画面表示は基本的にあまり考慮されず、大きすぎる端末から見た場合にデザインが崩れるのを嫌がり、上述のように幅1000～1200pxを超えた場合は、それ以上には広がらずに左右の余白だけが広がるというのが現状です。 高齢化時代のWebスタンダートに max-width は最低でも1920px、4Kが主流になることを考えると4000px程度までは欲しいです。 メニューやヘッダ・フッタ等以外のコンテンツ部分のフォントサイズは、vwで指定。 これでサイトを作ってみたところ閲覧が非常に楽でした。 椅子にふんぞり返ったままでも、ブラウザを最大化すれば楽に文字が読めます。 あいにく当サイトはまだ着手できていませんので下記サイトをご覧ください。 ブラウザを最大化もしくは幅を広げると、デザインが崩れない範囲で文字も大きくなります。 現在主流のディスプレイ解像度を考慮して […]
- 人柱：Windows 10 v1803(RS4)更新プログラムKB4100403 (17134.81)
Windows 10 バージョン1803の更新プログラムKB4100403、週末様子を伺っていたのですがなかなか人柱情報が少ないようなので、今からメインPCに導入してみようと思います。 仮想環境で問題がなくてもメインPCだと全然変わってきたりするんですよね。 KB4100403（17134.81）の概要 Internet Explorerの問題により、Webページへの複数回の訪問で特定の非同期シナリオでWebワーカー間の通信が失敗する可能性があります。 更新されたタイムゾーン情報に関する追加の問題に対処します。 クローズドキャプションの設定がアップグレード後に保持される問題を解決します。 オーディオまたはビデオの再生が開始されている間に新しいオーディオエンドポイントを作成すると、Microsoft Edgeや他のアプリケーションが応答を停止する原因となる信頼性の問題が解決されます。 dGPUを持つ特定のハードウェアでWindows Helloの登録が失敗する可能性がある問題に対処します。 特定のベンダーのNVMeデバイスを搭載したシステムの電源回生に関する問題に対処します。 Intel SSD問題は対策済み。 東芝バッテリ問題も対策済みだが6月まで待てと。 私は4番目のオーディオ・ビデオが関係する不具合対策に期待。 2018年5月28日の正午になってもこのサイトの更新がなかったら、お察しください。 KB4100403(17134.81)ダウンロード先 Windows Update カタログ（KB4100403） KB4100403情報 以下2018年5月28日18時追記 更新が遅くなってしまいましたが、KB4100403更新プログラムのスタンドアロンインストールが無事に完了しバージョン17134.81になりました。 導入によるトラブルは一切ありませんでした。 ダウンロード時間を除いて、更新にかかった時間は3分程度、1回の再起動だけでした。 ただ更新後ログインをして、すぐにWindows Update画面を開いたところ真っ白で一瞬ドキッとしました。（KB410372あたりでWindows Updateが表示されないのを嫌というほどみたばかりなので。そのあたりの詳細はWINDOWS 10 APRIL 2018（1803）の不具合【前編】をご覧ください。） もう一回再起 […]
- ついき来たのか！？Windows 10 バージョン1803安定版。
2018-05 x64 ベース システム用 Windows 10 Version 1803 の累積更新プログラム (KB4100403) Windows Updateカタログ 飛びつこうと思ったんですが、先週のトラブルが嘘のように、サウンドドライバの更新をして以来とても安定していまして。（詳しくはこちらの記事の下のほうをご覧ください） 「魔の1週間よ再び」ってなりたくないしな～。 今回の更新ですが、Microsoft気合入れてきてますね。 ビルド17134.81（0.80も上がった～） 430MBってサービスパックレベルですね。 しかし、今回ばかりは人柱お願いします。 ｍ(__)m まあ、週が明けたらやってみますね。 追記：その後KB4100403インストールして動作検証しました。
- 偽サイトに嵌って防衛手段を検証する
公開しているメールアドレスは、最近トレンドなフィッシングメールをピックアップで紹介したように、フィッシングメールが毎日山ほど届きます。せっかくなので訪問してみました。 フィッシングサイトに嵌ってみました 最近のブラウザはデフォルト設定で注意喚起してくれます。 Chromeの場合 Firefoxの場合 Firefoxのほうがキッパリと言い切っていてかっこいいですね。 どのブラウザも、うっかり誤クリックで進んでしまわないように「無視して進む」というボタンが無いインターフェイスになってますが、頑張って先に進んでみました。 仮想PC・ブラウザをプライベートモード・LAN切り離し・IPアドレス変更等を行ったうえでの検証です。アクセスするだけで様々な情報を抜かれる恐れがありますので、安易に先に進むようなことはしないようにしてください。 APPLEっぽいサイトが表示されました。 一見APPLE公式のように見えますが、中央の入力フォーム以外はリンクすらされていない張りぼてです。 ですが疑いの目を持って見ない限り、偽サイトだということに気づかないと思います。 フィッシングサイトの見抜き方 騙されないためにはアドレスバーに表示されているURLをよく見てください。まずこの習慣をつけましょう。 見るのは最初に現れるスラッシュ「/」よりも左側です。それよりも後（右側）は一切気にしないで大丈夫です。 http://cert-protection-account-appleid-apple.com ブラウザによっては cert-protection-account-appleid-apple.com とhttp://（またはhttps://）が省略されて表示されます。 以下のような場合にはさらに注意が必要です。 apple.example.com/rmd_nid_vcss… google.example.com/rmd_nid_vcss… ドメイン名「example.com」の前にドット「.」が入っている場合、それより左側はドメインの保有者が自由に好きな文字を設定できるサブドメインと呼ばれます。 一番最初に知っている名前が入っているからといって絶対に信用してはいけません。 itunes.apple.com これはitunesがサブドメインですが、その右側を見るとドメイン名がapple. […]
- WordPressの引越しプラグイン『Duplicator』の正しい使い方
WordPressを使い慣れていて、ドメイン変更等も手動でsql置換して～とやった事がある方が「今回は楽にやってみたい」と、ナメてかかると意外とハマります。 ドキュメント読めば書いてあるんでしょうが、甘く見ているだけに慣れ親しんだ日本語ページをGoogleで探して斜め読みして取り掛かるものですからなおさら。 移転先サーバーにはWordPressをインストールしない。 これ重要です。 多くのサイトで「WordPressをインストールしておく」と書いてありますが、zipが解凍できなかったり、パーミッションの問題が発生したりと問題を引き起こします。 私もエラーが発生したので、サーバーコンソールでunzipのパス確認したり、installer.phpの該当部分を眺めてみたりしましたが、ディレクトリを削除するだけでOKでした。 新しいサーバーに設置するのは旧サーバーからダウンロードした2つだけ。 installer.php 20180000_XXXXXXX_archive.zip これだけの記事なんですけど、少し寂しいので他のポイントも挙げておきます。 installer.phpにアクセスする前にドキュメントルート（public_html等）を一旦707等にしておき、終わったら戻す。 nginxでキャッシュを使っている場合には止めておかないとハマる。 正常に動作することが確認できたらアップロードした2つ以外にも消しておいたほうが良さそうなファイル。 20180000_XXXXXXX_archive.zip installer.php database.sql installer-backup.php web.config installer-data.sql .htaccess （旧サイトで使用していた場合を除く） installer-log.txt Contact Form 7等でGoogleのreCAPTCHAを使っている場合などは「サイト所有者のエラー:サイトキーのドメインが無効です」と表示されていると思うので申請を忘れずに。 旧サイトへの301リダイレクト設定。
- バッファローLinkStationの管理画面が重い
BuffaloのLinkStationというネットワーク対応の外付けHDDを使っていますが、管理画面が何をするにも異常に遅くて、他の方も書かれていましたが設定するのが億劫になります。 ファームウェアの更新やメディアサーバーをオフにしてみたりしましたが解決しなかったのですが、原因がわかりました。 Buffalo LinkStation 管理画面の動作を速くする方法 Internet Explorerで管理画面にアクセスすると、実用レベルの遅さになりました。 それまではGoogle Chromeを使っていたのですが、メニュー項目をクリックするたびに5秒～10秒、ひどいときにはそのまま処理が返ってこないという状況でした。 ひょっとしてと思いIEからアクセスしてみたところ、画面遷移に1～3秒程と（じゅうぶんに遅いですが）設定するには実用的なレベルになりました。
- WordPressをお名前.comのレンタルサーバーRSプランに引っ越しをする際の注意点
お名前.comのコントロールパネルからMySQLファイルをインポートしようとするとエラーが発生した際の解決方法。WordPressのファイル転送はFileZilla（SFTP）を使って問題なく完了。
- PukiWikiのURLをNginxで正規化【index.php非表示】
10年以上ぶりにPukiWikiをいじっているんですが、昔の情報は豊富にありますが最近の情報が乏しいですね。 PukiWikiの全盛期は、Nginxが誕生したばかりでしたので仕方ないのかもしれませんが。 PukiWikiのindex.php無しでURLを統一する URLの正規化としてまず、 http://example.com/ http://www.example.com/ https://www.example.com/ これらをhttps://example.comに301リダイレクトしました。 これについては各所に載っているようにserverディレクティブを追加して、return 301～といった感じです。（ここでは詳細は割愛します） これで完璧！と思いつつGoogle Search Consoleを眺めているとindex.php有りと無しが…。 pukiwiki.ini.phpの設定でindex.phpを表示しないという項目があります。 // Shorten $script: Cut its file name (default: not cut) //$script_directory_index = ‘index.php’; コメントアウトを外して試してみましたが、何かが違う。 確かに表示はされなくなりました。 index.php有りの膨大なURLがすでにGoogleにインデックスされているので、index.php有りで404エラーになると困るのですが、結果はindex.phpを入れたURLでもちゃんとページが表示されました。 しかしindex.phpが表示されたままの状態。ステータスコードは200。index.php有りと無しの両方のページが存在した状態です。 ということでNginxの設定を変更しました。 server { if ($request_uri ~* “^(.*/)index\.php(.*)$”) { return 301 $1$2; } } 上記のようにdefault serverディレクティブに書き加えて、 nginx -s reload で完了です。 PukiWikiネタってまだ需要あるんでしょうか。 今回PukiWiki 1.5.2（utf8）をベースに以下のようなカスタマイズをしたのですが、要望があれば時間を見つけて記事 […]
- WP-PageNaviで2ページ目以降が404エラー【解決】
最近すっかりWordPressから離れていたんですが、良くも悪くも情報量が豊富ですね。 WordPressは10年以上前（WordPress MEの頃）からいじってますが、どんどん複雑化してきて最近はhome.phpやらfront-page.phpやらindex.phpやらと、テンプレート構造を理解するのさえ大変です。 時間があったので何年か前に構築したサイトを手直ししていたところ、トップページのページネーションが効かなくなってしまいました。 100個近いカスタムフィールド・300超えのカテゴリ・function長すぎなコンテンツで、どのタイミングで表示されなくなったのか不明なまま、ネット上の情報を頼りにあれこれ試して半日が過ぎ、ようやく解決しました。 固定ページ用WP-PageNavi対策コード function.php function pagenavi_home($wp_query) { if (!is_admin() && $wp_query->is_main_query() && $wp_query->is_home()) { $wp_query->set(‘cat’, 5); $wp_query->set(‘post_type’, ‘iisys’); $wp_query->set(‘posts_per_page’, 12); } } add_action(‘pre_get_posts’, ‘pagenavi_home’); 3行目のcatはカテゴリーID5を指しています。不要であれば行ごと削除。 4行目のpost_typeはカスタム投稿タイプを指定。iisysは一例で、通常の投稿であればpostになります。 両方を指定したい場合には配列にします。 $wp_query->set(‘post_type’, array(‘post’, ‘iisys’)); 5行目のposts_per_pageは表示件数。記事数よりも多い数にするとページネーションは表示されません。 上記を書いたうえで、該当テンプレート（私の場合はindex.php）のquery_posts等を消してください。 以下は私の環境では効果ありませんでした。 管理画面の表示設定にある「1ページに表示する最大投稿数」を1件にする pa […]
- タリーズ オンラインストアでカード情報が漏洩【ペイメントアプリケーションの改ざんについて】
出典：経済産業省 商務・サービスグループ 商取引監督課 ペイメントアプリケーションの改ざんとは、オンラインでクレジットカード情報を入力する時に、悪意のある人がその入力フォームをこっそり変えてしまうことです。これによって、ユーザーが入力した大事な情報が盗まれるのです。 2024年10月3日、タリーズコーヒーが発表したところによると、約5万3000件のクレジットカード番号やセキュリティコードが漏れてしまった可能性があるとのこと。この事件の原因も改ざんでした。 この手口は10年以上前からあるのに、最近でも被害が後を絶ちません。私たちも、オンラインでカード情報を入力する時は、特に注意が必要です。大切なお金や情報を守るために、しっかり気をつけましょう。 ↑ AIに生成させてみた文章です。 ↓ 人間が書いてます。 漏洩した可能性がある情報は以下のように非常に深刻なものです。 漏洩した可能性がある情報 個人情報 ・氏名 ・住所 ・電話番号 ・性別 ・生年月日 ・メールアドレス ・ログインID ・ログインパスワード ・配送先情報 クレジットカード情報 ・クレジットカード番号 ・カード名義人名 ・有効期限 ・セキュリティコード 今回のタリーズオンラインショップ程のECサイトであれば、私も安心してカード情報の入力をしてしまうと思います。 利用者が自己防衛をするのはかなり難しいです。 かといってECサイト側での対応も難しいのが現状です。 例を挙げますと、つい先週になりますが楽天市場で買い物をした際に、不正アクセスを疑われたようで「注文キャンセル＆アカウントロック」をされてしまいました。 ここ何年も利用していなかったのに5万円程度のものを立て続けに購入したというのがAIに犯罪の可能性を疑われ、仕事で必要なものを買っただけなのにこれでは別の意味で信頼を失ってしまいます。 楽天市場ほどの規模にもなると、一定のスコアで黒扱いにするというシステムにするしか方法は無いのかもしれませんが、厳しくすれば善良なユーザーに迷惑が掛かり、緩くすれば悪意を持ったユーザーがすり抜けるという難しさがあります。 迷惑メールのフィルタリングや、警察による職務質問などにも言えることなんでしょうが。 また、タリーズから発表があったこの文章が気になります。 既に弊社では、クレジットカード会社と連携し、漏洩した可能性のあるク […]
- XMLサイトマップをGoogle Search Consoleに準拠
インデックス登録されましたが、サイトマップに送信していません Google Search Consoleのカバレッジで緑色の有効（インデックスに登録されている）になっているものの、「インデックス登録されましたが、サイトマップに送信していません」という詳細情報が気になりました。 クリックしてみると「例」としてURL一覧が表示されます。 そのURLをさらにクリックすると、UTF-8でエンコードされたURLが表示されます。 送信しているXMLサイトマップもUTF-8でエンコードをしていますし、URLの正規化も済んでいるのになぜ？ じっくりと見比べてみると、XMLサイトマップのURLはスラッシュが「%2F」にパーセントエンコーディングされているのに対して、Googleでは「/」のままです。 サイトマップを出力しているphpソースを見てみると、PATH_INFOをrawurlencodeでエンコードしています。 rawurlencodeはRFC3986にもとづいて「-_.~」とアルファベット以外をすべてエンコードするようですので妥当なはずです。 Google独自仕様？と思ったのですが、RFC3986の3.4章に「スラッシュ (“/”) と疑問符 (“?”) の文字はパーセントエンコーディングする事を避けるほうがユーザビリティのためにはよい。」という記述がありました。 スラッシュはパーセントエンコードしないように修正 GoogleもRFCもスラッシュはパーセントエンコードしないと提唱しているのであれば、これに合わせるべきだと思い以下のように修正しました。 $r_page = rawurlencode($page); $r_page = str_replace(‘%2F’, ‘/’, $r_page); 修正後、XMLサイトマップの出力とGoogle Search ConsoleのURLを比較するとマッチしていましたので、これで解決です。
- WordPressの引っ越し・ドメイン変更ツール「Search Replace DB」日本語版配布
WordPressの引っ越しやドメイン変更の際に「All-in-One WP Migration」よりも「Search Replace DB」を使った方が良い理由。Search Replace DB日本語版のダウンロードができます。