投稿

raspberry pi の php8.3 → 8.4 で Apache2のPHPが動作しなくなった

raspberry pi の apt からアップグレードしたところ、php が 8.3 → 8.4 となり Apache2 でPHPが動作せず、ソースが表示されてしまうようになってしまった 元々、ラズパイ5へ PHPをインストールするとデフォルトで 8.2 となるため 8.3 を入れていた(2024年3月頃)もの PHP8.4のモジュールを入れて、apache2を再起動したら動作するようになった # a2enmod php8.4 # systemctl restart apache2 参考文献

spamassassin の定義をすり抜ける U+FEFF

From が「Apple_サポート」や「TS_CUBIC_CARD」で始まる spam に対して、spamassassin の user_prefs 定義がすり抜けるため調べたところ From の先頭に U+FEFF が挿入されている 0xFE 0xFF は UTF-16BE の BOM のため、これらでエンコードされた後マッチングが行われている可能性 通常、From に U+FEFF は混入しないので、user_prefs の定義へコピペしてマッチするようになった(存在しているが、表示されない) header FROM_UFEFF From =~ // score FROM_UFEFF 4.00 抜け道として FEFFが挿入されているのか、配信システムで元ファイルのBOM削除し忘れかは不明 Unicodeと共に 、厄介だけどピンポイントでspam判定可能 U+FEFF が混入されている spam の From 文字列(U+FEFF以降の一部) Apple_サポート TS_CUBIC_CARD ANAカード InteractiveBrokers ANAマイレージクラブ事務局 ANA サポート 大和証券 大和証券セキュリティ管理部

PayPayで銀行からチャージしようとしたら「ご利用の銀行からチャージの承認がおりませんでした」

イメージ
 PayPayで長らく放置していたPayPay銀行(旧ジャパンネットバンク)を登録してチャージしようとしたら チャージできませんでした ご利用の銀行からチャージの承認がおりませんでした 詳しくは銀行へお問合せください たらい回しに合う感じ大、と思いながら銀行の問い合わせフォームから問い合わせた所 すぐに返事が来て(通常は翌営業日と書いてあった) 不審なログインの形跡を当社で検知したため、不正利⽤にあわないように⼝座の取引を停⽌させていただいた(略 残高や取引履歴を確認して問題がない旨を伝えると、すぐに制限は解除されました 昔シェアウェアの受取口座とかで公表してたから、アタックくらいは受けてたであろう...

PHPでパスを連結

PHPでパスを連結 echo path_combine(__DIR__, 'aaa', 'bbb/ccc'); function path_combine(...$paths){ $result = array(); foreach ($paths as $path){ $dirs = explode(DIRECTORY_SEPARATOR, rtrim($path, DIRECTORY_SEPARATOR)); $result = array_merge($result, $dirs); } return implode(DIRECTORY_SEPARATOR, $result); } ※末尾の区切り(/等)は削除されます ※2つ目以降の引数の先頭に区切りは使用できません

pushcode.jp の API で What(タイトル、本文)へ任意の文字列を投入

イメージ
Webプッシュサービス pushcode.jp の API を使用して通知を行っていて、タイトルと本文をAPI呼び出しで投入する方法に手間取ったのでメモ ※json を投げて通知可能な状態からの話です APIの説明 にある「変数」を使用するのですが、説明が分かりにくかった(有料との差別化?)のと What の API利用のチェックが新規作成時にしか保存されない(不具合?)のに引っかかった プッシュ 作成時に What のAPI利用にチェックを入れて、タイトルと本文に {{変数名}} を入れておく ※ここでは {{title}} と {{body}} としてます WhatのAPI利用がオフで json に what があると {"message":"API flag for 'what' is not set.","result":"error","status_code":469} というエラーを返されます API でpostする json の what -vars へ、先程の変数名: データ で投入 { "when": { "immediate": true }, "what": { "vars": { "title": "タイトル", "body": "本文" } } } こんな感じで、任意の文字列を送信可能になる pushcode.jp での通知、早くて30秒程度とけっこう時間がかかる Pushbullet(アプリ通知)と比べるとかなり遅い感じ、Webプッシュだからか、でもブラウザのGmailはすぐプッシュされてるしな...

Xbox.com 未成年アカウントの「プライバシーとオンラインの安心設定」を変更する

イメージ
 Xbox.com 未成年アカウントの「プライバシーとオンラインの安心設定」がグレー表示になって変更できない 未成年アカウントは直接変更できず、保護者用アカウント(非未成年)を紐づけて、そちらから変更を行う 必要なアカウント(マイクロソフトアカウント) 対象の未成年アカウント(登録されているメールアドレス) 保護者用アカウント 紐づけから「プライバシーとオンラインの安心設定」までの手順 保護者アカウントで Family Safety へログインして「家族のメンバーを追加」 メンバーを選択して、未成年アカウントのメールアドレスを入力する 未成年アカウントのメールアドレス へ認証メールが届くのでメール内のリンクから認証する 保護者アカウントの  Family Safety  を再度開くか再読み込みして、未成年アカウントが追加されているのを確認 保護者アカウントで Xbox.com の「 プライバシーとオンラインの安心設定 」を開く(ログインする) 未成年アカウントが表示されているはずなので、そちらを選択して各設定を行う ※一番下に送信ボタンあり

証券会社のフィッシング対策、認証コードに効果は無いのでは...

イメージ
証券会社やネットバンクのフィッシング対策に導入されている、多要素認証やデバイス認証 コードをe-mailやSMSで送ってくるのが多いが、これに意味はあるのだろうか この対策、デバイス認証必須にするから補償はしませんよ的な感じもする そもそも、フィッシングサイト経由の損失(ユーザー側の過失)を補償していたら、自作自演することで犯罪者は2度収益を上げることも可能になるわけで... 対策の本質は「 サイトのドメインを見ろ 」 一般的なコード送信 コード送信の場合、フィッシングサイトへ認証済みcookieが送られて、フィッシングサイト側のブラウザが新しいデバイスとして登録されてしまう PPAPのように同じルート上で入力(①, ④)を行うのでは、ひと手間多いだけ (ApplePay + イオンカード + iD の不正登録と同じ) 考えられる対策(Webのみを利用した場合) 認証コードの代わりにURLを送り、開いてもらう (メールのリンクをそのまま開くという時点でどうかとは思うが、1の前に既にそれをやっていると思われる) フィッシングサイトを経由している場合、ログイン時(ID, PW)のCookieと不一致になりブロック可能 認証URLを開くブラウザがログイン時と同じブラウザでなければならない フィッシングサイトが受信したURLをコピペしろ、となっていてそれに従うと無力