Slide 1

Slide 1 text

詐騙網站開發經驗分享 小 畢 CrBoy

Slide 2

Slide 2 text

保護當事網站

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

支 援 HTTPS

Slide 5

Slide 5 text

當然要有些選單跟精美圖片

Slide 6

Slide 6 text

按鈕是 一 定要的

Slide 7

Slide 7 text

哪個正經的網站不發些公告呢

Slide 8

Slide 8 text

提醒使 用 者避免詐騙!貼 心 !

Slide 9

Slide 9 text

身 為 一 個軟體開發者

Slide 10

Slide 10 text

約耳趣談軟體

Slide 11

Slide 11 text

「讓錯的程式看得出錯」 "Making Wrong Code Look Wrong"

Slide 12

Slide 12 text

讓詐騙網站看得出詐騙 Make Fraud Site Look fraud

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

故事的起源

Slide 16

Slide 16 text

某銀 行 某銀 行 .某寄信公司 某寄信公司

Slide 17

Slide 17 text

我:???? 人 家銀 行 找外包,何必非要 自己 的 mail server 才 行 原PO說不是銀 行 的,明明 就有 ,有問題嗎 某銀 行 其實很多銀 行 的紙本帳單 都是傳檔案給專 門 印帳單 的公司印刷、封裝、郵寄 的。申請的時候都放棄這 些權利了 這位是不是腦筋有問題啊, 明明是 某銀 行 .某寄信公司

Slide 18

Slide 18 text

我:👍👍👍👍 防釣 魚 教戰 一 點就是確認網址 寄件 人 結果銀 行自己 沒遵守 造成使 用 者混淆 用 非 自身 的網域 以後被詐騙集團利 用 的機會很 高 紙本帳單是銀 行自己 送嗎? 找郵局會不會有個資疑慮? 最搞笑的是, 的官網 說:詐騙集團會使 用 與本 行 相似的網址發送電 子 郵件或 簡訊,極有可能是要進 行 詐 騙的前置 行 為 某銀 行 那要 背書 .com.tw 是 自己 其它網域 某銀 行 .某寄信公司 某銀 行

Slide 19

Slide 19 text

–當時的我腦袋亂七八糟 「蛤叫 人 家發信不會設 SPF 喔?」 「啊你各位看到網域都不看後 面 的嗎」 「找外包發信沒問題啊,可是這個外包 用自己 名義發信捏😆」 「怎麼沒 人 搞清楚其實你找 Google 或微軟發信也是 一 種外包」 「沒有啦網域名稱不能有底線」 「咦進線要求客服重送就會是銀 行自己 的 domain 喔?」

Slide 20

Slide 20 text

「欸我也來看 一 下我的帳單🧐」

Slide 21

Slide 21 text

不看不知道, 一 看嚇 一 跳😮 • 綜合電 子 對帳單是 用 server@###bank.[發信服務商].com.tw • 廣告信跟登入成功通知是 用 ebanking@###bank.com • 轉帳交易通知是 用 ebanking@mht.###bank.com • 官網的網址是 https://www.###bank.com.tw/ • https://www.###bank.com/ 會轉到官網 • 但是 http://###bank.com/ 會噴 IIS 的 403 • 有 人 提到的 ###.com 是不通的 寄件者好幾個 網站跟 email 的 domain 不 一 致

Slide 22

Slide 22 text

網域名稱沒辦法給 人 信 心

Slide 23

Slide 23 text

不是漏洞, 而 是 UX 問題

Slide 24

Slide 24 text

長得更像是真的網域? 好像 大 家都會漏掉 .tw

Slide 25

Slide 25 text

真的漏了😆

Slide 26

Slide 26 text

相信最近都有受到感召

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

為了避免這個網域被惡意利 用

Slide 29

Slide 29 text

衝動購物

Slide 30

Slide 30 text

應該要做點什麼

Slide 31

Slide 31 text

做點即將失傳的傳統 手工 藝好了 手 刻 HTML 與 CSS

Slide 32

Slide 32 text

懶 人 版銀 行 網站誕 生 所有連結都沒有 用 ,騙不到 人

Slide 33

Slide 33 text

怕被告,所以... • 不抄「參考」網站的 code(但是會抄 色 碼) • 不偷圖,需要圖片 一 律靠 AI 產 生 • 不做後端,減少被攻擊風險,並減少詐騙疑慮 • 前端放在 GitHub Pages,除了 Google Analytics 以外也不掛 js • 網站名稱不可以 用 相同的字

Slide 34

Slide 34 text

連 logo 都是詠唱成果 (其實失敗很多次)

Slide 35

Slide 35 text

Cursor 還嘗試了最近很夯的 AI 編輯器

Slide 36

Slide 36 text

不是幫我寫 code 而 是寫內容

Slide 37

Slide 37 text

想要解決的問題

Slide 38

Slide 38 text

使 用 者難以信任網域名稱

Slide 39

Slide 39 text

明確的網域名稱計畫 • (舉例) • 固定使 用 相同的名稱 • 明確定義每個名稱(甚 至 email)的 用 途 • 把容易混淆的名稱買下來,除了轉址到主網站外,不要使 用 • 告訴客 戶 只需要認得特定網域名稱

Slide 40

Slide 40 text

銀 行 的地域性很重要

Slide 41

Slide 41 text

隨便想幾個銀 行 來看看 • 這些銀 行 都有買下「 自己 名稱.tw」👍 • x 山 、中x、永x、x展、x泰、x打、x 大 、匯x • 好像多數沒有在使 用 ,就是放著,也沒做轉址🙃 • 至 少避免了被拿去做壞事的可能 • UX 還不夠好

Slide 42

Slide 42 text

該如何委託別 人 用 我的網域寄信?

Slide 43

Slide 43 text

直接寄 Email 寄件者可以偽造

Slide 44

Slide 44 text

郵件服務商沒那麼笨

Slide 45

Slide 45 text

Sender Policy Framework (SPF) 在 DNS 寫上「我授權給這些主機幫我發信」

Slide 46

Slide 46 text

DomainKeys Identi fi ed Mail (DKIM) 提供發信主機證明 一 封信的確是 自己 發出的,且沒有被竄改

Slide 47

Slide 47 text

根據可靠(?)的 ChatGPT 告訴我

Slide 48

Slide 48 text

找 Cloud fl are 學電 子 郵件安全

Slide 49

Slide 49 text

👍

Slide 50

Slide 50 text

LT 時間來不及了 上台前才知道 5 分鐘改 4 分鐘 😭😭😭😭😭

Slide 51

Slide 51 text

跟某銀 行 聯繫

Slide 52

Slide 52 text

很快(24 小 時內)就接到回電 04:00 -> 19:00

Slide 53

Slide 53 text

–某銀 行高 階主管 「近期就會改回 用自己 的網域發信,這個已經在做了。」

Slide 54

Slide 54 text

👍

Slide 55

Slide 55 text

銀 行 的確會有點緊張

Slide 56

Slide 56 text

但這不是漏洞,是 UX 問題

Slide 57

Slide 57 text

稍具規模的企業都需要注意

Slide 58

Slide 58 text

總結 • 不單純關注安全,還要看你的使 用 者體驗 • 規範網域名稱計畫,避免使 用 者混淆 • 買下相似 domain,減少潛在風險 • 如果要請 人 發信,設定 SPF 跟 DKIM

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content