我做了一個詐騙網站...嗎？

Transcript

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

2. 保護當事網站

3. None

4. 支 援 HTTPS

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

6. 按鈕是 一 定要的

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

8. 提醒使 用 者避免詐騙！貼 心 ！

9. 身 為 一 個軟體開發者

10. 約耳趣談軟體

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

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

13. None
14. None

15. 故事的起源

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

17. 我：？？？？ 人 家銀 行 找外包，何必非要 自己 的 mail server 才

    行 原PO說不是銀 行 的，明明 就有 ，有問題嗎 某銀 行 其實很多銀 行 的紙本帳單 都是傳檔案給專 門 印帳單 的公司印刷、封裝、郵寄 的。申請的時候都放棄這 些權利了 這位是不是腦筋有問題啊， 明明是 某銀 行 .某寄信公司

18. 我：👍👍👍👍 防釣 魚 教戰 一 點就是確認網址 寄件 人 結果銀 行自己

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

19. –當時的我腦袋亂七八糟 「蛤叫 人 家發信不會設 SPF 喔？」 「啊你各位看到網域都不看後 面 的嗎」 「找外包發信沒問題啊，可是這個外包

    用自己 名義發信捏😆」 「怎麼沒 人 搞清楚其實你找 Google 或微軟發信也是 一 種外包」 「沒有啦網域名稱不能有底線」 「咦進線要求客服重送就會是銀 行自己 的 domain 喔？」

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

21. 不看不知道， 一 看嚇 一 跳😮 • 綜合電 子 對帳單是 用

    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 不 一 致

22. 網域名稱沒辦法給 人 信 心

23. 不是漏洞， 而 是 UX 問題

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

25. 真的漏了😆

26. 相信最近都有受到感召

27. None

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

29. 衝動購物

30. 應該要做點什麼

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

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

33. 怕被告，所以... • 不抄「參考」網站的 code（但是會抄 色 碼） • 不偷圖，需要圖片 一 律靠

    AI 產 生 • 不做後端，減少被攻擊風險，並減少詐騙疑慮 • 前端放在 GitHub Pages，除了 Google Analytics 以外也不掛 js • 網站名稱不可以 用 相同的字

34. 連 logo 都是詠唱成果 （其實失敗很多次）

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

36. 不是幫我寫 code 而 是寫內容

37. 想要解決的問題

38. 使 用 者難以信任網域名稱

39. 明確的網域名稱計畫 • （舉例） • 固定使 用 相同的名稱 • 明確定義每個名稱（甚 至

    email）的 用 途 • 把容易混淆的名稱買下來，除了轉址到主網站外，不要使 用 • 告訴客 戶 只需要認得特定網域名稱

40. 銀 行 的地域性很重要

41. 隨便想幾個銀 行 來看看 • 這些銀 行 都有買下「 自己 名稱.tw」👍 •

    x 山 、中x、永x、x展、x泰、x打、x 大 、匯x • 好像多數沒有在使 用 ，就是放著，也沒做轉址🙃 • 至 少避免了被拿去做壞事的可能 • UX 還不夠好

42. 該如何委託別 人 用 我的網域寄信？

43. 直接寄 Email 寄件者可以偽造

44. 郵件服務商沒那麼笨

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

46. DomainKeys Identi fi ed Mail (DKIM) 提供發信主機證明 一 封信的確是 自己

    發出的，且沒有被竄改

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

48. 找 Cloud fl are 學電 子 郵件安全

49. 👍

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

51. 跟某銀 行 聯繫

52. 很快（24 小 時內）就接到回電 04:00 -> 19:00

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

54. 👍

55. 銀 行 的確會有點緊張

56. 但這不是漏洞，是 UX 問題

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

58. 總結 • 不單純關注安全，還要看你的使 用 者體驗 • 規範網域名稱計畫，避免使 用 者混淆 •

    買下相似 domain，減少潛在風險 • 如果要請 人 發信，設定 SPF 跟 DKIM
59. None
60. None