Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature / Mediumの独自ドメインプランを使って訪問者のメールアドレスが窃取できる脆弱性の開示
0_medium_vuln_en.md Disclosure of a vulnerability that allows the theft of visitors' email addresses using Medium's custom domain feature Author: mala Introduction This article describes a vulnerability in a web service called Medium that allows you to steal visitors' e-mail addresses by using custom domain plan of Medium. This is done as my personal activity and is not related to my organization.
大量メール送信のための予備知識 - エムスリーテックブログ
【SREチーム ブログリレー1回目】 お疲れ様です。エンジニアリンググループ、コアSREの山本です。 他の情報伝達手段が現れた今は「メール」は以前よりも比重は落ちたかもしれませんが、まだまだ多くの人に情報を一気に伝えるための重要なツールです。 エムスリーでは自社サーバを利用してメールの大量送信を実施していますが、メール送信を実施するにあたって気にすべき基本的な事項についてシェアさせてください。 大量メール送信に関連する基本的な設定 基本的な設定(SPFと逆引き) DKIM IPの追加削除 バウンスメール処理 金で解決 まとめ We are Hiring! 大量メール送信に関連する基本的な設定 メール送信自体はそれほど難しいものではありません。 エムスリーではpostfixを利用していますが、設定はほとんどオリジナルでもメール送信自体は可能です。せいぜいドメイン名を登録するくらいでもいけます
忘れ去られたドメイン名に宿る付喪神 | IIJ Engineers Blog
開発・運用の現場から、IIJのエンジニアが技術的な情報や取り組みについて執筆する公式ブログを運営しています。 こんにちは。IIJ Engineers Blog編集部です。 IIJの社内掲示板では、エンジニアのちょっとした技術ネタが好評となって多くのコメントが付いたり、お役立ち情報が掲載されています。 そんな情報を社内に留めておくのはもったいない！ということで、IIJ Engineers Blog編集部より、選りすぐりの情報をお届けします。 今回は、使わなくなったドメイン名はどのようにすればよいかを紹介します。 そのまま放置しておいてよいのか？（ダメ） 廃止すればよいのか？（もっとダメ） どういった対応を行えばよいのか？ どうぞご覧ください。 終わったサービス・キャンペーンのドメイン名、放置されていませんか？ ドメイン名を放置すると付喪神がやどり、ひとりでにサイトを公開したりメールを出し始め
DNS前史：HOSTS.TXTとドメイン名ができるまで
こんにちは、技術開発室の滝澤です。 先月（2022年7月）、『Software Design 2022年8月号』の特集記事『WebエンジニアのためのDNS速習講座』に『第2章：DNSの構成要素と名前解決のしくみ』という記事を寄稿しました。第1章でも滝澤が趣味で作成した資料『ドメイン名の歴史』が参考文献として掲載されていました。よい機会なので、ドメイン名ができるまでの歴史について文章としてまとめようと思い、この本ブログ記事を書きました。 なお、筆者自身はインターネットの原型であるARPANETや80年代のインターネットをリアルタイムには体験してはいないため、RFC（Request for Comments）やインターネット上にある当時のホストのアーカイブを元に調査した内容をまとめたものになります。 ARPANETの時代 1969年から1980年代初期にかけてのインターネットの原型となったAR
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
AWS SESで信頼性の高いメール送信(SPF, DKIM, DMARC) with Terraform - 電気ひつじ牧場
メール認証の仕組みと、SESでのTerraformを使った設定方法について紹介します。 メール認証の種類 メールメッセージ MAIL FROM FROM SPF(Sender Policy Framework) DKIM(DomainKeys Identified Mail) DMARC SESの設定 SESで利用するドメイン認証 DKIM設定 DMARC with DKIM DMARC with SPF 参考 メール認証の種類 メールでは送信元のなりすましを検出するための認証の仕組みとして、主に以下の3つがあります。それぞれRFCで定められています。 SPF(Sender Policy Framework) DKIM(DomainKeys Identified Mail) DMARC(Domain-based Message Authentication, Reporting, and
取得したドメインで送信するメールの信頼性を上げる方法 - アルパカの徒然文
ドメインを取得後にそれを使ったメールアドレスで送信できるようになったが、受信先でそのメールが迷惑フォルダへ分類されることがある。 会社では Google Domain でドメインを取得後、Google Workspace を利用してメールを送信できるようになった。DNS の管理は Cloud DNS を利用していて、その設定は Terraform を用いて管理している。 当初の設定はシンプルなものであった。 DNS ゾーンを設定 設定したゾーンに対して MX レコードを設定 resource "google_dns_managed_zone" "example_com_domain" { name = "example-com" dns_name = "example.com." } # https://support.google.com/a/answer/9222085 resourc
DNSpooqの脆弱性詳細と攻撃コード解説 - knqyf263's blog
概要 要約 詳細 背景 前提 インターネット上に公開されたdnsmasq LAN内のマシンが攻撃者の支配下にある LAN内のマシンに攻撃者管理のWebサイトを閲覧させることができる 影響 中間者攻撃 汚染拡大 DDoS/Reverse DDoS CVE-2020-25684: ポートの多重化 CVE-2020-25685: 脆弱なCRC32の利用 CVE-2020-25686: 同一ドメイン名に対する複数クエリ発行 DNSフォワーダにおけるレスポンスの未検証 組み合わせる ドメイン名の登録 ソースIPアドレスの偽装 CRC32の衝突 攻撃の流れ ブラウザからの攻撃 検証端末 攻撃の成功確率 PoC fowarder cache attacker 大量クエリの送信 偽装レスポンスの送信 高速化の話 実行 対策・緩和策 余談 まとめ 概要 先日DNSpooqという脆弱性が公開されました。 ww
ITPのCNAMEクッキー規制について｜AD EBiS マーテック研究会
ご無沙汰しております。11月6日に、CNAMEレコードを使って付与された1st-party cookieの規制機能を搭載したiOS14.2がリリースされましたので、その内容をまとめます。いつものことですがマーケティングよりブラウザの細かい話です。正式発表前なので誤りの可能性がありますがご了承またはご指摘ください。 規制の仕組みまず規制されるのは、AppleのWebKitエンジニアJohn Wilanderさん（ITPの発明家）が「Third-party CNAME cloaking」として定義するものです。 Third-party CNAME cloaking means a first-party subdomain resolves to a third-party domain which does not match the resolution for the top frame
ioドメイン障害を理解するため、DNSの仕組みについて勉強した - $shibayu36->blog;
先日、ioドメインの障害があったのだけど、自分がDNSの仕組みをよく分かっていないせいで、いまいちどういうことが起こっていたのか把握できなかった。そこで、DNSの仕組みについて軽く勉強したので、そのメモを残しておく。内容は間違っているかもしれないので、その場合は指摘してください。 DNSについて学んだこと Software Design 2015/4のDNSの教科書が非常に勉強になった。また、 インターネット10分講座：DNSキャッシュ - JPNICも参考になる。 権威サーバとフルリゾルバ まず、DNSサーバには権威サーバとフルリゾルバの二つの種類が存在する。 権威サーバ ドメインの情報を管理し、自分の管理しているゾーンの情報を提供するだけのサーバ 問い合わせたドメインが自分のゾーンの管理下ではない場合、別の権威サーバへ委任するという情報を返す コンテンツサーバとも言われる? 例) co
DNS - moin.qmail.jp
1. DNS DNS辞典を目指すwikiです。 右上の検索ボタン(タイトル、テキスト)を活用してください。 twitter: beyondDNS https://djbdns.qmail.jp/ Domain Name System (DNS) DNS/NEWS /項目一覧 /難しい DNS入門 1.1. 特長 「ドメイン名」空間(集まり)を「共有」統合するための仕組みです。 /基礎 /分散管理 /統合 /委任･委譲 ドメイン名は階層構造をしています。 ドメイン名の階層にしたがって、分割･管理されています。ドメイン名には属性を持たせられます。 /ドメイン名, /ゾーン, /ドメイン名登録 などに分けて、説明します。 ｢分散｣、｢統合｣の仕組みが｢委任･委譲｣です。 それぞれの｢ゾーン｣を管理しているのが権威サーバーです。/ゾーン /権威サーバー ドメイン名空間内の検索を受け持つのがリゾルバ
リソースレコードの種類と役割とは (1/2)
DNSのネームサーバは、ドメイン名（及びホスト名）とIPアドレスの対応をデータベースとして保持している。このデータベースが持つデータを「リソースレコード」と呼ぶ。 このデータベースとリソースレコードの構造と形式は、DNSサーバソフトによって異なる。もっとも有名なDNSサーバソフトの「BIND」では、「ゾーンファイル」と呼ばれるデータベースをテキストファイルとして保持している。BINDでは、ゾーンファイルにホスト名とIPアドレスの対応などのリソースレコードを記述している。以下、BINDのゾーンファイルを基準に解説を進める。 リソースレコードにはいくつかの種類（レコードタイプ）が存在する。一般的に使用されている主なリソースレコードには次のものがある（図1）。 A（アドレス） CNAME（キャノニカルネーム） MX（メールエクスチェンジ） NS（ネームサーバ） SOA（スタートオブオーソリティ）
さくらのメールボックスを使うときのDNS設定 at softelメモ
問題 Webサーバーとメールサーバーを分けたい。独自ドメインでWebサイトを稼働させているサーバーとは別のサーバーで、独自ドメインでメールの送受信をしたい。 さくらのメールボックスのサービスを使おうと思う。 さくらのメールボックスの画面の案内だと、NSをさくらのNS（ns1.dns.ne.jp、ns2.dns.ne.jp）にせよとのこと。同じドメインでWebサイトも稼働させてるので、NSを変えるのは避けたい。NSは今のままにするならどうしたらいいの？DNS設定はどうしたらよい？ 答え すでに運用中のドメインで、DNS設定がされていて、MXレコードだけさくらのメールボックスに向けたいときは、以下のようにする。 １、さくらのメールボックスのホスト名を調べる さくらのメールボックスに申し込んだら、以下のようなホスト名が発行される。 ********.sakura.ne.jp ２、さくらのメールボ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
送信ドメイン認証の現状
近年のDNSはプロトコル拡張が活発すぎる!? 現時点で意識しておくべきリソースレコードとは【DNS Summer Day 2022】
/blog/2020/10/20201027_subdomaintakeover/
ハッカーによる「DNSハイジャック」の急増が、インターネットの信頼性を破壊する
変化するDNSとサーバー証明書の関係～「ランチのおともにDNS」より【Internet Week 2017】
DNSについて