お知らせ
現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
- 投稿日：
最近クレジットカードの不正利用についてよく聞くが、個人に取っている対策を書いておく。
使わないサービスのアカウントからはクレジットカード情報を削除する
これはカード番号が漏洩する恐れがなくとも不正利用のリスクがあるからだ。
例えば何かしらの理由でアカウントが乗っ取られたり、サービス側で不正操作されたときに予期しない課金が行われる可能性はある。正直、個人的にサービス側を全く信用しておらず、オペミスやストライキの一環、悪意のある社員によるいたずらなどで不正請求が起きる可能性も懸念している。
クレジットカード情報の紐づけが削除できないサービスは極力利用しない
例えばOpenAIやNotionでは一度クレジットカードを登録すると削除できない、こういうサービスは怖い。基本的にカード情報を登録しない方向に倒している。
やむを得ず登録してしまった場合は、そのサービスを使わなくなったらアカウントを削除することにしている。
正直、クレカの紐づけ解除できないサービスは全部滅んで欲しい。
解約したカードは強制停止させる
例えばSMBCでは解約したカードであっても有効期限まで使える仕様があるため、番号漏洩やクレジットマスター攻撃などによって被害を受ける可能性がある。そこで取れる対策としてはカードの強制停止だ。これはサポートセンターに連絡することでカードそのものを無効化する方法だ。カード番号が機能しなくなれば不正請求される可能性もなくなる。
因みにこの手続きは正規のものではないため不必要に使うのは控えたほうがいいと思う。
逆に言うと解約したカードでも有効期限までは使えてしまうため、サブカードとして使うなどの使途もあるので、利活用の道があるのなら残しておくのも悪くはない。
- 投稿日：
ここ最近なりすましメールが目立つのでなりすましメール防御対策を取りましょうという話。
なりすましメールが増えている一例
ここ数日の間にイラストレーターのIxy先生やMastodonインスタンス管理人のにょき氏といった一定の知名度を持つ人物を中心になりすましメールの被害にあっているようだ。
ここまで目立つのは余り見聞きしなかったので恐らくここ昨今のGMailとかの騒動を見たところで、なりすましメールを作れることに気づいた人物が愉快犯的に行為をしているのだろう。
取りうる防御策
個人レベルでできる対策としてはDNSレコードやメールサーバーの設定にSPF, DKIM, DMARCを設定することだ。これらの内容についてはGoogleによるDMARC を使用してなりすましと迷惑メールを防止するが詳しい。
さくらのレンタルサーバーを利用している場合は以下が参考になる。
さくらのレンタルサーバーを利用して外部DNSを利用している場合は、私が以前書いたValue-DomainのドメインをさくらのレンタルサーバーのメールでSPF, DKIM, DMARC対応させるが参考になるだろう。
SPD, DKIM, DMARCの三点を設定することで相手のメールサーバーがこれらに対応している場合になりすましメールを迷惑メールとして分類したり、メールの受信を拒否できるとされているため、設定することでなりすましメールを防御できる可能性が高まる。
メール送信に使っていないドメインに関しても以下のようなDMARCを設定しておくことで、悪意のある第三者によるなりすましを防げるだろう。
txt _dmarc v=DMARC1; p=reject; aspf=r; adkim=r
またメールサーバーを運用されている各位におかれては、SPD, DKIM, DMARCの三点を識別し、適切に受信メールをフィルタリングできる仕組みを導入して頂けると犯罪予告や迷惑メールによる被害を減らせる可能性があるので、是非とも導入を検討いただきたい。
- 投稿日：
前職で古いWebシステムのマイグレーションしてた時に思ったのだが、SameSite CookieがあればCSRF Tokenは最早いらないのではないか？というのに気が付いたので調べてみた話。
結論として言うとEdgeではPOSTリクエストでCookieが飛ぶ事はないので、CSRF Tokenを考慮する必要はなさそうに思える。
理由としてはCookieでSameSite=strictを指定している場合、クロスドメインでのCookie送信がブロックされるという話が事実であればCSRF Tokenは不要であるはずだからだ。
これによって悪意のあるサイトからAjaxやリダイレクト、フォームなどを使った攻撃をした場合にサーバーにCookieが送信されなくなる筈なので、理論上は問題なくなる。
以下では実際にCookieが送信されるかどうかの動きを見てみた。確認環境はMicrosoft Edge 121.0.2277.83。方式のリンクはシーケンス図になっている。
シーケンス図に書いてあるSameSite={var}の{var}にはstrict、laxが入る。確認内容としてはシーケンスの一番最後のHTTPリクエストでCookieが送信されているかどうかを見ている。noneは面倒なので見ていない。
| 方式 | SameSite=strict | SameSite=lax |
|---|---|---|
| HTTP 302 REDIRECT | 送信される | 送信される |
| アンカーリンクのクリック | 送信されない | 送信される |
| アンカーリンクのクリック→HTTP 302 REDIRECT | 送信されない | 送信される |
| location.hrefでの移動 | 送信されない | 送信される |
| location.hrefでの移動 →HTTP 302 REDIRECT | 送信されない | 送信される |
| FORMタグのsubmit(GET) | 送信されない | 送信される |
| FORMタグのsubmit(POST) | 送信されない | 送信されない |
SameSite=strictだと外部サイトから開いたときにCookieが送信されないため、Google検索などから流入された時のログイン状態に不都合が出ると思われるので、その様なケースではSameSite=laxが無難だろう。
SameSite=laxの場合、GETリクエストではCookieが送信されるため、CSRF攻撃を受ける可能性があるが、GETで更新系処理をしない限り基本は問題にならないと思われる。
参考
- 2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか | 徳丸浩の日記
- Cookies: HTTP State Management Mechanism (httpwg.org)
- httpwgによるドラフトの仕様（ブラウザがこれを守るかどうかはまた別の話）