お知らせ

現在サイトのリニューアル作業中のため、全体的にページの表示が乱れています。
投稿日:
技術::DNS技術::メール技術::セキュリティ

ここ最近なりすましメールが目立つのでなりすましメール防御対策を取りましょうという話。

なりすましメールが増えている一例

ここ数日の間にイラストレーターの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}にはstrictlaxが入る。確認内容としてはシーケンスの一番最後の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で更新系処理をしない限り基本は問題にならないと思われる。

参考

生のHTTPメッセージを見たい時に使える方法。devtoolsではフォーマットされたログしか見れないが、生のテキストを見たい時に使える。具体的には以下の画像のような奴だ。

image-1706238902445.png

よく忘れるのでメモとして残しておく

確認環境

Env Ver
Google Chrome 120.0.6099.225
Microsoft Edge 120.0.2210.144

やり方

chrome://net-internals/にアクセスするとログ収集ができるので、ログを集めたらイベントビューワで見ればよい。なおイベントビューワは外部サイトなので注意。

以前はブラウザ内で完結していて、リアルタイムに見れたはずだが、何故かできなくなっていた。

Edgeの場合はedge://net-internals/でもアクセスできるが、特にこだわりがなければ汎用性の高いchrome://net-internals/でよいと思う。

投稿日:
技術::暗号通貨

BTCの送金をしたくなったので、そのメモ

手順

幾つかサービスが存在するが今回はDMM Bitcoinを利用する。この記事はDMM Bitcoinの宣伝ではなく、私はDMMから一切報酬を受理していないことを付記しておく。

  1. まずウォレットを作成するため、サイトから適当に登録する。2024/03/01までに登録すると1000円貰えるのでありがたい。
    1. 私は金曜の20時半ごろに登録し、約2時間ほどで口座開設できた。最速1時間らしいがキャンペーンがあるのと、人間が登録作業をやってる雰囲気を感じたので時間がかかっているのだろう
    2. なお1000円の受け取り方は常識的に考えれば解ると思うので本記事では紹介しない
  2. ログインしてマイページを開き、画面左部のメニューを確認する
  3. 「日本円・暗号資産の入金」から「日本円入金(クイック入金)」に進む
    画面左部のメニューにある「日本円・暗号資産の入金」から「日本円入金(クイック入金)」
  4. 自分の持っている銀行口座を選び入金作業を行う。5000円からなので注意したい。
    自分の持っている銀行口座を選び入金作業を行う
  5. 恐らく即時入金されるはずなので、入金を確認したら「暗号資産取引」へ進む
    暗号資産取引
  6. なんかウィンドウが開くが、このままではレバレッジ取引しかできないので、現物取引を行えるように設定する
    初期状態ではレバレッジ取引をするようになっている
  7. 画面上部のメニューから「現物取引(購入・売却)」を選ぶ
    「現物取引(購入・売却)」を選ぶ
  8. すると現物取引用のウィンドウが開くので、普通にBTCを購入する。数量を入力して「Ask/買」を押せば買える
    数量を入力して「Ask/買」を押せばBTCを買える
  9. まだこの段階ではウォレットに入っていないので「口座振替」を行う
    まだこの段階ではウォレットに入っていないので「口座振替」を行う
  10. 「振替口座」を「トレードからウォレットへ」、「通貨/暗号資産の選択」をBTCに、「振替金額/数量」にウォレットに移送したい金額を入れる
    「振替口座」を「トレードからウォレットへ」、「通貨/暗号資産の選択」をBTCに、「振替金額/数量」にウォレットに移送したい金額を入れる
  11. 最後に「日本円・暗号資産の出金」から「BTC出金」を選び、画面の指示通りにやれば出金できる
    最後に「日本円・暗号資産の出金」から「BTC出金」を選び、画面の指示通りにやれば出金できる
    1. なお出金には結構時間がかかる様なので気長に待つのが良い。私の場合3回ほどやったが全て15時間ほどかかった。

あとがき

以前bitFlyerを利用しようとしたことがあるのだが、ありとあらゆる操作が非常に面倒で使う気が起きず、入金したものの、何もせず出金して退会した経緯がある。それと比べるとDMM Bitcoinはまだ使いやすい。

なおbitFlyerでは1円からの入金に対応している様なので少額利用したい場合はbitFlyerを選ぶのも一つの選択肢かもしれない。

投稿日:
技術::プロトコル::HTTP

バーチャルホストを利用することで1IPに対し複数のドメインを紐付けることが出来るが、hostsに書かないとアクセスが出来ないという面倒な問題が発生する。今回はこれを回避するためにhostsの記述無しでバーチャルホストにアクセスする方法を書いておく。

やり方としては単純で、HTTPリクエストのHostヘッダーにバーチャルホストのドメイン名を指定すると、そのバーチャルホストへのリクエストを投げることが出来る。

一例:curl http://127.0.0.1/ -H 'Host: example.com'